git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git index: how does it work?

From
Shaun Cutts <shaun@cuttshome.net>
Date
Aug 5, 2009, 19:31 UTC
Message-ID
<C2C8DCE2-388B-49F4-A231-CD52779CDF48@cuttshome.net>
In-Reply-To
<fabb9a1e0908051121m6efafc02gd468a92784a73ecd@mail.gmail.com>
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:
Show 25 quoted lines
> Heya,
>
> On Wed, Aug 5, 2009 at 09:21, Shaun Cutts<shaun@cuttshome.net> 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
>
Previous: Sverre Rabbelier
Message 9 of 9 in “git index: how does it work?”
  1. Shaun CuttsAug 5, 2009
  2. Junio C HamanoAug 5, 2009
  3. Shaun CuttsAug 12, 2009
  4. Sverre RabbelierAug 12, 2009
  5. Shaun CuttsAug 12, 2009
  6. Björn SteinbrinkAug 12, 2009
  7. Junio C HamanoAug 12, 2009
  8. Sverre RabbelierAug 5, 2009
  9. Shaun CuttsAug 5, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.