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

[Greg Chicares]

On 10/30/20 10:56 PM, Vadim Zeitlin wrote:
> On Thu, 29 Oct 2020 20:35:23 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> 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.

We want a command that just works when copied and pasted,
with as little manual editing as possible.

> 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.

Adding one invariant word to the incantation seems to make it work.
Leaving that word out makes it fail sometimes. I'm satisfied with
that knowledge, for now at least. My personal proclivity is to
learn by a depth-first search, but with git that rabbit hole goes
too deep.

> 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.

We always want to do the same thing: synchronize one machine's
"blessed" repository with another's. Sure, git has the power to do
a million other things, but that's the only thing we ever want to
do with these "blessed" repositories. We've never had, and really
don't need, any branch other than 'master'. We always want to
synchronize everything to the commit pointed to by 'master'. And
naming that branch makes a command work when not naming it failed.