Feature request - discard hunk in add --patch mode

Feature request - discard hunk in add --patch mode

[Mina Almasry]

Hi,

I frequently stage files using git add --patch command and I almost 
always come across debug code I want to discard, but there is no option 
for that in the prompt. The result is that I have to run an extra 
command after the dialogue ends.

I would like to add a feature to allow users to discard hunks using a 
command like r! or d!

I was wondering if that would be a welcome addition to git. I am willing 
to work on the feature myself.

Regards,
Mina

Re: Feature request - discard hunk in add --patch mode

[Thomas Rast]

Mina Almasry <almasry.mina@hotmail.com> writes:

> I frequently stage files using git add --patch command and I almost 
> always come across debug code I want to discard, but there is no option 
> for that in the prompt. The result is that I have to run an extra 
> command after the dialogue ends.
>
> I would like to add a feature to allow users to discard hunks using a 
> command like r! or d!

This has come up before, and actually led to the introduction of
'checkout -p' and 'reset -p':

  http://thread.gmane.org/gmane.comp.version-control.git/123854

Judging by the '!' above, you are already aware that this is a dangerous
option that needs some safeguards.  I imagine that would largely account
for Junio's safety concerns.  So you could pick up from the general
direction of Pierre's post, and try to work out something.

However, life has become rather more complicated since 2009.  Whatever
you do also needs to fit nicely with checkout/reset/stash -p.  The first
two also take commit arguments, resulting in a total of seven modes of
operation, defined in %patch_modes.

I imagine one good angle of attack would be to proceed as follows:

* Optionally make add--interactive.perl more aware of what the patches
  say.  Ideally there would be a way to reverse the direction of a diff
  (or otherwise manipulate it) in the program itself, instead of having
  to decide this when fetching the patches.

* Change things so that the actions in %patch_modes are a hunk property
  instead of a global state.  Of course the actual mode still needs to
  be global state.  Not all actions should be possible in all modes;
  figure out a clean way to implement this.

* Design commands in some modes that switch to another mode, and/or set
  another action than the default in the current mode.

Note that r! commands need to also work in singlekey mode, where the 'r'
is read immediately and you would have to read for another
(confirmation) key to get the '!'.

Good luck!

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Feature request - discard hunk in add --patch mode

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Mina Almasry <almasry.mina@hotmail.com> writes:
>
>> I frequently stage files using git add --patch command and I almost 
>> always come across debug code I want to discard, but there is no option 
>> for that in the prompt. The result is that I have to run an extra 
>> command after the dialogue ends.
>>
>> I would like to add a feature to allow users to discard hunks using a 
>> command like r! or d!
>
> This has come up before, and actually led to the introduction of
> 'checkout -p' and 'reset -p':
>
>   http://thread.gmane.org/gmane.comp.version-control.git/123854

That is a blast from the past.

Why is saying "git checkout ." too much work, after "add -p" that
you excluded the debugging cruft?

I actually do this for extra safety, though:

	git add -p ;# add everything but exclude debug cruft
	git diff ;# make really sure that this shows only garbage
	git diff | git apply -R ;# and get rid of that garbage

primarily because I can take the "git diff" output in the second
step to a file, remove the hunk that I accidentally forgot to add
in the "add -p" stage, and "apply -R" to remove only the cruft.
After doing so, "git diff" will show the important-but-forgotten
bit, and I can choose to add it to the next commit, or I can choose
to leave it in the working tree for a future commit after the
current index is committed.

But the above is a tangent side-note to show possibly a better way
to work, not about adding new operations to "add -p".

Re: Feature request - discard hunk in add --patch mode

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <trast@student.ethz.ch> writes:
>
>> This has come up before, and actually led to the introduction of
>> 'checkout -p' and 'reset -p':
>>
>>   http://thread.gmane.org/gmane.comp.version-control.git/123854
>
> That is a blast from the past.
>
> Why is saying "git checkout ." too much work, after "add -p" that
> you excluded the debugging cruft?

Please forget this question.  A better way in the form of "stash -p"
was suggested in the old thread to get rid of debug cruft in the
tree before an "add -p" session (or during a series of "add -p"
sessions).

So is this still an issue?

Re: Feature request - discard hunk in add --patch mode

[Mina Almasry]

On 12-08-15 02:46 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>>> This has come up before, and actually led to the introduction of
>>> 'checkout -p' and 'reset -p':
>>>
>>>    http://thread.gmane.org/gmane.comp.version-control.git/123854
>> That is a blast from the past.
>>
>> Why is saying "git checkout ." too much work, after "add -p" that
>> you excluded the debugging cruft?
> Please forget this question.  A better way in the form of "stash -p"
> was suggested in the old thread to get rid of debug cruft in the
> tree before an "add -p" session (or during a series of "add -p"
> sessions).
>
> So is this still an issue?
>
>
I read most of the thread, and I do think it still is. Here are my 2 cents:

1. The alternative commands aren't nearly as time efficient:
     - git checkout . is fast and awesome, but you can't use it if, for 
example, you have to maintain a dirty         working tree
     - git (stash|reset|checkout) -p make you go through (all|most) of 
the hunks you have to hunt down             those 2 lines that say "echo 
'This line is runningantoeuhaoeuaoae'"

2. All of the safety concerns can be alleviated with the right 
interface. I am glad the u option mentioned in the thread did not go 
through since I agree it is not ideal. However, if the command is:
     (a) something with a '!', then no one will hit it by mistake, and
     (b) the prompt makes it clear that work is lost
then I think it would be fine

The advantages of a command like this are pretty huge IMO. I can see 
this being a big time saver.

How about adding this to the git add -p prompt:

     r! - remove this hunk. The hunk is discarded from the working tree, 
and is irrevocably lost.

Re: Feature request - discard hunk in add --patch mode

[Junio C Hamano]

Mina Almasry <almasry.mina@hotmail.com> writes:

> On 12-08-15 02:46 PM, Junio C Hamano wrote:
> ...
>> Please forget this question.  A better way in the form of "stash -p"
>> was suggested in the old thread to get rid of debug cruft in the
>> tree before an "add -p" session (or during a series of "add -p"
>> sessions).
>>
>> So is this still an issue?
>>
> I read most of the thread, and I do think it still is. Here are my 2 cents:
>
> 1. The alternative commands aren't nearly as time efficient:
>     - git checkout . is fast and awesome, but you can't use it if, for
> example, you have to maintain a dirty         working tree
>     - git (stash|reset|checkout) -p make you go through (all|most) of
> the hunks you have to hunt down             those 2 lines that say
> "echo 'This line is runningantoeuhaoeuaoae'"

You have to do that _at least once_ anyway, as there is no other way
for Git to tell which one is debugging cruft and which one is the
real change you value without you telling it.  Will return to the
topic later.

> 2. All of the safety concerns can be alleviated with the right
> interface.

There are three safety concerns I raised in the original thread.
Among them, I do not think

 (1) new user may mistake "undo" to be something safe; and
 (2) experts will continue making typo between "y" and "u"

are the primary risks of the original patch Thomas pointed out.  

A much bigger problem with the approach is (3) letting "add" touch
the working tree breaks the world model.  Both experts and newbies
alike, people have learned that "git add" will never clobber what
they have in the working tree and rely on that promise.

And your key assignment, command renaming or extra prompting do not
change this fundamental issue at all.

Let's step back a bit, and define the problem we are solving.

Suppose you have changes in your working tree that are worth
multiple commits, debugging aid, and uncommittable WIP.  You want to
create multiple commits, possibly giving each of them the final
testing before committing, and want to end up with the WIP (plus
possibly the debugging aid, as that may still help your WIP) in your
working tree.

Do we agree that the goal of the discussion of this thread is to
make that process simple, safe, efficient and easy?

Now, back when the original patch by Pierre was proposed, it indeed
was cumbersome.  You could sift things through by "add -p" to build
the first commit in the index, commit, and iterate.  In each round,
"add -p" step had to skip the same debugging aid and WIP over and
over again.  If you wanted to give the result of "git add -p" a
final test before committing, "stash save -k" would give you the
state you would be committing, but it isn't easy to reintroduce only
the debugging aid to the working tree.

Since then "stash -p" was added to our toolchest.  So theoretically,
we should be able to do something like this:

    # start from N-commit worth of change, debug and WIP
    git stash save -p debug ;# stash away only the debugging aid
    # now we have only N-commit worth of change and WIP
    git stash save -p wip ;# stash away WIP

Then after that, you need N round of "git add -p && git commit".

Now, with what we have already, can we also give final testing
before committing?  Each round may now start with:

    git add -p ;# prepare the index for the next commit
    git stash save -k ;# save away the changes for later commits

and at this point, your working tree and the index has what you are
about to commit.  If we can apply the "debugging aid" stash we
created earlier to the working tree, that would allow you to test
the state you are about to commit with your debugging aid.  The
command to do so may be

    git stash apply stash@{2}

Once you are satisfied, you can reset this change out of your
working tree with "checkout .", and then "git commit" to record what
is in the index.

And then you can "git stash pop" to bring back the remainder of
N-commit series worth of changes.  You are ready to continue to the
next round.

Once you created N-commit series, you will still have two stash
entries, one "debug" and one "wip".  You should be able to resurrect
"wip" with

    git stash pop

just fine, but there is a little problem after this step.  Because
"git stash [apply|pop]" does not want to work on a dirty working
tree, starting from this state just after popping "wip" stash, you
cannot "git stash pop" to have both WIP changes and debugging aid to
the working tree.

A topic to improve "stash [apply/pop]" to allow it may be a valid
and useful thing to do.

As an approximation, without changing any of the current tools,
however, you should be able to do this after creating N-commit
series following the above procedure.

	git stash pop ;# resurrect "wip" to the working tree.
        git add -u ;# and add that to the index temporarily
        git stash pop ;# resurrect "debug" to the working tree as well.
	git reset ;# then match the index to HEAD

That will mix the WIP and debug again in your working tree.

Why you would want to mix them together, after sifting debug and wip
using "add -p" already, is a different issue, though (there are
valid scenarios why you would want to do so, and there are valid
cases why you do not have to bother).

So is this still an issue?

Re: Feature request - discard hunk in add --patch mode

[Mina Almasry]

Well I actually didn't know about stash -p when I asked for this, but I
still see room for us removing some more friction here:

>     # start from N-commit worth of change, debug and WIP
>     git stash save -p debug ;# stash away only the debugging aid
>     # now we have only N-commit worth of change and WIP
>     git stash save -p wip ;# stash away WIP
> 
> Then after that, you need N round of "git add -p && git commit".
> 
> Now, with what we have already, can we also give final testing
> before committing?  Each round may now start with:
> 
>     git add -p ;# prepare the index for the next commit
>     git stash save -k ;# save away the changes for later commits
> 
Here you have to _at least_ go through all your hunks once to stash the
debug code, once to stash the WIP, and once to add -p and commit.

Going through hunks is expensive... it takes quite a bit of time. Each
time you launch one of those commands you have to go through all hunks
you haven't decided on yet - could be a lot of hunks.

Now, what if we had a command where you would go through all your hunks
one, by one, and will give you an option to stage, stash, or discard
what you want as you please? In the above scenario, lets say N was 1,
then the scenario would be:

    # start from 1-commit worth of change, debug and WIP
    
    # stash debugging and WIP code, 
    # and stage the code you want to commit
    git mystery-command
    
    # everything done
    git commit

Then we would reduce 3 -p commands to 1 -p command.

Now what should this command be called? You resist making git-add unsafe
and I understand that. How about: 

  1. Give git add -p options that expose this extra functionality. So:

git add -p ; # can only stage code
git add -p --with-discard ; # does git add -p, plus discards hunks
git add -p --with-discard --with-stage ; # plus discard, plus stage

So in the hunks you can go:
  - discard; # and it would discard it
  - stage <stash>; # and it would stash it into <stash>

The argument I am making is that if a programmer explicitly asks for one
of those features then git will cooperate, and add becomes unsafe. We
are trusting that the programmer knows what they are doing. In all other
cases git add is the same, and will never touch the working tree.

We can also change git checkout -p and git stash -p so that they behave
the same:

  git stash -p --with-add; # does everything -p stash, and stages too
  git checkout -p --with-add; # does everything -p checkout, and stages

  2. We can come up with a whole new git command that does this.
Something like git patch-process

  # start from 1-commit worth of change, debug and WIP

  git patch-process ; # Stage, stash, and discard hunks as you please

  # ready for commit
  git commit

How does this sound?

PS: Newbish question: I am looking to help out with git, either with
this feature or others. How do I get around getting assigned a work to
do? Thanks.

Mina

On Wed, 2012-08-15 at 16:58 -0400, Mina Almasry wrote:
> On 12-08-15 02:46 PM, Junio C Hamano wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> Thomas Rast <trast@student.ethz.ch> writes:
> >>
> >>> This has come up before, and actually led to the introduction of
> >>> 'checkout -p' and 'reset -p':
> >>>
> >>>    http://thread.gmane.org/gmane.comp.version-control.git/123854
> >> That is a blast from the past.
> >>
> >> Why is saying "git checkout ." too much work, after "add -p" that
> >> you excluded the debugging cruft?
> > Please forget this question.  A better way in the form of "stash -p"
> > was suggested in the old thread to get rid of debug cruft in the
> > tree before an "add -p" session (or during a series of "add -p"
> > sessions).
> >
> > So is this still an issue?
> >
> >
> I read most of the thread, and I do think it still is. Here are my 2 cents:
> 
> 1. The alternative commands aren't nearly as time efficient:
>      - git checkout . is fast and awesome, but you can't use it if, for 
> example, you have to maintain a dirty         working tree
>      - git (stash|reset|checkout) -p make you go through (all|most) of 
> the hunks you have to hunt down             those 2 lines that say "echo 
> 'This line is runningantoeuhaoeuaoae'"
> 
> 2. All of the safety concerns can be alleviated with the right 
> interface. I am glad the u option mentioned in the thread did not go 
> through since I agree it is not ideal. However, if the command is:
>      (a) something with a '!', then no one will hit it by mistake, and
>      (b) the prompt makes it clear that work is lost
> then I think it would be fine
> 
> The advantages of a command like this are pretty huge IMO. I can see 
> this being a big time saver.
> 
> How about adding this to the git add -p prompt:
> 
>      r! - remove this hunk. The hunk is discarded from the working tree, 
> and is irrevocably lost.
> --
> 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
>