tools for easily "uncommitting" parts of a patch I just commited?

tools for easily "uncommitting" parts of a patch I just commited?

[Jacob Keller]

Hi,

I recently (and in the past) had an issue where I was using git add
--interactive and accidentally did something like the following:

# hack lots of randmo changes, then begin trying to commit then separately
git add -i
# set only the changes I want
# accidentally add <file> to the commit
$git commit -s <file>
# type up a long commit message
# notice that I committed everything

At this point I'd like to be able to do something like:
$git unstage -i
# select each hunk to unstage

and end up with a commit that only has what I originally wanted,
without having to re-write the commit message, nor having to do a lot
of weird things, or anything.

I can ofcourse use reset HEAD^ and lose my commit message, but then
I'd have to retype that out or copy paste it from somewhere else.

I ended up doing something like:

# save the current tree
$git rev-parse HEAD >savetree
# checkout the old files and re-write
$git checkout HEAD^ <file>
# update commit removing all changes from this file
$git commit --allow-empty --amend <file>
# now checkout the tree again to the contents of the saved tree
$git checkout $(cat savetree) <file>
# now add only the parts I wanted before
$git add -i
# finally amend the commit
$git commit --amend

That's a lot of steps and forces me to save my own file.

I thought of a few alternatives:

1. Create an advice setting which basically allows me to say "git,
please prevent me from staging files + an index if the files I marked
also conflict with paths already added to the index, maybe unless I
passed a force option"

or

2. somehow streamline the process of what I did above so I could just
do something like:

git commit --amend --set-tree=HEAD^

which would force the commit tree up one and avoid the double checkout
stuff, without actually changing my checked out copy at all

Then I'd be able to quickly re-add what I wanted.


3. somehow allow an unstage option.

So for the TL;DR; .. does anyone know of any tools which would help
automate the process so I could simply do

"git uncommit -i" and run a tool just like git add interactive or git add -p?

Thanks,
Jake

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jeff King]

On Wed, Oct 19, 2016 at 03:26:18PM -0700, Jacob Keller wrote:

> I recently (and in the past) had an issue where I was using git add
> --interactive and accidentally did something like the following:
> 
> # hack lots of randmo changes, then begin trying to commit then separately
> git add -i
> # set only the changes I want
> # accidentally add <file> to the commit
> $git commit -s <file>
> # type up a long commit message
> # notice that I committed everything
> 
> At this point I'd like to be able to do something like:
> $git unstage -i
> # select each hunk to unstage

I'd usually do one of:

  # undo selectively
  git reset -p HEAD^
  git commit --amend

or:

  # roll back the whole commit
  git reset HEAD
  # do it right this time
  git add -p
  # and steal the commit message from the previous attempt
  git commit -c HEAD@{1}

-Peff

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jacob Keller]

On Wed, Oct 19, 2016 at 3:42 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 19, 2016 at 03:26:18PM -0700, Jacob Keller wrote:
>
>> I recently (and in the past) had an issue where I was using git add
>> --interactive and accidentally did something like the following:
>>
>> # hack lots of randmo changes, then begin trying to commit then separately
>> git add -i
>> # set only the changes I want
>> # accidentally add <file> to the commit
>> $git commit -s <file>
>> # type up a long commit message
>> # notice that I committed everything
>>
>> At this point I'd like to be able to do something like:
>> $git unstage -i
>> # select each hunk to unstage
>
> I'd usually do one of:
>
>   # undo selectively
>   git reset -p HEAD^
>   git commit --amend

AHA! I knew about git reset -p but I didn't know about git reset -p
allowed passing a treeish. Does this reset modify my local files at
all? I think it doesn't, right?

>
> or:
>
>   # roll back the whole commit
>   git reset HEAD
>   # do it right this time
>   git add -p
>   # and steal the commit message from the previous attempt
>   git commit -c HEAD@{1}
>
> -Peff

Also nice to know about git commit -c

Thanks a lot! This should save me some headaches.

I still think it's worth while to add a check for git-commit which
does something like check when we say "git commit <files>" and if the
index already has those files marked as being changed, compare them
with the current contents of the file as in the checkout and quick
saying "please don't do that" so as to avoid the problem in the first
place.

A naive approach would just be "if index already has staged
differences dont allow path selection" but that doesn't let me do
something like "git add -p <files>" "git commit <other files>"

We could even make it work so that "commit --only" doesn't run this so
that way people can easily override, and we can give suggestions for
how to fix it in the output of the message. I can't really think if a
reasonable objection to such a change. I'll try to code something up
in the next few days when I can find some spare time.

Regards,
Jake

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jeff King]

On Wed, Oct 19, 2016 at 04:36:36PM -0700, Jacob Keller wrote:

> >   # undo selectively
> >   git reset -p HEAD^
> >   git commit --amend
> 
> AHA! I knew about git reset -p but I didn't know about git reset -p
> allowed passing a treeish. Does this reset modify my local files at
> all? I think it doesn't, right?

Correct. If you wanted to modify the working tree, too, use "git
checkout -p HEAD^".

> I still think it's worth while to add a check for git-commit which
> does something like check when we say "git commit <files>" and if the
> index already has those files marked as being changed, compare them
> with the current contents of the file as in the checkout and quick
> saying "please don't do that" so as to avoid the problem in the first
> place.
> 
> A naive approach would just be "if index already has staged
> differences dont allow path selection" but that doesn't let me do
> something like "git add -p <files>" "git commit <other files>"

I suspect both of those would complain about legitimate workflows.

I dunno.  I do not ever use "git commit <file>" myself. I almost
invariably use one of "git add -p" (to review changes as I add them) or
"git add -u" (when I know everything is in good shape, such as after
merge resolution; I'll sometimes just "git commit -a", too).

But it sounds like you want a third mode besides "--include" and
"--only". Basically "commit what has been staged already, but restrict
the commit to the paths I mentioned". Something like "--only-staged" or
something. I do not think we would want to change the default from
--only, but I could see a config option or something to select that
behavior.

I suspect nobody has really asked for such a thing before because
separate staging and "git commit <file>" are really two distinct
workflows. Your pain comes from mix-and-matching them.

-Peff

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jacob Keller]

On Wed, Oct 19, 2016 at 7:13 PM, Jeff King <peff@peff.net> wrote:
> I suspect both of those would complain about legitimate workflows.
>
> I dunno.  I do not ever use "git commit <file>" myself. I almost
> invariably use one of "git add -p" (to review changes as I add them) or
> "git add -u" (when I know everything is in good shape, such as after
> merge resolution; I'll sometimes just "git commit -a", too).
>
> But it sounds like you want a third mode besides "--include" and
> "--only". Basically "commit what has been staged already, but restrict
> the commit to the paths I mentioned". Something like "--only-staged" or
> something. I do not think we would want to change the default from
> --only, but I could see a config option or something to select that
> behavior.
>
> I suspect nobody has really asked for such a thing before because
> separate staging and "git commit <file>" are really two distinct
> workflows. Your pain comes from mix-and-matching them.
>
> -Peff

No. What I want is to *prevent* mix-and-match from happening.
Basically, sometimes I use "git add -p" to stage changes. But if I
just did a "git diff" and I know all the changes that I want are in
the file I will just do "git commit <file>" or "git commit -a". The
problem is that sometimes I stage stuff, forget or just make a brain
mistake, and I go ahead and use "git commit <file>"

What I want is to make it so that when you run "git commit <file>"
that it is smart enough to go "hey! You already staged something from
that file in the index and it doesn't match what you're asking me to
commit now, so I'm going to stop and make sure you either reset, don't
run "git commit <file>" or run "git commit --only <file>" or similar.

It's just about making it so that if I happen to make the mistake in
the future it doesn't generate a commit and instead tells me that I
was being an idiot. I don't want this check to just be "you can't
stage with the index and then tell me to commit -a or commit <files>"
because I think that's too restrictive and might make people complain.

Essentially, I want the tool to become smart enough to make it so that
an obvious mistake is caught early before I have to undo things.

That being said, it's much less of a pain point now that I know I can
go "git reset -p HEAD^". It never occurred to me that git reset -p
would work that way, so I didn't even try it.

Thanks,
Jake

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> I still think it's worth while to add a check for git-commit which
>> does something like check when we say "git commit <files>" and if the
>> index already has those files marked as being changed, compare them
>> with the current contents of the file as in the checkout and quick
>> saying "please don't do that" so as to avoid the problem in the first
>> place.
> ...
> I suspect both of those would complain about legitimate workflows.
>
> I dunno.  I do not ever use "git commit <file>" myself.

Users are different.  I do use this all the time, and it is not
unusual at all to have changed contents on paths other than <file>
already added to the index when I do so, i.e. an unrelated small
typofix in <file> jumping ahead of the real changes I am working on
in other parts of the tree.

"Please don't do that" would break.  Jacob says "avoid the problem",
but I do not see a problem in allowing it (it could be that the
problem Jacob has is in other parts of his workflow, but I do not
know what it is offhand).

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jacob Keller]

On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>>> I still think it's worth while to add a check for git-commit which
>>> does something like check when we say "git commit <files>" and if the
>>> index already has those files marked as being changed, compare them
>>> with the current contents of the file as in the checkout and quick
>>> saying "please don't do that" so as to avoid the problem in the first
>>> place.
>> ...
>> I suspect both of those would complain about legitimate workflows.
>>
>> I dunno.  I do not ever use "git commit <file>" myself.
>
> Users are different.  I do use this all the time, and it is not
> unusual at all to have changed contents on paths other than <file>
> already added to the index when I do so, i.e. an unrelated small
> typofix in <file> jumping ahead of the real changes I am working on
> in other parts of the tree.
>
> "Please don't do that" would break.  Jacob says "avoid the problem",
> but I do not see a problem in allowing it (it could be that the
> problem Jacob has is in other parts of his workflow, but I do not
> know what it is offhand).

I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:

I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.

Then, I (accidentally) run "git commit <file>"

I want git commit to complain here that the index <file> and acutal
<file> being requested are different and it thinks there's an issue.

I do *NOT* want it to complain if I do "git add -p" and put parts of
<other-file> into the index, and then run

git commit <file>

Does that make sense?

Basically if the index and "git commit <file>" both say "add <file>"
but they conflict in what version of <file> I want it to go "hey..
uhhh.. that's a bad idea"

Thanks,
Jake

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

> I still think we're misunderstanding. I want git commit to complain
> *only* under the following circumstance:
>
> I run "git add -p" and put a partial change into the index in <file>.
> There are still other parts which were not added to the index yet.
> Thus, the index version of the file and the actual file differ.
>
> Then, I (accidentally) run "git commit <file>"

I agree that this case is different.

Again, users are different, and I also often do

    $ edit file; think; decide it is a good enough first cut
    $ git add file
    $ edit file; think; decide it is getting better
    $ git add file
    $ edit file; think; decide it is now perfect
    $ git commit file

Because I do not think you can differentiate the above workflow from
the case where "git add -p" was used earlier, I think your updated
"git commit" needs to complain at this point.

I am not sure if that is OK.  I think it is less not-OK than the use
case I mentioned in my earlier message, in that this is not a case
that "please don't do it" breaks.  It however is an inconvenience
that the user has to say "git add file" before the "git commit" (or
"git commit file") to conclude the sequence.

So I dunno.

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jacob Keller]

On Thu, Oct 20, 2016 at 10:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>> I still think we're misunderstanding. I want git commit to complain
>> *only* under the following circumstance:
>>
>> I run "git add -p" and put a partial change into the index in <file>.
>> There are still other parts which were not added to the index yet.
>> Thus, the index version of the file and the actual file differ.
>>
>> Then, I (accidentally) run "git commit <file>"
>
> I agree that this case is different.
>
> Again, users are different, and I also often do
>
>     $ edit file; think; decide it is a good enough first cut
>     $ git add file
>     $ edit file; think; decide it is getting better
>     $ git add file
>     $ edit file; think; decide it is now perfect
>     $ git commit file
>
> Because I do not think you can differentiate the above workflow from
> the case where "git add -p" was used earlier, I think your updated
> "git commit" needs to complain at this point.
>
> I am not sure if that is OK.  I think it is less not-OK than the use
> case I mentioned in my earlier message, in that this is not a case
> that "please don't do it" breaks.  It however is an inconvenience
> that the user has to say "git add file" before the "git commit" (or
> "git commit file") to conclude the sequence.
>
> So I dunno.

Hmmm.. Ya ok I don't think we can actually distinguish between these
two work flows.

Given that I now know how to fix my mistake easily (git reset -p) I
think I will just go ahead and not bother with this as it's much less
of a pain now.

Thanks,
Jake

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

>> I am not sure if that is OK.  I think it is less not-OK than the use
>> case I mentioned in my earlier message, in that this is not a case
>> that "please don't do it" breaks.  It however is an inconvenience
>> that the user has to say "git add file" before the "git commit" (or
>> "git commit file") to conclude the sequence.
>>
>> So I dunno.
>
> Hmmm.. Ya ok I don't think we can actually distinguish between these
> two work flows.

What we might want to have in "git commit <paths>" is a new mode
that is totally different from -i/-o that says roughly "Start from
the tree of HEAD, pretend as if you removed all the paths that match
the given pathspec from the tree, and then added all the entries in
the index that match that pathspec.  Write that tree and commit.
Take nothing from the working tree".  I have a feeling that when
people do

	$ git add -p file1 file2 file3
	$ git commit file2

and ends up including _all_ changes made to file2, not just the ones
they picked in the earlier part of the workflow, they are expecting
such a behaviour.

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jacob Keller]

On Thu, Oct 20, 2016 at 11:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>>> I am not sure if that is OK.  I think it is less not-OK than the use
>>> case I mentioned in my earlier message, in that this is not a case
>>> that "please don't do it" breaks.  It however is an inconvenience
>>> that the user has to say "git add file" before the "git commit" (or
>>> "git commit file") to conclude the sequence.
>>>
>>> So I dunno.
>>
>> Hmmm.. Ya ok I don't think we can actually distinguish between these
>> two work flows.
>
> What we might want to have in "git commit <paths>" is a new mode
> that is totally different from -i/-o that says roughly "Start from
> the tree of HEAD, pretend as if you removed all the paths that match
> the given pathspec from the tree, and then added all the entries in
> the index that match that pathspec.  Write that tree and commit.
> Take nothing from the working tree".  I have a feeling that when
> people do
>
>         $ git add -p file1 file2 file3
>         $ git commit file2
>
> and ends up including _all_ changes made to file2, not just the ones
> they picked in the earlier part of the workflow, they are expecting
> such a behaviour.
>

Right now I think people who use it intentionally do expect it to work
that way. I just happen to not have wanted to add <file> but did so
anyways without considering, and thus I ended up including changes
that were for the next commit.

As long as there is a way to change "git commit" default from that
mode then we could make the default work and then let people configure
it to what makes sense.

I'll take a look at going this route.

Thanks,
Jake

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Lukas Fleischer]

On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
> [...]
> I still think we're misunderstanding. I want git commit to complain
> *only* under the following circumstance:
> 
> I run "git add -p" and put a partial change into the index in <file>.
> There are still other parts which were not added to the index yet.
> Thus, the index version of the file and the actual file differ.
> 
> Then, I (accidentally) run "git commit <file>"
> [...]

This reminded me of something that bothered me for a while. It's not
100% on-topic but still quite related so I thought I'd bring it up.

When working on a feature, I usually try to make atomic changes from the
beginning and use `git commit -a` to commit them one after another. This
works fine most of the time. Sometimes I notice only after making some
changes that it might be better to split the working tree changes into
several commits.

In that case, I git-add the relevant hunks and then, unfortunately, I
often run `git commit -a` instead of `git commit` (muscle memory bites
me), so I need to do all the splitting work again.

It's not much of an issue but would it be worthwhile to add an optional
feature (configurable) that warns you when using --all with staged
changes (which are not new files)? Are there others having the same
issue? Do you think this should be implemented as part of an alias
instead?

Regards,
Lukas

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jacob Keller]

On Sat, Oct 22, 2016 at 2:19 AM, Lukas Fleischer <lfleischer@lfos.de> wrote:
> On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
>> [...]
>> I still think we're misunderstanding. I want git commit to complain
>> *only* under the following circumstance:
>>
>> I run "git add -p" and put a partial change into the index in <file>.
>> There are still other parts which were not added to the index yet.
>> Thus, the index version of the file and the actual file differ.
>>
>> Then, I (accidentally) run "git commit <file>"
>> [...]
>
> This reminded me of something that bothered me for a while. It's not
> 100% on-topic but still quite related so I thought I'd bring it up.
>
> When working on a feature, I usually try to make atomic changes from the
> beginning and use `git commit -a` to commit them one after another. This
> works fine most of the time. Sometimes I notice only after making some
> changes that it might be better to split the working tree changes into
> several commits.
>
> In that case, I git-add the relevant hunks and then, unfortunately, I
> often run `git commit -a` instead of `git commit` (muscle memory bites
> me), so I need to do all the splitting work again.
>
> It's not much of an issue but would it be worthwhile to add an optional
> feature (configurable) that warns you when using --all with staged
> changes (which are not new files)? Are there others having the same
> issue? Do you think this should be implemented as part of an alias
> instead?
>
> Regards,
> Lukas

This is (essentially) what I am asking for above. It's the same
overall problem of "muscle memory bites me" and I want the tool to
change to help avoiding because I don't think I can win the fight
against muscle memory every time. Being configurable would ensure that
only those that want the behavior opt in.

Thanks,
Jake

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Duy Nguyen]

On Sat, Oct 22, 2016 at 4:19 PM, Lukas Fleischer <lfleischer@lfos.de> wrote:
> On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
>> [...]
>> I still think we're misunderstanding. I want git commit to complain
>> *only* under the following circumstance:
>>
>> I run "git add -p" and put a partial change into the index in <file>.
>> There are still other parts which were not added to the index yet.
>> Thus, the index version of the file and the actual file differ.
>>
>> Then, I (accidentally) run "git commit <file>"
>> [...]
>
> This reminded me of something that bothered me for a while. It's not
> 100% on-topic but still quite related so I thought I'd bring it up.
>
> When working on a feature, I usually try to make atomic changes from the
> beginning and use `git commit -a` to commit them one after another. This
> works fine most of the time. Sometimes I notice only after making some
> changes that it might be better to split the working tree changes into
> several commits.
>
> In that case, I git-add the relevant hunks and then, unfortunately, I
> often run `git commit -a` instead of `git commit` (muscle memory bites
> me), so I need to do all the splitting work again.
>
> It's not much of an issue but would it be worthwhile to add an optional
> feature (configurable) that warns you when using --all with staged
> changes (which are not new files)? Are there others having the same
> issue? Do you think this should be implemented as part of an alias
> instead?

I hit the same problem sometimes, but in my case sometimes I
accidentally do "git add" after "git add -p" and a configuration in
"git commit -a" won't help me. I'd prefer we could undo changes in
index instead. Something like reflog but for index.
-- 
Duy

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jeff King]

On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:

> I hit the same problem sometimes, but in my case sometimes I
> accidentally do "git add" after "git add -p" and a configuration in
> "git commit -a" won't help me. I'd prefer we could undo changes in
> index instead. Something like reflog but for index.

An index write always writes the whole file from scratch, so you really
just need to save a copy of the old file. Perhaps something like:

  rm -f $GIT_DIR/index.old
  ln $GIT_DIR/index.old $GIT_DIR/index
  ... and then open $GIT_DIR/index.tmp ...
  ... and then rename(index.tmp, index) ...

could do it cheaply. It's a little more complicated if you want to save
a sequence of versions, and eventually would take a lot of space, but
presumably a handful of saved indexes would be sufficient.

Another option would be an index format that journals, and you could
potentially walk back the journal to a point. That seems like a much
bigger change (and has weird layering, because deciding when to fold in
the journal is usually a performance thing, but obviously this would
have user-visible impact about how far back you could undo).

-Peff

Re: tools for easily "uncommitting" parts of a patch I just commited?

[Duy Nguyen]

On Sun, Oct 23, 2016 at 8:38 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:
>
>> I hit the same problem sometimes, but in my case sometimes I
>> accidentally do "git add" after "git add -p" and a configuration in
>> "git commit -a" won't help me. I'd prefer we could undo changes in
>> index instead. Something like reflog but for index.
>
> An index write always writes the whole file from scratch, so you really
> just need to save a copy of the old file. Perhaps something like:
>
>   rm -f $GIT_DIR/index.old
>   ln $GIT_DIR/index.old $GIT_DIR/index
>   ... and then open $GIT_DIR/index.tmp ...
>   ... and then rename(index.tmp, index) ...
>
> could do it cheaply. It's a little more complicated if you want to save
> a sequence of versions, and eventually would take a lot of space, but
> presumably a handful of saved indexes would be sufficient.

Yeah. I had something [1] like that but never sorted out the UI for it :(

> Another option would be an index format that journals, and you could
> potentially walk back the journal to a point. That seems like a much
> bigger change (and has weird layering, because deciding when to fold in
> the journal is usually a performance thing, but obviously this would
> have user-visible impact about how far back you could undo).

v2 [2] goes in this direction (but not a full blown COW, the journal
does not take part in any core operations of the index)

[1] https://public-inbox.org/git/%3C1375597720-13236-1-git-send-email-pclouds@gmail.com%3E/
[2] https://public-inbox.org/git/1375966270-10968-1-git-send-email-pclouds@gmail.com/
-- 
Duy