From: Jakub Narebski Date: Thu, 22 Mar 2007 03:32:25 GMT Subject: Re: Rename handling Message-ID: <200703220432.27071.jnareb@gmail.com> In-Reply-To: <46a038f90703211939j15dbda4cpfa2f49229b8c16cb@mail.gmail.com> Martin Langhoff wrote: > On 3/22/07, Jakub Narebski 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