threads / discuss / 16771

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

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

## tl;dr

7 messages between Dec 17, 2008 and Dec 18, 2008.

replies: 6people: 3as markdown or json

Tim Visher· Dec 17, 2008, 19:57 UTC · lore
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
Junio C Hamano· Dec 17, 2008, 20:30 UTC · re: Tim Visher · lore

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

"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".
Tim Visher· Dec 17, 2008, 22:48 UTC · re: Junio C Hamano · lore

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

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.

Show 11 quoted lines
> , 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
Junio C Hamano· Dec 17, 2008, 22:59 UTC · re: Tim Visher · lore

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

"Tim Visher" <tim.visher@gmail.com> writes:
Show 14 quoted lines
> 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.

Tim Visher· Dec 18, 2008, 01:22 UTC · re: Junio C Hamano · lore

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

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
Nanako Shiraishi· Dec 18, 2008, 03:34 UTC · re: Tim Visher · lore

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

Quoting "Tim Visher" <tim.visher@gmail.com>:
Show 7 quoted lines
> 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/
Tim Visher· Dec 18, 2008, 12:24 UTC · re: Nanako Shiraishi · lore

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

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.
Show 6 quoted lines
>  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

← back to recent threads