Hacker News Reader

Comment by jumpwah | Hacker News Reader

With magit, it's easy to only stage individual 'hunks' so that you can have only the relevant parts of a file staged. And so this problem goes away.

I also imagine it's easy to do this in fugitive as well.

It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.

View on HN

>It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.

I do it all the time, you just use `git add -p` and it steps through hunks letting you stage them or not. As long as you don't make too many changes without committing, it's not particularly tedious.

Sweet! I never bothered to check how to do it on the cli, and instead of being interactive, I just assumed you would have to reference the hunks by line number or something. Naive of me.

It also works with reset and checkout, BTW.

Wow thank you. I had no idea that was something you could do!

I recommend setting up a shell alias to do this. I have all of my frequently used git commands aliased to two- or three-letter mnemonics.

This was the 'killer app' that compelled me to switch to Git from Subversion back in the day, rather than anything else about Git intrinsically. The ability to organise my commits logically rather than temporally (i.e. not just as a stupid log of change over time) was like night and day.

> ability to organise my commits logically rather than temporally

I'm just getting started with Git; how do you do that? I googled it but nothing jumped out at me.

He referred to what the GP said - use "git add -p". Here's some introduction (I haven't watched it myself and can't comment on the quality):

http://johnkary.net/blog/git-add-p-the-most-powerful-git-fea...

You can simply use `git add -p` to stage hunks individually (or `git reset -p` to unstage some hunks).

And `git checkout -p` to erase hunks from the working directory. (i.e. delete without saving!)

That's a little dangerous! I use git stash -p instead, and only drop it after I'm absolutely sure.

"git add -p" can be fun, but it's a little scary because it's super easy to end up making commits that don't actually stand on their own. Super simple to miss an import here or a new field there. If you do a whole series of them, it might actually be worse for others to come back to (or bisect in) if they don't realize the original developer never actually compiled and tested each commit as-is.

Well ideally you could use `git stash -k -u` (-keep index, stash -untracked) to set your working directory to the state you're actually committing, and then run some tests.

For the most part though, I just try to avoid having so many hunks to step through that this is even an issue.

> It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.

It's extremely easy. git add -p and then you can select to add the hunk or not.

The UI for this in SourceTree is also really nice. Actually my favorite thing about ST is that I learned so much more about git from using it.

This, in my opinion, is one of the very compelling reasons to use a GUI for these types of operations.

As an example, refactoring something that touches many files often leads to several related/required changes that aren't part of the main refactor. When you first do the change, you're not 100% sure it will stay around, and committing at this point can be a pain later. As a result, you can end up with many files changed and several logical units of work done, and some may be [parts of] a single file, while some may be [parts of] many files. For 5 or 6 hunks, git CLI is usable. Beyond that, for say, a hundred, a UI where you can jump around is basically essential in order to make usable commits.

I know there are still people that snobbily look down on and dismiss GUI tools, but some things lend themselves well to GUI, so I'd suggest giving them a try.

SourceTree in particular works seamlessly with CLI. When I first started with it (being used to git CLI), I jumped back and forth quite a bit with no issue. Now I really only use git CLI for remote branch operations or viewing reflog, and occasionally for a 'git commit -am' if I happen to already be in a shell.

The other thing for me is that git is inherently very very stateful. There's tons of detail to keep in mind as you execute commands - your branch, what's staged or isn't, the state of the remotes, whether you have anything stashed, etc. To me that's a recipe for a tool that should be used through a GUI.

Reply on news.ycombinator.com