Re: Handling renames.

From: David Woodhouse <dwmw2@infradead.org>
Date: Apr 14, 2005, 19:20 UTC
Message-ID: <1113506402.12012.218.camel@baythorne.infradead.org>
In-Reply-To: <20050414185841.GA16865@elte.hu>

On Thu, 2005-04-14 at 20:58 +0200, Ingo Molnar wrote:

Show 7 quoted lines

> The thing i tried to avoid was to list long filenames in the commit 
> (because of the tree hierarchy we'd need to do tree-absolute pathnames 
> or something like that, and escape things, and do lookups - duplicating 
> a VFS which is quite bad) - it would be better to identify the rename 
> source and target via its tree object hash and its offset within that 
> tree. Such information could be embedded in the commit object just fine.  
> Something like:

Actually I'm not sure that's true. Let's consider the two main users of this information.

Firstly, because it's what I've been playing with: to list a given file's revision history, I currently work with its filename -- walk the commit objects, inspecting the tree and selecting those commits where the file has changed. If my filename is 'fs/jffs2/inode.c' then I can immediately skip over a commit where the 'fs' entry in the top-level tree is identical to that in the parent, or I can skip a commit where the 'jffs2' entry in the 'fs' subtree is identical to the parent... it's all done on filename, and the {parent, entry} tuple wouldn't help much here; I'd probably have to convert back to a filename anyway.

Secondly, there's merges. I've paid less attention to these (see mail 5 minutes ago) but I think they'd end up operating on the rename information in a very similar way. To find a common ancestor for a given file,, we want to track its name as it changed during history; at that point it's all string compares.

-- 
dwmw2