From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Thu, 02 Jun 2011 13:03:42 GMT
Subject: Re: [RFC PATCH] revert: Implement --abort processing
Message-ID: <BANLkTikgY_Kc6gu_iTtpiiayo9e=DPxOLw@mail.gmail.com>
In-Reply-To: <20110601190006.GB9730@elie>

Hi Sverre, Junio and Jonathan,

Sverre Rabbelier writes:
> Isn't this the kind of usecase we added 'git reset --merge' for?

Yes, I can see that now.

Junio Hamano writes:
> Even if you dropped the unconditional "rerere clear" from the patch, I am
> not sure what this new feature buys us. Some people would want the rerere
> cache cleared, some others don't. "revert --abort" will forever be to
> aborting revert and restoring some but not all the parts of the operation
> the user wants to be undone, as you cannot satisfy everybody.  So I am a
> bit puzzled why you thought this was even a good idea to begin with.

It's actually very specific to the way I work/ think -- I would have
expected an abort to go back in time, and make it look like the
operation wasn't performed in the first place. My normal workflow: I
make my changes, create a "fixup!" commit, abort, and cherry-pick that
commit from my reflog. Yes, I use "reset --hard" a lot, and yes, it's
a very powerful hammer.

I see now that this probably doesn't fit everyone's usecase. So the
changes I propose are:
1. Don't rerere clear. We can probably document this fact somewhere,
and hint the user about this during the time of abort.
2. Use reset --merge as Sverre suggested.

I'll think about this workflow and post a patch soon.

Jonathan Nieder writes:
> I have some changes to files that did not participate in the automatic
> cherry-pick:
>
>  1. for unrelated reasons, I bumped the version number in the Makefile
>  as a reminder not to forget later, without commiting it or marking
>  with "git add";
>
>  2. I (manually) moved a declaration to a different header file to
>  reflect differences between the codebase at the time of foo^ and HEAD,
>  to get it to compile.  Which works, so I mark it with "git add" for
>  incorporation into the corrected cherry-pick commit.
>
> With "git reset --merge", (1) is left alone, while (2) is backed out,
> unmerged entries are of course clobbered, and hazy cases in which I
> make some changes, "git add", and then make more changes without "git
> add" cause the operation to error out.  It would be nicer if git could
> read my mind, but at first glance this seems like an okay second-best.

Thanks for the excellent explanation. I'll think about this workflow
for a while before posting another iteration of this patch.

-- Ram