Re: [ANNOUNCE] Git wiki
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- May 5, 2006, 19:39 UTC
- Message-ID
- <e3g9m6$8i0$1@sea.gmane.org>
- In-Reply-To
- <20060505185445.GD27689@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Fri, May 05, 2006 at 08:31:06PM CEST, I got a letter > where Linus Torvalds <torvalds@osdl.org> said that...
Show 22 quoted lines
> I prefer making this [rename detection] data dependable to having to > resort to guessing on dependable less amount of data. > >> There's another reason why encoding movement information in the commit is >> totally broken, namely the fact that a lot of the actions DO NOT WALK THE >> COMMIT CHAIN! >> >> Try doing >> >> git diff v1.3.0.. >> >> and think about what that actually _means_. Think about the fact that it >> doesn't actually walk the commit chain at all: it diffs the trees between >> v1.3.0 and the current one. What if the rename happened in a commit in >> the middle? > > Then the automated renames detection will miss it given that the other > accumulated differences are large enough, and the suggested workarounds > _are_ precisely walking the commit chain. > > If you use persistent file ids, you never miss it _AND_ you DO NOT WALK > THE COMMIT CHAIN! You still just match file ids in the two trees.
Let not jump to the one of the possible solution. The detecting and noting renames and content moving (with user interaction) at commit is nice... unless does something which cannot allow interactiveness (like applying patchbomb), but even then detecting and saving info at commit would be good idea.
What we need is to for two given linked revisions (with a path between them) to easily extract information about renames (content moving). Perhaps using additional structure... best if we could do this without walking the chain. The rest is details... ;-P
-- Jakub Narebski Warsaw, Poland