Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

[Tim Visher]

Hello Everyone,

I'm attempting to use `git add -i` to help me resolve the differences
between two files in a way that makes sense (leaving class names, some
logic, but changing other things like white space, etc.).  I have all
of the changes that I want to be committed staged now in the index.
My question is this: is it possible to revert the changes that I
haven't staged so that the file looks as if everything inside of it
has been staged because none of the stuff I didn't stage is there
anymore.

Thanks in advance!

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

[Junio C Hamano]

"Tim Visher" <tim.visher@gmail.com> writes:

> My question is this: is it possible to revert the changes that I
> haven't staged so that the file looks as if everything inside of it
> has been staged because none of the stuff I didn't stage is there
> anymore.

The last part of the sentence after "because" does not parse for me at
all, but I think you are after one of the following:

 (1) if you want to get rid of garbage changes in your work tree, you
     would want "git checkout $that_path";

 (2) if you want to temporarily stash away further changes in your work
     tree, because you would want to first test what is staged, commit it,
     and then later continue to refine the changes stashed away thusly,
     you would want "git stash --keep-index".

Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

[Tim Visher]

On Wed, Dec 17, 2008 at 3:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The last part of the sentence after "because" does not parse for me at
> all...

Sorry for the double/triple/quadruple negatives I threw in there.
Makes the statement incredibly unclear.

> , but I think you are after one of the following:
>
>  (1) if you want to get rid of garbage changes in your work tree, you
>     would want "git checkout $that_path";
>
>  (2) if you want to temporarily stash away further changes in your work
>     tree, because you would want to first test what is staged, commit it,
>     and then later continue to refine the changes stashed away thusly,
>     you would want "git stash --keep-index".
>
>

If I could attempt to make my situation a little clearer.

I had two very similar files (I know, I know, DRY, blah blah. :\ It's
not my source tree to begin with... bleh) and I wanted to duplicate a
bunch of simple edits (adding white space, comments, etc.) from one of
them to the other without having to manually compare them.

Then, a light bulb went off in my head and I thought to myself that it
would make a ton of sense to use `git add -i` to add only the changes
that I wanted to the files and leave the stuff I wanted to be
different between the two of them out.  I `cp`ed the edited file over
the other file and then fired up `git add -i` and proceeded to stage
all of the edits that I wanted.  This left me with a staged version of
the file that was exactly what I wanted and a locally modified file
with contents that I didn't want.  However, the changes were still
untested.

What I wanted to do was basically get rid of the unstaged edits on
this file but keep the staged ones.  Without committing.

Unfortunately I couldn't figure out how to do this.  The solution I
came up with was to go ahead and `git commit` the staged changes and
then `git checkout PATH` the just committed file to overwrite the
local edits with the version of the file I wanted.

I want to know if it was possible to accomplish this without the commit stage.

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

[Junio C Hamano]

"Tim Visher" <tim.visher@gmail.com> writes:

> On Wed, Dec 17, 2008 at 3:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>>  (1) if you want to get rid of garbage changes in your work tree, you
>>     would want "git checkout $that_path";
>>
>>  (2) if you want to temporarily stash away further changes in your work
>>     tree, because you would want to first test what is staged, commit it,
>>     and then later continue to refine the changes stashed away thusly,
>>     you would want "git stash --keep-index".
> ...
> Unfortunately I couldn't figure out how to do this.  The solution I
> came up with was to go ahead and `git commit` the staged changes and
> then `git checkout PATH` the just committed file to overwrite the
> local edits with the version of the file I wanted.

How about omitting the "git commit" and do "git checkout PATH" after you
are done with the staging?  IOW, (1) above.

Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

[Tim Visher]

On Wed, Dec 17, 2008 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> How about omitting the "git commit" and do "git checkout PATH" after you
> are done with the staging?  IOW, (1) above.

Huh.  I guess I was under the impression that doing the `git checkout
PATH` would destroy the staged content as well as the unstaged.  This
isn't the case?

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

[Nanako Shiraishi]

Quoting "Tim Visher" <tim.visher@gmail.com>:

> On Wed, Dec 17, 2008 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> How about omitting the "git commit" and do "git checkout PATH" after you
>> are done with the staging?  IOW, (1) above.
>
> Huh.  I guess I was under the impression that doing the `git checkout
> PATH` would destroy the staged content as well as the unstaged.  This
> isn't the case?

A short answer is "no it is not the case."

I was about to quote "git checkout" documentation to you because I was reasonably sure that Junio won't respond to people who ask a question whose answer is plainly described in the manual pages, but I think the description of the command is a little confusing especially for people who read it for the first time.

This is a patch to clarify the sentence.

-- 8< -- Cut Here -- 8< --
Subject: Clarify documentation of "git checkout <tree-ish> paths" syntax

The SYNOPSIS section of the manual writes:

    git checkout [options] [<tree-ish>] [--] <paths>...

but the DESCRIPTION says that this form checks the paths out "from the
index, or from a named commit."  A later sentence refers to the same
argument as "<tree-ish> argument", but it is not clear that these two
sentences are talking about the same command line argument for first-time
readers.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---

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

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 168333a..bbdfa40 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -27,7 +27,7 @@ the first namespace level.
 
 When <paths> are given, this command does *not* switch
 branches.  It updates the named paths in the working tree from
-the index file, or from a named commit.  In
+the index file, or from a named <tree-ish> (most often a commit).  In
 this case, the `-b` options is meaningless and giving
 either of them results in an error.  <tree-ish> argument can be
 used to specify a specific tree-ish (i.e. commit, tag or tree)








-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?

[Tim Visher]

On Wed, Dec 17, 2008 at 10:34 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:

> A short answer is "no it is not the case."

Thanks.

> I was about to quote "git checkout" documentation to you because I was reasonably sure that Junio won't respond to people who ask a question whose answer is plainly described in the manual pages, but I think the description of the command is a little confusing especially for people who read it for the first time.

Agreed.

>  When <paths> are given, this command does *not* switch
>  branches.  It updates the named paths in the working tree from
>  the index file, or from a named <tree-ish> (most often a commit).  In
>  this case, the `-b` options is meaningless and giving
>  either of them results in an error.  <tree-ish> argument can be
>  used to specify a specific tree-ish (i.e. commit, tag or tree)

Works a lot better.

Thanks for the help!

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail