Implement core diff protocols

[hausdorf]

git produces both raw diff output (as in git diff) and a raw diff internal representation used to apply merges, patches, etc. This task will be composed of:

1. Nailing down what that protocol is.
2. Seeing if we can implement it faster.

The next step is to implement it inside and around the core diff function.

[hausdorf]

Andrew and I were poking around in git today. The places you will want to look are the diff* src files (e.g., diffcore-pickaxe.c, diff.c, and so on). Particularly useful as a place to start may be delta.h, as this houses the comments for the functions that occur in these diff* files. The function create_delta() seems promising, and is declared in delta.h and implemented in diff-delta.h.

What seems to be happening here is that files and commits are stored in the index -- note that this is not a number, but a struct, and appears to be very similar, if not the same thing as the index that you add files to when you run git add [filename] (i.e., this command puts a file in git's index).

Hope this helps!

[basepi]

Yep, we'll look through that stuff. Landon and will probably get together this weekend -- I have a physics midterm and non-school stuff to do until Friday afternoon or so, so I won't be able to dedicate much time to this until then.

[trane]

We found where you guys should start looking. It is in the git repo, "git/builtin/diff.c". This contains all of the methods that can be called when a 'git diff ...' command is issued and should be the primary reference source of what you guys will be supplying for third party interaction between our diff implementation(s) and the user linking libgit2.

[trane]

Alright, guys. Here is the KEY to your implementation... in

builtin/diff.c

the function

cmd_diff

(the last function) contains the comment of how the command-line options correspond to specific function calls.

[hausdorf]

You may have noticed that comments are sparse in the git source. Here is the cure:

Documentation/technical

Inside is a shit-ton of API .txt files that explain everything. Diff, merge, whatever. This is what you guys need to do your job.

[hausdorf]

Morning yet again, gentlemen. In today's exciting installment of "Andrew and Alex do your jobs for you", we will point you to a specific file that is (we think) the crux of your problem:

xdiff-interface.c

So remember, the goal here is to implement all the features needed to diff. Please call me if you have any questions about how that works.

[hausdorf]

Dear sweethearts,

If you were wondering, the diff function call patterns goes roughly as so, starting with the more general interface methods, and getting more specific (i.e., closer to the actual diff) as you go down the list.

1. xdiff-interface.c -> xdi_diff() -- the interface method used by git to interact with xdiff's diffing functionality
2. xdiff/xdiff.c -> xdl_diff() -- sets up initial diff requirements, decides whether or not to use patience
3. xdiff/xdiff.c -> xdl_do_diff() -- sets up more specific requirements for diff stuff
4. xdiff/xdiff.c -> xdl_recs_cmp() -- diffs and passes diff into the diffdata_t parameters, method name means "recursively compare" FYI

Love, Alex and Andrew

[hausdorf]

@kyeana, you were talking about windows/unix interface. Just FYI, the win32/ folder I think houses the official windows interface, while the unix/ folder houses the unix stuff.

[hausdorf]

Addendum: they both appear to implement the map.h file from src/. So my guess is you can just access the windows or unix API through the interface defined in map.h and let a #define or something handle which file it is that you compile that for. Or maybe that's actually handled by waf. I dunno.

[hausdorf]

Also, it appears that you can access this functionality via src/dir.h.