Re: fast forward merge overwriting my code

From: Junio C Hamano <gitster@pobox.com>
To: Philip Oakley <philipoakley@iee.email>
Cc: Andre Ulrich <andre.ulrich@smail.fh-koeln.de>, git@vger.kernel.org
Subject: Re: fast forward merge overwriting my code
Date: Mon, 24 May 2021 00:01:53 +0900	[thread overview]
Message-ID: <xmqqo8d1o5ni.fsf@gitster.g> (raw)
In-Reply-To: 8f3d4d1e-18f4-ccb2-9439-80a5812c2f36@iee.email

Philip Oakley <philipoakley@iee.email> writes:

> On 22/05/2021 16:48, Andre Ulrich wrote:
>> .... Then I use
>>
>> git checkout master
>>
>> and
>>
>> git merge testing
>>
>> I would expect git to tell me "hey, wait, you have changed some of the
>> first lines in the .txt file. When you merge, your code on master will
>> be altered". But git just merges everything in.
> ...
> maybe `git merge --no-ff testing` for use of a command line option
>
> or setup your .gitconfig e.g. `git config --global merge.ff no`,
> but also `git config --global pull.ff yes` if you are using `git pull`
> (=fetch + merge)

I didn't get an impression that this has anything to do with
fast-forwarding, though.  The file in question has changes on the
"testing" branch since it forked from "master", and the user is
merging, i.e. the user _assumes_ that the tip of each branch suits
his/her purpose better than the tip of the other branch, hence wants
to take improvements on both branches incorporated into a single
history--- which is the point of "merging" the testing branch into
the master branch.  The result of merging might reveal that the tip
of the other branch wasn't as great as s/he earlier thought, in
which case s/he may want to undo the merge.  But if the result of
merging better suites his/her purpose, it would be an improvement
over where 'master' used to be (and it would also be an improvement
over where 'testing' used to be), and the world makes a progress.

In this particular case, the "master" side did not move since the
two branches forked, so the merge was to take improvements made on
"testing" into "master", and if the edit to the file in question
made on "testing" were bogus, the merging operation of course will
bring that breakage in, together with all the other changes.  Since
the lack of any progress on the "master" side does not change this
picture, I do not think fast-forwardness has anything to do with
what Andre is complaining about.

"git merge" cannot be expected to inspect the file and point out
"no, the edit they made on the testing branch is totally bogus,
don't merge it".  That is left for humans and tools other than Git
(like test suite) may help them.