Junio C Hamano wrote: > Petr Baudis <pasky@suse.cz> writes: > >> But the non-obviously important part here to note is that the branch B >> merely "corrects a typo on a comment somewhere" - the latest versions in >> branch A and branch B are always compared for renames, therefore if >> branch A renamed the file and branch B sums up to some larger-scale >> changes in the file, it still won't be merged properly. > > I probably am guilty of starting this misinformation, but the > code does not compare the latest in A and B for rename > detection; it compares (O, A) and (O, B). > > But the end result is the same - what you say is correct. If a > path (say O to A) that renamed has too big a change, then no > matter how small the changes are on the other path (O to B), > rename detection can be fooled. We could perhaps alleviate it > by following the whole commit chain. Or perhaps by helper information about renames, entered either by git-mv (and git-cp) or rename detection at commit, e.g. in the following form note at <commit-sha1> was-in <pathname> note at <commit-sha1> was-in <pathname> (with the obvious limit of this "note header" solution is that it wouldn't work for filenames and directory name containing "\n"). I'm not sure if <pathname> should be just basename, of full pathname. -- Jakub Narebski Warsaw, Poland - 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.htmlReceived on Sat May 06 02:50:26 2006
This archive was generated by hypermail 2.1.8 : 2006-05-06 02:50:48 EST