Re: [darcs-devel] Darcs and git: plan of action

From: Ray Lee <ray-lk@madrabbit.org>
Date: Apr 18, 2005, 18:35 UTC
Message-ID: <1113849317.23938.48.camel@orca.madrabbit.org>
In-Reply-To: <20050418122011.GA13769@abridgegame.org>

On Mon, 2005-04-18 at 08:20 -0400, David Roundy wrote:

Show 6 quoted lines

> Putting darcs patches *into* git is more complicated, since we'll want to
> get them back again without modification.  Normal "hunk" patches would be
> no problem, provided we never change our diff algorithm (which has been
> discussed recently, in the context of making hunks better align with blocks
> of code).  We could perhaps tell users not to use "replace" patches.  But
> avoiding "mv" patches would be downright silly.

Okay, I still haven't used git yet (and have only toyed around with darcs for a bit), so take what I'm saying with a grain of salt. Regardless, I think you may be asking the wrong question. The tracking of renames was bandied about pretty thoroughly on-list from Wednesday through Friday (for far better commentary and insight, see Linus' messages with subject: Merge with git-pasky II.)

git does track changesets that describe the parent tree(s) and the result. The trees track filenames and hashes. So, doing a fairly straightforward compare on two trees will let you immediately discover renames that have occurred, as the filename in the tree changed while the hash didn't.

So, the question then becomes, can an outside tool cheaply derive all the information that darcs would need to perform it's work? The renames should be easy, as long as no content changed during the rename. As for token replacement (and whitespace changes, etc.), that could be discovered via domain-specific parsers (something specific per language, for example). Linus tossed a link to one such tool (hmm, where was it. Sheesh. You sure right a lot, dude :-).)

	http://minnie.tuhs.org/Programs   (see Ctcompare)

...which should be viewed more as a proof-of-concept than a mergeable code-set. It does show that diff's vocabulary is sadly lacking in expressiveness, and improving that, I think, would be a useful area to expend effort.

Again, I may be off here, especially considering I've a backlog of a couple hundred messages to read since the weekend. (You guys need to go outside more often.)

Ray