On 3/22/07, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
Additional issue that we have to think about with respect to rename support for merges is that git uses 3-way merge, taking into account _only_ upstream commit (of the branch we want to merge to), side branch commit (of the branch we want to merge) and common ancestor[*1*] (merge base) for merging. What is important is that the intermediate states, how we got to the current state, does not matter. Well, one could argue that if we remember explicit (provided by user) info about renames for example in proposed 'note' field of a commit object, or in other helper structure (we cannot remember the information in blob or tree), we can gather and remember information about recorded explicit renames when finding common ancestor...
But we do have some of that already - if one trees being merged is missing a path that changed on the other one, we walk back on the ancestry looking for renames. Or am I seeing things?
Still, it would be nice to have --follow=<file> option to git-log family, besides path limiting.
+1 here - git log should have something equivalent to diff's -M. When the file "disappears", run a diff-tree -M -C against the parents to see whether there were any "related predecessors" to the file to add to the pathspec. Of course, there could be more than one. For example, right now, git log git-cvsimport.perl ends at the big tool rename. cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html