PATCH] Documentation: Tweak use case in "git stash save --keep-index"

PATCH] Documentation: Tweak use case in "git stash save --keep-index"

[Eric Raible]

The documentation suggests using "git stash apply" in the
--keep-index workflow even though doing so will lead to clutter
in the stash.  And given that the changes are about to be
committed anyway "git stash pop" is more sensible.

Additionally the text preceeding the example claims that it
works for "two or more commits", but the example itself is
really tailored for just two.  Expanding it just a little
makes it clear how the procedure generalizes to N commits.

Signed-off-by: Eric Raible <raible@gmail.com>
---
Note that this is relative to Junio's pu branch (v1.5.6.2-397-g20210bb)

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

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index df26901..bf241da 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -201,9 +201,10 @@ $ git add --patch foo
 $ git stash save --keep-index
 $ build && run tests
 $ git commit -m 'First part'
-$ git stash apply
+$ git stash pop
+... repeat above five steps until one commit remains ...
 $ build && run tests
-$ git commit -a -m 'Second part'
+$ git commit foo -m 'Remaining parts'
 ----------------------------------------------------------------

 SEE ALSO
-- 
1.5.6.1.1073.g489ff.dirty

Re: PATCH] Documentation: Tweak use case in "git stash save --keep-index"

[Junio C Hamano]

"Eric Raible" <raible@gmail.com> writes:

> The documentation suggests using "git stash apply" in the
> --keep-index workflow even though doing so will lead to clutter
> in the stash.  And given that the changes are about to be
> committed anyway "git stash pop" is more sensible.

Yeah, I was pondering about this myself.  After popping the remaining
part, you would "git add -p" the next batch, the same "stash save -k-i" to
save the remaining bits away, and continue.  Will queue.

BUT

It is very likely that in this workflow you would sometimes find that what
you staged (and left in the working tree after "save -k-i") is faulty and
you need to tweak it in place to make it into a good enough shape for
committing.  The example probably should talk about what happens.
Editing, testing and committing is fine, but then what?  Will the "pop"
wipe that unplanned change you made after "save -k-i" out? (the answer is
no and this is safe, but the reader of the documentaiton needs it
explained)

Also this may be a good way to split an existing commit into five during a
"rebase -i" session, and the example in the documentation might want to
talk about it in that larger picture.

>  Documentation/git-stash.txt |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index df26901..bf241da 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -201,9 +201,10 @@ $ git add --patch foo
>  $ git stash save --keep-index
>  $ build && run tests
>  $ git commit -m 'First part'
> -$ git stash apply
> +$ git stash pop
> +... repeat above five steps until one commit remains ...
>  $ build && run tests
> -$ git commit -a -m 'Second part'
> +$ git commit foo -m 'Remaining parts'
>  ----------------------------------------------------------------

Re: PATCH] Documentation: Tweak use case in "git stash save --keep-index"

[Eric Raible]

The documentation suggests using "git stash apply" in the
--keep-index workflow even though doing so will lead to clutter
in the stash.  And given that the changes are about to be
committed anyway "git stash pop" is more sensible.

Additionally the text preceeding the example claims that it
works for "two or more commits", but the example itself is
really tailored for just two.  Expanding it just a little
makes it clear how the procedure generalizes to N commits.

Finally the example is annotated with some commentary to
explain things on a line-by-line basis.
---
[Note: If we can't rely on fixed-width fonts then the resulting
example will look stupid]

On Mon, Jul 7, 2008 at 10:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Also this may be a good way to split an existing commit into five during a
> "rebase -i" session, and the example in the documentation might want to
> talk about it in that larger picture.

If you're talking about 'edit' mode, doing a "reset HEAD^", and then
using the same "add --patch"/"stash save -k-i"/commit/"stash pop"
cycle in question then I understand and agree.  But only if the
user wants to test each part separately.

Otherwise why bother with stash-k-i when you can just loop
on add-patch/commit or use git-gui?
--
 Documentation/git-stash.txt |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index df26901..7d50d74 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -197,13 +197,14 @@ each change before committing:
 +
 ----------------------------------------------------------------
 ... hack hack hack ...
-$ git add --patch foo
-$ git stash save --keep-index
-$ build && run tests
-$ git commit -m 'First part'
-$ git stash apply
-$ build && run tests
-$ git commit -a -m 'Second part'
+$ git add --patch foo            # add just first part to the index
+$ git stash save --keep-index    # save all other changes to the stash
+$ edit/build/test first part
+$ git commit foo -m 'First part' # commit fully tested change
+$ git stash pop                  # prepare to work on all other changes
+... repeat above five steps until one commit remains ...
+$ edit/build/test remaining parts
+$ git commit foo -m 'Remaining parts'
 ----------------------------------------------------------------

 SEE ALSO
-- 
1.5.6.1.1073.g489ff.dirty