10

Sometimes I work on system without X Window installed, and can't use Git GUI.

What are existing console alternatives to the git add -p?

I like almost everything that it does (more than Git GUI actually), but I hate that it does not let me view the whole picture and choose the order that I want to review the chunks. That's the only actual advantage of Git GUI over git add -p to me, but it is rather crucial one.

I tried tig, but I do not like the user experience that it offers.

Any suggestions?

Alexander Gladysh
  • 39,865
  • 32
  • 103
  • 160
  • Are you aware of the 'g' command? It's certainly less than ideal, but it does give you a list of all hunks and the ability to move to a particular hunk (effectively letting you choose the order). – William Pursell May 02 '11 at 14:37
  • I am aware of it, but it is not good enough — I need to see all hunks in a file as whole to decide if I want to commit them now. – Alexander Gladysh May 04 '11 at 02:29

3 Answers3

19

Vim has a plugin 'fugitive'

Edit: the linked vimcast (comments) is excellent and I recommend it. I would like to add the hint that there will normally not be a need to type :diffget and :diffput in longhand, because you can do he same directly in normal/visual mode by pression do and dp.

The best command to start with for this feature appears to be :Gstatus

Vim is a terminal editor (which so happens to have a gui port too)

The fugitive plugin will simply let you edit the index and worktree versions of files alongside each other and let you diffput/diffobtain until you're satisfied. Vim's diff mode is sophisticated, and much more flexible/intuitive than git add --patch.

  • scrollbinding
  • syntax highlighting and intra-line (wordlevel) diff highlighting simultaneously
  • automatic diff folding (of unchanged regions)

You can get fugitive here

Snippet from :he fugitive:

Edit a file in the work tree and make some changes. Use |:Gdiff| to open up the indexed version. Use |do| and |dp| on various hunks to bring the files in sync, or use |:Gread| to pull in all changes. Write the indexed version to stage the file.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Have you ever looked at fugitive? - That said, I'm pretty sure Emacs will have a diff mode, being a general purpose editor – sehe May 02 '11 at 06:26
  • 3
    There is also a recent [Vimcast that demonstrates fugitive’s `git add --patch` equivalents](http://vimcasts.org/episodes/fugitive-vim-working-with-the-git-index/). – Chris Johnsen May 07 '11 at 05:37
0

what about a simple

git diff

to "view the whole picture" and then a

git add -i
5

to chose the first file you want to commit, stage the hunks, and then repeat the process with the next files?

Markus
  • 5,667
  • 4
  • 48
  • 64
  • 1
    does the '5' have a meaning there? – sehe May 01 '11 at 21:56
  • 1
    I'd like to be able to do all of this simultaneously. Often I have several series of uncommitted hunks sitting in several different files (that would be one series per commit). Running through `git add -p` loop for each one each time is rather tedious. Also this use of `git add -i` is the same as using actual file name in `git add -p` invocation, not much improvement. – Alexander Gladysh May 01 '11 at 21:58
  • @sehe: that's a file list menu item number. – Alexander Gladysh May 01 '11 at 21:58
  • @Alexander Gladysh: I'm not sure what you mean - thought of giving you some more overview by `git add -i` (e.g. seeing lines of codes changed). And yes, you have to call `git add -i` and `git commit` for every different/next commit, but that's how git works. What do you mean precisely with to do "all simultaneously"? – Markus May 01 '11 at 22:14
  • @markus: Say, I have 5 changed files with changes for 3 different commits, spread randomly through all files. I want to be able to see diff for a file and pick hunks for each commit at the same time, as Git GUI allows me to. That is, random access. But `git add -p`allow sequental access only, from top to bottom of the file. And I can't switch between files during the process. Not very convenient to use. – Alexander Gladysh May 01 '11 at 23:47
  • 1
    @Alexander Gladysh: Then you're out of luck with me. The only other hint I can give you, is to change your coding style to do changes for only one and small commit at a time and commit them before you start working on the next commit. Then you don't need to delegate changes to different commits, and that's more the philosophy of git: do one thing at a time. Make small commits. If you work on different things, create a temp-branch for each. Merge/Rebase them accordingly. – Markus May 02 '11 at 09:44
  • @markus: Makes sense, but sometimes it is just not practical to interrupt "The Flow" just to stop and make the commit. – Alexander Gladysh May 02 '11 at 15:20
0

If I were in the same situation as you (a mix of hunks where some hunks are 'more important' than others), I'd commit the lesser hunks into their own commits with easily distinguishable commit message and leave only those 'more important' hunks so that they don't get in the way of diffs, or git add -i.

With the easily distinguishable commit messages for the "less privileged" hunks it should be easy to deal with them later.

holygeek
  • 15,653
  • 1
  • 40
  • 50