tracking renames

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

On Tue, Mar 4, 2008 at 1:57 PM, Andrew Morton <akpm@linux-foundation.org> wrote:

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

Cheers,

Harvey

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

Oh.  Thanks.  It seems dumb that one needs to add an option to get it to do this.

Andrew Morton <akpm@linux-foundation.org> writes:

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.

Le 08-03-04 à 17:19, Jakub Narebski a écrit :

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

On Wed, 5 Mar 2008, Jean-François Veillette 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_.

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).

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

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.

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

On Mar 5, 2008, at 8:15 AM, Jakub Narebski wrote:

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

Hi,

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

This is one of the most FAQ.  Please see

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

Hth, Dscho

On Thu, Mar 6, 2008 at 5:39 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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