Re: Stupid git!

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Mon, 14 Sep 2015 14:28:06 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> >> From: David Kastrup <address@hidden>
>> >> Date: Mon, 14 Sep 2015 12:29:37 +0200
>> >> Cc: Sven Axelsson <address@hidden>, emacs <address@hidden>
>> >> 
>> >> 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 you insist
on only ever using git pull, it also has an option --ff-only which will
refuse to do anything non-trivial.

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

There is a reason it is available as a command line option and not just
as a configuration variable.

-- 
David Kastrup