Re: fast forward merge overwriting my code

[Philip Oakley <philipoakley@iee.email>]

On 23/05/2021 16:01, Junio C Hamano wrote:
> 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.  

Andre had (in the body of the text) explicitly said that it was the fast
forward that was the problem for him.

I suspect he had a mental model / world view / weltanshauung that was
more aligned to a swim lane model of branches (named lines of
development) and that, possibly in a GUI, the loss two lanes was rather
confusing.

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

In his description it's not always clear "also change some of the
already existing lines" what happened elsewhere that could lead to the
confusion. It will have been tricky for Andre, as someone new to git, to
really know what was going on. We can't assume the new user knows what
Git will do.

> 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.
>
>
The changes to mental models that are needed to understand Git can take
some time, especially for those who haven't grown up with it.

Philip