tracking renames

tracking renames

[Andrew Morton]

When I do

	git-whatchanged drivers/watchdog/iTCO_wdt.c

it ends at "mv watchdog tree under drivers".  I'd have expected it to
tell me things about that file when it was in its original home at
drivers/char/watchdog/iTCO_wdt.c

Re: tracking renames

[Harvey Harrison]

On Tue, Mar 4, 2008 at 1:57 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>  When I do
>
>         git-whatchanged drivers/watchdog/iTCO_wdt.c
>

git-whatchanged --follow drivers/watchdog/iTCO_wdt.c

Cheers,

Harvey

Re: tracking renames

[Andrew Morton]

On Tue, 4 Mar 2008 14:03:54 -0800
"Harvey Harrison" <harvey.harrison@gmail.com> wrote:

> On Tue, Mar 4, 2008 at 1:57 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> >  When I do
> >
> >         git-whatchanged drivers/watchdog/iTCO_wdt.c
> >
> 
> 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.

Re: tracking renames

[Jakub Narebski]

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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: tracking renames

[Jean-François Veillette]

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 ?
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.
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.
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'.

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

- jfv

Re: tracking renames

[Jakub Narebski]

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

Re: tracking renames

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 201 bytes --]

Hi,

On Wed, 5 Mar 2008, Jean-François Veillette wrote:

> Am I the only one who think rename could be explicit ?

This is one of the most FAQ.  Please see

	http://git.or.cz/gitwiki/GitFaq

Hth,
Dscho

Re: tracking renames

[Martin Langhoff]

On Thu, Mar 6, 2008 at 5:39 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>  This is one of the most FAQ.  Please see
>
>         http://git.or.cz/gitwiki/GitFaq
>

And don't miss the entertaining and colourful email by Linus on the
subject here http://permalink.gmane.org/gmane.comp.version-control.git/217

... this has also been a recurring flamefest in the past. So if anyone
is feeling argumentative, have a good read of the thousands of flaming
posts on the matter :-)

cheers,


m

Re: tracking renames

[Steven Grimm]

On Mar 5, 2008, at 8:15 AM, Jakub Narebski wrote:
> 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_.

Having watched (and participated in) this discussion several times as  
it's come up on the list, the one thing I don't understand is why  
people -- not you, but others -- think this has to be an "as opposed  
to" issue. I have yet to see anyone propose that git should lose its  
rename detection, but the counterarguments and explanations about how  
inferior rename tracking is often seem to presuppose that that's  
what's being asked for.

I think the setup the pro-rename-tracking crowd mostly wants is, "git  
always treats explicitly specified renames as renames and uses its  
current detection regime if there is no explicit specification." As  
you say later on in the parent message, a wish-list item that hasn't  
become reality yet.

I am not saying I think it's too important, BTW; I'm just trying to  
clarify the other point of view. Personally, my only major wish item  
for git's rename support is better handling of directory renames, but  
I don't really care how git knows that the directory in question has  
been renamed. The file rename support has worked very well for me in  
practice.

-Steve