All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [RFC PATCH v2] revert: Implement --abort processing
Date: Sun, 12 Jun 2011 07:21:45 -0500	[thread overview]
Message-ID: <20110612122145.GA20495@elie> (raw)
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.

  reply	other threads:[~2011-06-12 12:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-11  6:36 [RFC PATCH v2] revert: Implement --abort processing Ramkumar Ramachandra
2011-06-11 11:22 ` Jonathan Nieder
2011-06-12 12:09   ` Ramkumar Ramachandra
2011-06-12 12:21     ` Jonathan Nieder [this message]
2011-06-12 12:51       ` Ramkumar Ramachandra
2011-06-12 22:12         ` Jonathan Nieder
2011-06-13 14:55           ` Ramkumar Ramachandra
2011-06-13 20:28             ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110612122145.GA20495@elie \
    --to=jrnieder@gmail.com \
    --cc=artagnon@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.