Revert option for git add --patch

Revert option for git add --patch

[Nathan Broadbent]

Hi,

I would like to propose a revert option for 'git add --patch', that
reverts the hunk. I often use `git add -p` to skip whitespace changes
when preparing a patch, and a 'revert' option would save me from
running 'git checkout <file>' after I've staged the desired changes.

I would propose adding r and R options for the 'Stage this hunk' menu,
with the following actions:

r: Revert this hunk
R: Revert this hunk and all other remaining hunks

e.g. Stage this hunk [y/n/a/d/K/j/J/e/r/R?]?


Please let me know if you think this is a good idea.


Best,
Nathan

Re: Revert option for git add --patch

[Simon Rozet]

help

On Wed, Nov 7, 2012 at 3:54 PM, Nathan Broadbent <nathan.f77@gmail.com> wrote:
> Hi,
>
> I would like to propose a revert option for 'git add --patch', that
> reverts the hunk. I often use `git add -p` to skip whitespace changes
> when preparing a patch, and a 'revert' option would save me from
> running 'git checkout <file>' after I've staged the desired changes.
>
> I would propose adding r and R options for the 'Stage this hunk' menu,
> with the following actions:
>
> r: Revert this hunk
> R: Revert this hunk and all other remaining hunks
>
> e.g. Stage this hunk [y/n/a/d/K/j/J/e/r/R?]?
>
>
> Please let me know if you think this is a good idea.
>
>
> Best,
> Nathan
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Revert option for git add --patch

[Michal Kiedrowicz]

Nathan Broadbent <nathan.f77 <at> gmail.com> writes:

> I would like to propose a revert option for 'git add --patch', that
> reverts the hunk. I often use `git add -p` to skip whitespace changes
> when preparing a patch, and a 'revert' option would save me from
> running 'git checkout <file>' after I've staged the desired changes.


Doesn't `git checkout -p` do what you describe?

Kind regards,
Michal Kiedrowicz

Re: Revert option for git add --patch

[Jonathon Mah]

Nathan,

I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).

The interactive staging-and-editing tool could be improved, but I'm not sure that tool should be called 'git add -p'. git add doesn't touch the working tree — at least I hope not, because I wouldn't expect it.

But I eagerly support more discussion. If someone does want to add this feature to "git add -p" (or named differently), I'll add a request for another letter (perhaps '!')  to edit the hunk in the working tree.
	


Jonathon Mah
me@JonathonMah.com

Re: Revert option for git add --patch

[Nguyen Thai Ngoc Duy]

On Thu, Nov 8, 2012 at 3:57 PM, Jonathon Mah <jmah@me.com> wrote:
> Nathan,
>
> I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).

I agree. I'd be really nice to have an interactive command about hunk
manipulation between HEAD (or some other ref), index and worktree in
both directions (except writing to HEAD, of course). This reminds me
of the "git put" discussion a while ago, which also moves code between
different locations..
-- 
Duy

Re: Revert option for git add --patch

[Jeff King]

On Thu, Nov 08, 2012 at 12:57:19AM -0800, Jonathon Mah wrote:

> I find myself performing similar actions to you: using git add -p to
> stage hunks, sometimes editing the staged patch; and keeping mental
> notes of things I wanted to revert, sometimes changing them in the
> editor in another window, and sometimes reverting them after the add
> session with git checkout -p).

Yeah, I often use a similar workflow. A related one is:

  (1) Make lots of unrelated changes in the working tree.

      $ hack hack hack

  (2) Pick out hunks for the first commit.

      $ git add -p

  (3) Put the rest of the changes aside.

      $ git stash -k

  (4) Test (and possibly tweak) the result, then commit.

      $ make test
      $ git commit -m "topic 1"

  (5) Bring back the stashed changes.

      $ git stash pop

  (6) If there are still interesting changes, goto step 2.

  (7) Otherwise, discard with "git reset --hard" or "git checkout -p".

I.e., iterating on the changes to put them into several different
commits (and achieving a clean, testable state before making each
commit).

The downside of these workflows is that you have to say "no" to hunks
multiple times (one per iteration) instead of just sorting them in a
single pass. This works OK in practice, but it might be nice to have a
tool that makes a single pass and lets you drop hunks into buckets
(topic 1 vs topic 2 vs discard), and then apply the buckets in order,
stopping to test, tweak, and commit after each one.

> The interactive staging-and-editing tool could be improved, but I'm
> not sure that tool should be called 'git add -p'. git add doesn't
> touch the working tree — at least I hope not, because I wouldn't
> expect it.

Right. I think the idea of one-pass tool is a good one, but it should
not be called "git add -p".

-Peff

Re: Revert option for git add --patch

[Jeff King]

On Fri, Nov 09, 2012 at 08:42:33AM +1300, Nathan Broadbent wrote:

> It sounds like we want a tool that combines the functionality of 'git add
> --patch', 'git checkout --patch', and other features, so that we can
> perform various actions on 'hunks' without switching context. What do you
> think about naming this command 'git patch'?

I think it would be a slightly confusing name, given that it is not
related to the usual Unix "patch" command (git's analog to that is "git
apply").

I was thinking something like "git organize" because it is about
organizing muddled changes. Duy mentioned my earlier "git put", which is
based around the same ideas. This could be thought of as "git put
--patch", I suppose.

> I'm not sure how dropping hunks into 'buckets' would work, but the main
> idea is to be able to stage, discard or edit hunks in a single pass.

Buckets are really just patches you are building up from hunks. So I
think you are dealing with two buckets either way: a to-stage bucket and
a to-discard bucket. Adding more buckets isn't hard; you just turn the
to-stage bucket into an array of buckets.

The tricky part is figuring out how to keep the state persistent across
multiple invocations. The simplest program flow for the 2-bucket case
would be something like:

  for h in hunks
  do
          show hunk to user
          ask user what they want to do
          if they want to stage
             append to to-stage patch
          else if they want to discard
             append to to-discard patch
          else
             ignore the hunk
  done
  feed to-stage patch to "git apply --cached"
  feed to-discard patch to "git apply -R"

Modifying the loop to have more buckets is easy. But the end is probably
something like:

  feed to-discard patch to "git apply -R"
  feed bucket[0] to "git apply --cached"
  save bucket[1..n] somewhere
  exit

Then the user gets control back, builds, tests, commits, whatever, and
then runs "git organize --continue" to apply bucket[1], and so on. And
since we don't know what the user did in between, we have to be ready
for conflicts in applying the buckets.  Hmm, this is sounding a lot like
how "rebase --interactive" works.

One way to implement this would be to store each bucket as a commit
against HEAD (i.e., stage it into a temporary index, then run "git
write-tree" and "git commit-tree"), and then make a "rebase -i"
instruction sheet like:

  pick $sha1_of_bucket_1_commit
  edit
  pick $sha1_of_bucket_2_commit
  edit

and so forth, except that we would not want our picks to actually commit
(just pull the changes into the working tree and/or index).

That's just me thinking off the top of my head. Obviously what you are
proposing is way simpler, and it is probably sane to start with the
simple thing, and then build the more complex thing on top. But it might
be worth keeping in mind the complex case when building out the
infrastructure for the simple case.

-Peff

Re: Revert option for git add --patch

[Bogolisk]

Jonathon Mah <jmah <at> me.com> writes:

> 
> Nathan,
> 
> I find myself performing similar actions to you: using git add -p to stage 
hunks, sometimes editing the
> staged patch; and keeping mental notes of things I wanted to revert, sometimes 
changing them in the editor
> in another window, and sometimes reverting them after the add session with git 
checkout -p).

Other front-ends like Egg and Magit has been providing the ability to move hunks 
back and forth, for a long time.