Re: Stupid git!

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: acm@muc.de,  sven.axelsson@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 14 Sep 2015 14:47:15 +0200
>> 
>> >> >> Pulling is not a really good thing to do if you have uncommitted work.
>> >> >
>> >> > I'm doing it all the time, and have yet to report a single problem.
>> >> >
>> >> > It's the simplest way of minimizing the probability of spurious
>> >> > merges, when someone else pushes before you.
>> >> 
>> >> Nope.  The simplest way is to git fetch rather than git pull.
>> >
>> > How is using 2 commands instead of one, and learning an additional
>> > command, simpler?
>> 
>> The "simplest way of minimizing the probability of spurious merges" is
>> not to execute commands doing possibly unintended merges.
>
> If your recipe would have been "don't use pull", it would have been
> simpler.  But that's not what it says, it says "use fetch and merge
> instead", which is definitely not simpler.
>
>> If you insist on only ever using git pull, it also has an option
>> --ff-only which will refuse to do anything non-trivial.
>
> At the cost of having to learn the option.  Not simpler.
>
>> >> > If you commit then pull, and someone else pushed in between, you
>> >> > will get that "merged branch master" thing.
>> >> 
>> >> It that's not what you want, git pull -r will rebase just fine.
>> >
>> > We've concluded long ago that "pull --rebase" is trouble when you
>> > merge from and to feature branches, so I'm trying to stay away of that
>> > path.
>> 
>> That's ridiculous.  What we have concluded is that setting --rebase as a
>> default was not likely a good idea because of feature branches.  But it
>> is quite absurd not to use the option for those cases where you indeed
>> want a rebase instead of a merge commit.
>
> It's not absurd when you take muscle memory into consideration.  We
> are talking here about routine operations (since you don't know in
> advance whether a pull will cause conflicts or a need to merge), not
> about an option to be used in specific rare circumstances.

The simplest option taking muscle memory into account is throwing the
computer against the wall.  If you are not interested in actually
achieving the objective ("minimizing the probability of spurious
merges"), that seems by far the simplest action.

I just don't see the point in discussing the simplest action you can
take without actually achieving the objective at the same point of time.

-- 
David Kastrup