Le 08-03-04 à 17:19, Jakub Narebski a écrit :
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:
On Tue, 4 Mar 2008 14:03:54 -0800
"Harvey Harrison" <harvey.harrison@xxxxxxxxx> 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
--
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
