0

Sometimes I end up with a working tree with a lot of changes, mainly after coding in a hurry - the changes are so many that could fit in 20 commits, spread across 2 or three branches. To clean up the working tree and commit everything nicely, I follow this unpleasant workflow:

  1. Use git add -p to inspect all the hunks in the working tree, without saving anything to the index (i.e. answer "no, don't stage this" to every hunk). Meanwhile, I try to mentally group the hunks into commits, and take some notes (in a text file) of the commits I should build with the hunks I'm seeing.

  2. After I've assigned every hunk to a commit (in my notes), then I start git add -p again, and answer "yes, stage this" only to the hunks that go into the first commit. After going over all the hunks and picking the ones I want, I actually do the commit.

  3. Repeat at step 2 as long as there are hunks left in git add -p. This means that I go over all the hunks, for every commit I have in my notes.

This is obviously a very silly way of dealing with many changes at once. Is there a good way of starting with many changes, sorting them out and then ending up with a nice set of commits, in their right branches?

Maybe there is a way to incrementally build multiple commits, simultaneously, in multiple indexes. Or maybe I should commit all the changes into one big commit, then split it into multiple ones somehow? Or maybe there's a way to (ab)use git stash to help in grouping changes together?

SQB
  • 3,926
  • 2
  • 28
  • 49
CamilB
  • 1,377
  • 1
  • 12
  • 27
  • 2
    I don't think, there is much wrong about this workflow apart I basically never use notes. But I like `git citool` for visually selecting the files or lines of files to include in each separate commit. And yes, like noted below `git rebase -i`, sometimes in conjunction with `git commit --fixup` or `git commit --squash` helps ordering things. – Tilman Vogel Apr 27 '13 at 20:23
  • Ah, and in the end, you could switch to your topic branches and `git cherry-pick` the respective commits from your "work branch". – Tilman Vogel Apr 27 '13 at 20:25

3 Answers3

2

Not much of an improvement, but you could start adding files to the first commit during step one, even if that does not end up to be the first commit you really want to have, since you can finish by reordering your commits with an interactive rebase.

Klas Mellbourn
  • 42,571
  • 24
  • 140
  • 158
  • I didn't know about interactive rebase. I guess I can first checkout to a new branch, commit things in whatever order I can, reorder them with interactive rebase (maybe squash some too), and at last merge with fast-forward into the original branch, pretending I never branched/squashed/performed surgery on commits. I'll look more into reordering commits. It is an improvement, since I don't have to keep the list of "potential commits". – CamilB Apr 27 '13 at 19:02
  • Yeah, interactive rebase gives you a lot of freedom. You can split commits too. So you might create a "miscellaneous" commit of changes that you wait until the rebase to split up. – Klas Mellbourn Apr 27 '13 at 19:13
0

You are going against the typical workflow of git add

It typically adds the current content of existing paths as a whole, but
with some options it can also be used to add content with only part of
the changes made to the working tree files applied.

git add -p is there to "bail you out", but you should not be repeatedly using this workflow to where you need multiple indexes to accomodate it. Use Git as it is meant to be used.

Zombo
  • 1
  • 62
  • 391
  • 407
  • I'm afraid I don't understand the answer... I know `git add` adds an entire file to the index. I don't want to do that, since I have changes pertaining to many potential commits in one file. That's why I'm using `git add -p`. First, only to figure out what "potential commits" I can make out of all the changes in the working tree, and then, later, to actually build these commits. – CamilB Apr 27 '13 at 17:29
  • Also, what do you mean by _"[it] is there to «bail you out», but you should not be repeatedly using this workflow to where you need multiple indexes to accomodate it"_? I know I'm doing it wrong, that's why I'm asking for alternatives. I want to clean up my working tree, with or without multiple indexes. I should update the title to say this... – CamilB Apr 27 '13 at 17:36
  • How is Git meant to be used when you have many changes in the working tree and you want to turn them into clean commits? I've edited the question and title to emphasize on this particular situation. I want to stop doing this, so I must do something else. What exactly should I do? – CamilB Apr 27 '13 at 17:47
  • I know. I hate it when it happens. I love a clean repo, and a log that reads like a story. But sometimes all goes wrong, my time ran out and I had to skip doing the version control. But now I have the time to clean up the mess and finish the story. Please stop telling me "don't do it". I know. I don't do it. It's **not my normal workflow**. It was an emergency, it is now over, and now I want to tidy up the working tree. – CamilB Apr 27 '13 at 18:12
  • I think you're reading too much intent into the manpage. git-add defaults to assuming the file you want to stage is precisely the one in the working tree and it gives you the option of staging subsets of the difference between the index and working tree by using -p. In my opinion this does not imply a recommended workflow of religiously staging precisely what is in your working directory. Developers are humans who might want to fix a typo while implementing a new widget. So thet git add -p and commit then they switch to the typofixes branch and git add -p the typo fix there. No big deal IMO. – JosefAssad Apr 27 '13 at 18:30
  • @StevenPenny Should I understand that relying too much on `git add -p` is frowned upon? What would be the reasons? – CamilB Apr 27 '13 at 19:07
  • @JosefAssad I agree, `git add -p` is a great tool. I also think it's very good for reviewing changes in the working tree too, since in the CLI, the hunks given by `git add -p` are far more readable than the full output of `git diff`. – CamilB Apr 27 '13 at 19:08
0

If you can slightly modify your workflow such that:

  1. you have multiple 'features' implemented in multiple files, but
  2. you don't have multiple 'features' implemented in one file

then you could use:

git commit -m 'feature 1' -- foo.c bar.c
git commit -m 'feature 2' -- bing.c bang.c
...

This avoids the entire 'hunk' problem - but it requires you to change your workflow.

Note that the 'git way' for this is to create a branch for each feature, to develop each feature independently, to merge all the features back in.

GoZoner
  • 67,920
  • 20
  • 95
  • 145
  • 2
    My features are well divided into modules, nice and hierarchically. I commit changes properly, using the "git way", with branches per features and all that. But sometimes, when there's a rush, I don't do any version control, and just code away. This way, many changes accumulate. It happens occasionally. This isn't a normal situation. Normally, I change a file for one reason, and that results in one commit. But in these situations, many changes pile up in a file, and they were done with different, unrelated purposes in mind. They do fit in single commits. But they're _many_. – CamilB Apr 27 '13 at 18:01