Hacker News Reader

Comment by jdpage | Hacker News Reader

That's exactly what git add -p does, and it's vastly more convenient than when you don't have a staging area.

I find the problem with git add -p is when you have changes that are overlapping - e.g. you've tried a few variations of implementing something, that have many commonalities - but sadly you didn't commit them as you went along, but now what to, for reference in case they are needed later.

git add -p doesn't help tease them apart, because its hunks are based on diffs, and the granularity usually does not coincide with actual changes (nor syntax or semantics of the languages). Which is really expecting a bit too much! Diff's implementation of LCS algorithm is incredibly fast and works amazingly well for changes in different places.

So what I do is edit the file to what I want, stage and commit, then undo and continue. This doesn't really use the staging area, and I'm hoping there's a better way to do it... if anyone can think of one?

I don't use `git add -p` much, since i commit exclusively with `git gui`. The reason being that `git gui` allows me to stage single lines, or hunks AND allows me to change the granularity of hunks on the fly. Even if that isn't an option for you, i'm sure that `git add -p` has a command to modify hunk granilarity.

One thing that I've found handy on a few occasions is Atlassian Source Tree. You can stage individual lines, not just individual hunks. Sometimes that makes it much easier to pull apart the changes.

git add -p, then "s" until it can't split the hunk any more, then "e" to edit the hunk manually?

you can do it, but I've found in some cases that modifying patches (including "e") becomes more complex than stating the desired result directly.

Reply on news.ycombinator.com