Re: [RFC PATCH v2] revert: Implement --abort processing

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 12, 2011, 12:21 UTC
Message-ID: <20110612122145.GA20495@elie>
In-Reply-To: <BANLkTi=T0wCg1bKzmtQEQ-J-5ogqRZaqRg@mail.gmail.com>

Ramkumar Ramachandra wrote:

> My notion of --abort has changed: I simply want to remove the state
> files for the cherry-pick so that the user can execute more
> cherry-pick/ revert commands.  I didn't think a soft reset would be
> intrusive.

Well, if you understand this part then you can forget most of the rest of what I said. Think about this for a second. New user (or forgetful, experienced user), has just run

	git cherry-pick HEAD..topic

to integrate the changes from topic in a linear history. Ran into conflicts, wanted to give up. Ran

	git cherry-pick --abort

Would this person expect:

 - that "git diff --cached" would return a pile of changes
 - that "git reset --keep", "git reset --merge", "git checkout",
   "git merge", and various other commands would refuse to do much,
   for fear of clobbering the new "local changes"
 - that the worktree would be unchanged
 - etc

Would they be happy about it? Just put yourself in their shoes. A soft reset is near the most intrusive behavior possible.

And that is a good way to think about the UI for any new facility. If you disregard about how flexible it is in abstract, how easy to implement, how elegant-sounding and just think about a person using it will find her quality of life improved or worsened, that is (1) a good sanity-check on a design and (2) basically the only way to explain it to other people.