Re: git-merge-cache / StGIT - gitmergeonefile.py: merging one tree into another rather than two trees into merge base

From: Junio C Hamano <junkio@cox.net>
Date: Sep 16, 2005, 19:59 UTC
Message-ID: <7vvf10hji1.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <tnxslw6d4qt.fsf@arm.com>

Catalin Marinas <catalin.marinas@gmail.com> writes:

Show 6 quoted lines

> git-read-tree -m doesn't handle the case when a file is removed from
> one branch and unmodified in the other, which is what happens in your
> test. For each of these removed files, git-merge-cache will call
> gitmergeonefile.py which calls 'git-update-cache --remove'.
>
> An improvement would be to make git-read-tree smarter...

I think this was once discussed but the primary reason for the behaviour is that Linus wanted to leave as much merge policy decision to be scriptable without hardcoding it in read-tree.

For example, you would see branch A removing a path while branch B keeping the path if A renamed it to somewhere else while B kept it -- a cleverer merge policy than one-path-at-a-time we currently have _could_ take a hint from the unmerged cache, go look for the other half of the rename in branch A, and ask the user if the rename should be honored in the merge result for example. If you always do "added or removed in only one head means take that head", most likely in the above example B would not have a new path (rename target of A) so you would end up always taking the file rename.

>> git-diff-tree -r v2.6.13 master |grep ' D'|wc -l
>>
>> gives 189.

A completely different topic:  would it please people if I did this?

    $ git-diff-tree -r --names-and-changes A B
    M	frotz
    R93	rezrov	nitfol
    D	yomin