Unexpected behaviour with git stash save --keep-index?

Hello all,

while I was using StGit for the first time and used git stash to split the changes into different patches I noticed that git stash save -- keep-index will stash also the changes that are already in the index. This was unexpected atleast to me but maybe someone can explain why it's correct.

The following sequence should illustrate the problem. Notice how both the b and c are popped from the stash.

git init echo a > test.txt git add test.txt git commit -m "a" echo b >> test.txt git add test.txt echo c >> test.txt git stash save --keep-index git commit -m "b" git checkout -b new_branch HEAD^ git stash pop git diff

Also maybe someone could someone recommend a way to split an unclean working dir into several patches/commits?

With regards

Jonas

Hi,

On Tue, Sep 02, 2008 at 01:14:10AM +0200, Jonas Flodén wrote:

A plain 'git stash [save]' means "save all local modifications and clear both the index and the working tree".

'git stash save --keep-index' means "save all local modifications and remove all modifications from the working tree that are not in the index". This differs substantially from "save only those modifications that are not in the index, and then remove them from the working tree".

The workflow described at the end of stash's man page (under 'Testing partial commits') works well for me.

(Heh, I have just looked that section up, and noticed that the formatting is broken and some comments are missing from the man page. I will send out a patch in a minute.)

Regards, Gábor

Asciidoc removes lines starting with a dot when creating manpages. Since those lines were comments in use case examples showing shell commands, preceed those lines with a hash sign.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
 Documentation/git-stash.txt |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

There is no need to explicitly pass the file to be committed to 'git commit', because it's contents is already in the index.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---

  Ah, and one more small change in stash docs.

 Documentation/git-stash.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

SZEDER Gábor wrote:
 > 'git stash save --keep-index' means "save all local modifications and
 >  remove all modifications from the working tree that are not in the
 > index".  This differs substantially from "save only those
 > modifications that are not in the index, and then remove them from
 > the working tree".
 >

Thanks for the explanation. It seemed strange first but now I know why it does that.

 >> Also maybe someone could someone recommend a way to split an
 >> unclean working dir into several patches/commits?
 > The workflow described at the end of stash's man page (under 'Testing
 >  partial commits') works well for me.
 >

Thanks. What about the case when I already have a number of existing patches/commits and want to split the working dir into them.

Regards, Jonas

On 2008-09-02 01:14:10 +0200, Jonas Flodén wrote:

[...]

This is what I usually do:

  1. Create a new StGit patch with all the changes.

  2. Pop that patch.

  3. View the patch in an emacs diff-mode buffer, and repeatedly

       a. apply one or more hunks, and

       b. create a new patch with just those changes

     until no more changes remain.

Another way to do it would be to

  1. Use e.g. git-gui to stage the changes you want in your first
     patch.

  2. Make an StGit patch out of just that (with e.g. stg new and stg
     refresh --index).

  3. If the worktree is still dirty, go to step 1.

A third method I usually make use of is to commit very often while developing, and periodically clump these microcommits together into larger commits. This sidesteps the whole problem of splitting up a commit into pieces, which can be quite a chore if splitting on hunk boundaries isn't enough. (stg coalesce will turn two or more smaller patches into one large patch for you. And I'm pretty sure git-rebase --interactive has some equivalent functions.)