Re: tracking renames

[Jakub Narebski <jnareb@gmail.com>]

On Wed, 5 Mar 2008, Jean-François Veillette wrote:
> Le 08-03-04 à 17:19, Jakub Narebski a écrit :
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>>
>>> On Tue, 4 Mar 2008 14:03:54 -0800
>>> "Harvey Harrison" <harvey.harrison@gmail.com> wrote:
>>>>
>>>> git-whatchanged --follow drivers/watchdog/iTCO_wdt.c
>>>>
>>>
>>> Oh.  Thanks.  It seems dumb that one needs to add an option to get
>>> it to do this.
>>
>> In "git log <paths>..." or "git whatchanged <paths>..." the <paths>
>> option is "path limiter" and can be a directory. There can be more
>> than one path. And following renames is more costly.
> 
> Am I the only one who think rename could be explicit?

No, you are not the only one. Use Bazaar-NG (bzr) or Mercurial (hg)
if you think you truly need rename _tracking_ as opposed to rename
_detection_.

> Don't take me wrong, I do appreciate the fact that git recognize  
> renames after-the-fact, when specifically asked for it.
> But as a developer, at some point, a rename is no longer a point-of- 
> view discovery, a rename is a rename by 'design', by the nature  
> itself of the change, it's no longer an after-the fact realisation.

There is a point why git does rename detection and not (usually 
file-id / file-inode based) rename tracking, besides historical
reasons. This discussion crops now and there; you can search mailing
list archives (and perhaps look up GitFaq at GitWiki).

> It seem to me that no mather how smart we try to discover renames,  
> there will always be cases where algorithm won't discover due to time/ 
> space/other constraints.

Then we will improve rename (and copy) detection heuristics.

> I would like something like 'graft' where after the fact, we can  
> educate git that there is a connection between 2 commits.  In a  
> similar way, at some point, I would like to tell git, 'ok stop trying  
> to figure out which changes are renames, you guessed it right for the  
> last 10 times, just freeze it ... but let me adjust it if you guessed  
> it wrong'.

There was idea of _local_ second level of rerere (reuse resolved 
resolution of conficting merges), more persistant, which would remember 
tree merge conflicts (rename detection and other such conflicts).
But as far as I know it never got implemented.
 
IMVHO it is only sensible solution, see below.

> This is a comment from  a git user, I've not looked at the code at  
> all (and probably won't do anytime soon).

First, I think it could be good idea to store helper advisiory 
information about explicitely stated renames, or tree merge resolutions 
as a [proposed] 'note' header in commit object, to be remembered when 
traversing graph of commits to find common ancestor(s) and later reuse 
in rename detection. But this never got past the wishful thinking...


Explicit rename tracking has many caveats. 

If you remember it with commit info, you would loose at least somewhat 
nice assertion that only endpoints (which includes merge bases) matters 
when doing merge, not the path taken.  IIRC it is what Mercurial does.

If you use some kind of automatic assigned file-ids (file-inodes) you 
can have problems with independently added (on different branches) 
files.  Linus also suggests that if you have file-id conflict, you 
would have to resolve it again, and again, and again.  IIRC it is what 
Bazaar-NG (following original Arch idea) does.

And of course with rename (and copy) tracking you _have_ to explicitely
state renames, which is a bit out of question if some of your commits 
comes as a patches in email, or from foreign SCM. Or if you forget to 
explicitely state rename.


Besides wholefile rename tracking is only small fragment of dealing with 
code movement, something what "git gui blame" ("git blame -C -C") is 
good at...

-- 
Jakub Narebski
Poland