From: Catalin Marinas Date: Sat, 17 Sep 2005 09:31:57 GMT Subject: Re: git-merge-cache / StGIT - gitmergeonefile.py: merging one tree into another rather than two trees into merge base 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: > Catalin Marinas 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. > 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