Re: tracking renames
- From
- Jean-François Veillette <jean_francois_veillette@yahoo.ca>
- Date
- Mar 5, 2008, 15:39 UTC
- Message-ID
- <965172C8-C7A4-4932-899B-1E1A77BD7C12@yahoo.ca>
- In-Reply-To
- <m3zltegmj0.fsf@localhost.localdomain>
Le 08-03-04 à 17:19, Jakub Narebski a écrit :
Show 14 quoted lines
> 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