I'll be happy to keep you posted....
... I'll put up a description once I get things worked out a bit more.
It will take me a month or two, though, probably.
... but as a quickie... :)
The general idea is to use actual syntax parsing to understand what
happens in particular files, but be able to fall back on text if
necessary. (Maybe "smarter text" as described by Daniel would be an
intermediate fallback step.)
No matter what the target language, files have a hierarchical
organization (at least as far as I am going to care about :)). My idea
is to write a "delta" in yaml with the tree-edit operations, as a
universal representation of changes. This could be edited by the user
if necessary -- for example: a move with edits in it might not be
detected, but the user could explicitly replace the delete/add pair
with the move/edit. Tools would be provided to verify that the edited
deltas actually produce the changes stated (& update them to capture
the next set of deltas, etc.)
Suggestions from you guys as to the best way to tie this in would be
greatly appreciated. I think the analysis of particular file types
should only be loosely coupled with the rest of the system, though, as
otherwise it will create a rats' nest.
Ideally, there would be a mechanism for an outside diff tool to
specify "these are the hunks", and to register a utility to apply
them... the smart diff tool would use the yaml tree-operation format
and have its own registry (or config section) for how to analyze
particular file types.
The diff tool would also be coupled with a merge tool... in general,
it would be nice if there were more hooks for providing specialized
diff & merge.
-- Shaun
On Aug 5, 2009, at 8:21 PM, Sverre Rabbelier wrote:
Heya,
On Wed, Aug 5, 2009 at 09:21, Shaun Cutts<shaun@xxxxxxxxxxxxx> wrote:
PS I'm considering writing an extension to git where the "diff"
understands the
semantics of certain types of files: hunks wouldn't just be textual
blobs but
would try to represent a minimal change from one version to the
next based on an
edit distance, so that, e.g. changing the location of a function
would be
represented by a "move" edit, rather than two text changes.
This sounds very similar to what Daniel was discussing in "[PATCH 2/3
v3] Use an external program to implement fetching with curl git" [0],
if you're truly interested in doing this, please do keep me posted
(and I suspect Dscho might also be interested in being cc-ed) :).
[0] http://thread.gmane.org/gmane.comp.version-control.git/124503
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html