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

[Junio C Hamano <junkio@cox.net>]

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

> 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