views:

764

answers:

1

I just created a big piece of code I want to commit in several separate commits.
So I can stage relevant parts, commit, stage, commit, ... and so on until I have all my changes commited.

The missing part is how can I test whether I split the commit correcty.
I.e. whether the part that is in staging area at least compiles?

To do that I must somehow bring my work tree to be in sync with index (staging area) without losing the changes to be committed later.

What is the right way to do it?
What is the quickest way to do it?

Update:
How to do it with magit?

+4  A: 

You could do it with:

$ git branch task1 # first set of commit to do

An intermediate branch can be useful to record some intermediate commits when you are slowly adding some content to the index.

Then try an interactive session for adding just what you want:

$ git add -i

Add any time you want to check what you have added:

$ git stash --keep-index

If it compiles, git commit your current work, and if task1 is not yet complete, git stash pop to restore the full working tree and repeat.

Once task1 is fully baked, you can trim all those 'taks1' commits, and merge the all work in master:

$ git checkout master
$ git merge task1
$ git branch -D task1 # no need for that intermediate branch

If you want to conserve the history of some significant task1 commits, you can rebase first taks1 on top of master, before merging master in task1 (fast-forward)

Finally, if your stash still contains some work in progress, repeat the all process for task2.

VonC
git stash --keep-index is exactly what I needed.
Łukasz Lew
--keep-index is new to me as well. Thanks and +1
Noufal Ibrahim
@VonC: Great explanation. This (and `git-rebase -i) is one of the things I really love about using Git and I do this sort of thing all the time. It gives you the ability to *craft* your commits so that they make sense and contain only relevant (related) changes.
Dan Moulding