lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 5724e39 5/5: Suggest a workaround for a puzzling git error
Date: Fri, 30 Oct 2020 23:56:18 +0100

On Thu, 29 Oct 2020 20:35:23 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

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

 Sorry, this thought just hasn't entered my mind, so used I am to be the
one forgetting past discussions and being reminded about it by the others.

GC> You had proposed two ideas:
GC> 
GC> |  First one, which I'm almost sure is going to work: just create a 
temporary
GC> | branch and switch your HEAD (== pointer to the commit currently checked
GC> | out) to it, e.g.:
GC> | 
GC> |         git checkout -b tmp-branch HEAD~3
GC> | 
GC> | Then you can follow the usual procedure without any changes and, at the
GC> | end, you can just
GC> | 
GC> |         git checkout master
GC> |         git branch -d tmp-branch
GC> 
GC> That first suggestion seems laborious...
GC> 
GC> |  Second one, requiring less steps, could be to just create a branch 
without
GC> | switching to it:
GC> |
GC> |        git branch some-good-name HEAD~3
GC> |
GC> | and then use it when creating the bundle:
GC> |
GC> |        git bundle create /opt/lmi/blessed/$(date -u 
+'%Y%m%dT%H%MZ')-gwc.bundle origin/master..some-good-name --branches
GC> 
GC> ...and so does the second. AFAICT, both involve creating a unique name,
GC> in the repository, for a bundle's intended contents, and then using that
GC> name when pulling from the bundle on another machine.

 Yes.

GC> It's better not to have to specify such a parameter. We already have a
GC> name, "HEAD", that needn't be specified because it's implicit;

 I thought that having an explicit and unique name might be better and less
confusing, but there is, of course, nothing wrong with using HEAD or master
if you find it clear enough.

GC> the problem is that it doesn't always work.

 I still don't understand why does this happen, but I probably won't spend
any time on this if this is not really important to you.

GC> But we also have another built-in name, "master", that looks like it'll
GC> always work; if it needs to be specified, at least it's invariant.

 Again, sorry if I'm forcing an open door here, but for me using "master"
is potentially problematic precisely because the name itself is invariant,
while the commit pointed by it is not.

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

 It seems to be implicitly understood that everything in the "SPECIFYING
REFERENCES" section can be used with "git bundle create".

 Regards,
VZ

Attachment: pgpdc_6AQXOpT.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]