Hacker News Reader

Comment by dasil003 | Hacker News Reader

You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks.

I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split.

However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don't want to use whatever shitty editor your tool has in it, I want to use vim with syntax highlighting so I can properly format my commit messages. Even something as simple as viewing a full commit is faster in the CLI because you can just pipe it to less or send it to an editor versus whatever tradeoffs a GUI has to make to stay performant, make use of screen space, etc.

One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

View on HN

> committing single lines from hunks that can't be split.

Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before.

Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

`git add -p` adds by the hunk, which is a unit of quantization bigger than a line.

E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk".

(Waiting for someone to chime in with how to split a hunk and change my life).

You use the 'e' option which allows you to edit the hunk. Remove the minus sign or the entire line with a '+'

You can use 's' to split a hunk but it would indeed not work if you want to split two consecutive lines.

You can also use 'e' option to edit the hunk to e.g. remove one of the added line.

Nothing as easy as clicking a line in a GUI though.

Within 'git add -p' when you get to the hunk that you want to edit (split down to single lines), press 'e'. This will open an editor (vim in my case) which lets you edit the diff manually.

In there you can remove added lines (prefixed by '+') by removing them, and re-adding removed lines (prefixed by '-') by replacing the '-' with a space ' '.

And how is this faster/better than selecting a line with the mouse and pressing s without opening any other editor?

Do it in Vim (or emacs for those weirdos out there) and you're done before you would've even reached the mouse :)

Sometimes your changes are across multiple files, and it's easier to say, "yes, yes, yes, yes, split, no, no, yes, ..."

Say you have 3 sequential lines, but you only want to stage the middle one. You can’t split it into smaller hunks by hitting ‘s’ during ‘git add -p’. I’m sure there’s a way I’m just not familiar with but I just use Sourcetree for this on the rare occasion it occurs.

You can split hunks manually by editing (hit “e” instead of “s” during staging). I end up doing this fairly regularly.

i think that’s his point? there’s a huge amount of useful, but advanced functionality in the git CLI

As mentioned before, manual edits can be made at that point. However I'll add that for this use case, a tool integrated in your editor will often be more adapted to manual staging. I have Tim Pope's vim-fugitive plugin in mind which is a quite wonderful way of using Git.

You can also manually edit the hunk to remove the 2 lines you don't want to stage and use the recountdiff utility to update the hunk header.

  > Fugitive

That's interesting. I switched back from emacs to vim (neovim), and fugitive was recommended. it just looked like :commands for the normal git cli... maybe I missed something.

So even though I edit in vim, I jump back to emacs for magit for bigger commits or multiple smaller commits (where I need to see diffs to be sure I capture my changes).

I have desired something as useful in vim, but I didn't think there was anything. I'll take another look at fugitive.

Yeah, fugitive seems pointless to me. Might as well just use the git cli...which I do, but when I want something quicker to navigate/visualize, magit is my go to.

See my comment in sibling thread. I am not familiar with Magit, but there's no equivalent on the CLI to Fugitive's flow for rapidly traversing history, it's really really useful, and lets me answer questions that other devs on the team just throw up their hands because a line may have traversed several different files over dozens of commits throughout its history. The reason it can't be done on the CLI is because you need multiple buffers and window management to make it viable.

All that said, I don't really use it for committing, mostly because I have a shell open right next to the editor anyway.

You may want to give a try to vimagit so. https://github.com/jreybert/vimagit/

As soon I started to work with git, I installed fugitive. My learning curve of fugitive has been slow, and I have never be able to stage efficiently with it.

And then, a colleague showed me magit: I waited for a year that something similar comes to vim, trying to push this idea to fugitive https://github.com/tpope/vim-fugitive/issues/569 , without success.

Finally, some first experiments showed that partial hunk stage was feasible, and I created vimagit.

As you will see, it is far from whole magit features. For the moment, it "only" focuses on stage/unstage and commit feature (which is the main use case to me). The current workflow is quite robust: you can easily navigate through all the diffs to review them, stage by file/hunk/line/part of line, write the commit message (or amend the last commit), jump to the diff locations in their files... I continue to use fugitive for Gblame and Gdiff.

Next major features should be git stash (be able to prepare a stash like a commit, by file/hunk/line) and some git log related feature (to easily git commit --fixup a chosen commit in a log for example).

> One last tool is Fugitive. This blows away anything else I've ever seen for interactively traversing history at the line level.

Sorry if I'm being think, but how do you do that? Are you talking about Gblame?

Yes, Gblame then in the blame pane ‘o’ to open the commit, then in the commit pane navigate to a file name and ‘o’ to open the old file, then rinse and repeat. You can trace line history across files this way.

Reply on news.ycombinator.com