Re: [lmi] [lmi-commits] master 5724e39 5/5: Suggest a workaround for a puzzling git error

[Greg Chicares]

On 10/28/20 10:24 PM, Vadim Zeitlin wrote:
> On Mon, 26 Oct 2020 16:27:19 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...trying to pull from a particular validated bundle...]
> GC>       $git pull /path/to/catchup.bundle
> GC>       fatal: Couldn't find remote ref HEAD
> GC>     whereas this succeeded:
> GC>       $git pull /path/to/catchup.bundle master
> 
>  I think this is a good solution (rather than just a workaround) in any
> case, but I wonder if you have already tested any of the alternative
> workarounds from my reply to your original message about this problem at
> 
>       https://lists.gnu.org/archive/html/lmi/2019-08/msg00001.html

I had simply forgotten about that discussion. You had proposed two ideas:

|  First one, which I'm almost sure is going to work: just create a temporary
| branch and switch your HEAD (== pointer to the commit currently checked
| out) to it, e.g.:
| 
|         git checkout -b tmp-branch HEAD~3
| 
| Then you can follow the usual procedure without any changes and, at the
| end, you can just
| 
|         git checkout master
|         git branch -d tmp-branch

That first suggestion seems laborious...

|  Second one, requiring less steps, could be to just create a branch without
| switching to it:
|
|        git branch some-good-name HEAD~3
|
| and then use it when creating the bundle:
|
|        git bundle create /opt/lmi/blessed/$(date -u 
+'%Y%m%dT%H%MZ')-gwc.bundle origin/master..some-good-name --branches

...and so does the second. AFAICT, both involve creating a unique name,
in the repository, for a bundle's intended contents, and then using that
name when pulling from the bundle on another machine. It's better not to
have to specify such a parameter. We already have a name, "HEAD", that
needn't be specified because it's implicit; the problem is that it
doesn't always work. But we also have another built-in name, "master",
that looks like it'll always work; if it needs to be specified, at least
it's invariant. This command:
  git pull $bundle_filepath master
can be copied and pasted, and only the bundle filepath need be changed.
The others require additional variables. IOW, I think these commands:
  git bundle create $bundle_filepath origin/master..HEAD --branches
  git pull $bundle_filepath master
are already as simple as possible, except that '--branches' seems
superfluous...

|  I also wonder why do we use --branches in the first place, it looks like
| --branches=master should be enough -- and take quite a bit less space if
| you have any other branches which are not needed by the recipient.

This repository has only one branch, 'master':
  /opt/lmi/proprietary[0]$git --no-pager branch
  * master
If I create a bundle without any '--branches' option, it seems to
work properly:

  $git bundle create /opt/lmi/blessed/$(date -u +'%Y%m%dT%H%MZ')-eraseme 
origin/master..HEAD

  $git bundle verify /opt/lmi/blessed/20201029T2021Z-eraseme
  The bundle contains this ref:
  e5094a5a820181422d52243cf8a6d40dc799d142 HEAD
  The bundle requires this ref:
  f42ffa270bd15c0605517ac996bf2aff3b9a65a5 
  /opt/lmi/blessed/20201029T2021Z-eraseme is okay

  $git pull /opt/lmi/blessed/20201029T2021Z-eraseme
  From /opt/lmi/blessed/20201029T2021Z-eraseme
   * branch              HEAD       -> FETCH_HEAD
  Already up to date.

It seems curious to me that the manual
  https://git-scm.com/docs/git-bundle
mentions '--branches' only once, as an option for 'git clone',
not for 'git bundle create'.