On Mon, 2005-04-18 at 08:20 -0400, David Roundy wrote:
> 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.)


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to