Martin Langhoff wrote: > 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? First, I was talking about hypotetical manually-provided helper information about explicit renames, entered by user, not guessed by SCM. Second, I have thought that rename detection is done on final states: upstream, branch and ancestor, not on intermediate commits. I guess I thought wrong. -- Jakub Narebski Poland - 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