Catalin Marinas wrote: > On Fri, 2005-09-16 at 12:59 -0700, Junio C Hamano wrote: > >>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. i noticed while testing the new cache API that there are no tests under t/ for git-merge-index. there is also no test script that covers the prune_cache() function in ls-files.c. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2.1.8 : 2005-09-20 01:51:36 EST