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

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

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

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

On Wed, Oct 19, 2016 at 3:42 PM, Jeff King <peff@peff.net> wrote:

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?

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

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

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

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

On Wed, Oct 19, 2016 at 7:13 PM, Jeff King <peff@peff.net> wrote:

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

Jeff King <peff@peff.net> writes:

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).

On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano <gitster@pobox.com> 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>"

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

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

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.

On Thu, Oct 20, 2016 at 10:39 AM, Junio C Hamano <gitster@pobox.com> wrote:

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

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

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.

On Thu, Oct 20, 2016 at 11:41 AM, Junio C Hamano <gitster@pobox.com> wrote:

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

On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:

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

On Sat, Oct 22, 2016 at 2:19 AM, Lukas Fleischer <lfleischer@lfos.de> wrote:

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

On Sat, Oct 22, 2016 at 4:19 PM, Lukas Fleischer <lfleischer@lfos.de> 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.

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

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

On Sun, Oct 23, 2016 at 8:38 AM, Jeff King <peff@peff.net> wrote:

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

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/