search

prati0100 / git-gui

Tcl/Tk based UI for Git. I am currently acting as the project's maintainer.
161 stars 87 forks source link

Implement "git gui diff" and "git gui merge" #16

Open jnareb opened 4 years ago

jnareb commented 4 years ago

This would help close the gap in git-gui functionality. The code to display side-by-side diff, and to perform chunk-by-chunk merge can be borrowed from tkdiff.

prati0100 commented 4 years ago

Just so we are on the same page, would git gui diff and git gui merge be separate sub-tools (like git gui blame and git gui browse for example)? Or should they somehow integrate with the "main" git-gui UI?

As of now, git-gui does show diff of the current repo state (IOW, the working directory and index). My guess is that you want git gui diff to work similar to git diff, where it can take two points or revision ranges and show the diff between them, correct? That would be neat, but would require a new stripped-down UI. Sure, you can probably use some of the pre-existing elements, but a lot of the UI would have to be created. Not that its a bad thing, I'm just pointing it out.

As for git gui merge, I'm not sure a separate tool is really needed. It probably makes more sense to just add features like side-by-side diffs to the main UI. We do already support making merges via the UI, so I don't think much more has to be done there.

This response is largely an attempt to elicit more information so I completely understand your suggestion. Correct me if I interpret something incorrectly.i

jnareb commented 4 years ago

I was thinking about a single separate sub-tool (like git gui blame) for both git gui diff and git gui merge; it's just that in merge mode the tool would have one more pane and different set of actions.

What I would like is to be able to set up git-gui in diff and merge modes as diff.tool (or diff.guitool) and/or merge.tool (or merge.guitool).

prati0100 commented 4 years ago

A single sub-tool for diff would be great. But with merge, we would have a lot of duplication since similar merge conflict resolution and highlighting features need to be present in the main UI too. A lot of procedures would probably end up being re-used though, so maybe that is something we should debate over when there is a working implementation.