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

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Sep 17, 2005, 09:31 UTC
Message-ID: <1126949517.6941.19.camel@localhost.localdomain>
In-Reply-To: <7vvf10hji1.fsf@assigned-by-dhcp.cox.net>

On Fri, 2005-09-16 at 12:59 -0700, Junio C Hamano wrote:

Show 12 quoted lines

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

This could be OK for git-read-tree but maybe git-merge-index could have a --smart option to deal with trivial cases like below (or a separate tool). Whoever wants to write a more interactive script would not pass this option.

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

That's what happens with the current merge scripts.

Another option for me would be to try to interface Python with libgit.a and emulate the git-merge-index behaviour but I've never tried mixing Python and C before.

Show 6 quoted lines

> 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

It might help for people using git directly (me as well). StGIT parses the git-diff-tree output anyway.

-- 
Catalin