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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 12, 2011, 22:12 UTC
Message-ID: <20110612221217.GA2789@elie>
In-Reply-To: <BANLkTi=gYSJgG-Yu-+-5wPetpb0-AW=X+g@mail.gmail.com>

Ramkumar Ramachandra wrote:

Show 6 quoted lines

> Frankly, I'm still trying to understand how other people work -- I
> don't use the porcelain much, and I dislike anything but the most
> minimalistic automation.  I didn't even like the change to cherry-pick
> where you can simply "git commit" after resolving a conflict; I still
> prefer and use the more explicit "git commit -c" after removing the
> CHERRY_PICK_HEAD.  Also, I *always* use rebase with --onto

I don't think that should stop you from thinking about how new facilities help or interfere with work at all. You use magit, right? It automates all kinds of things. And while each person is going to use tools in different ways, that hasn't kept people from getting things done in the past.

If you are thinking "I would never use 'git cherry-pick --abort' --- I would just look in the reflog for a commit to 'reset --hard' to", then you are *done*. Just document it, make sure the reflog has useful content to help out, and wait until someone complains and adds a shortcut they like.

Addendum:  Personally I was happy about "git commit" that implicitly
takes the commit message from CHERRY_PICK_HEAD because it adds a

	Conflicts:

		Makefile

that I can use as a template for a message about the nature of the conflict and how I fixed it up. As a side note, I'm curious about why you end up needing to remove the CHERRY_PICK_HEAD. Is "git commit -c interesting-patch" misbehaving somehow? (It should ignore the CHERRY_PICK_HEAD entirely.)