All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>,
	git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: [PATCH] rebase: learn --discard subcommand
Date: Mon, 30 May 2011 06:50:55 +0200	[thread overview]
Message-ID: <4DE3222F.6030604@alum.mit.edu> (raw)
In-Reply-To: <7vpqn2psjv.fsf@alter.siamese.dyndns.org>

On 05/28/2011 08:51 PM, Junio C Hamano wrote:
> "git reset --hard" used to be such a command in simpler times. It removes
> MERGE_HEAD unconditionally, so that a confused user can start from scratch
> without having to worry about what was in progress. As a devil's advocate,
> I am wondering if it is a good idea to simply teach "reset --hard" to also
> remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge,
> CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be
> done with it. It is a large hammer, but it is certainly the easiest to
> explain and the simplest to understand way to get out of any troubles.

If it would be desirable to separate the resetting of the working tree
from the resetting of any in-progress operation, perhaps "git reset
--abort" (by analogy with "git reset --abort" etc) would be a possible
spelling of the latter.  To reset any in-progress operations *and* reset
the working tree, on could use "git reset --hard --abort".

I strongly agree with another poster that it would be useful if "git
status" would print information about in-progress operations.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  parent reply	other threads:[~2011-05-30  4:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-28  2:58 [PATCH] rebase: learn --discard subcommand Martin von Zweigbergk
2011-05-28 13:15 ` Ramkumar Ramachandra
2011-05-29 12:50   ` Martin von Zweigbergk
2011-05-28 18:51 ` Junio C Hamano
2011-05-28 20:26   ` Tim Mazid
2011-05-28 22:50     ` Jonathan Nieder
2011-05-29 13:14   ` Martin von Zweigbergk
2011-05-29 13:41     ` Jakub Narebski
2011-05-30  4:50   ` Michael Haggerty [this message]
2011-05-28 23:08 ` Jonathan Nieder
2011-05-29  9:30   ` Tim Mazid
2011-05-29 17:28   ` Martin von Zweigbergk
2011-05-29 18:58     ` Jonathan Nieder
2011-05-30  4:46   ` Michael Haggerty
2011-05-30  5:14     ` Tim Mazid
2011-05-30  8:44       ` Michael Haggerty
2011-05-30  5:01   ` Miles Bader

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=4DE3222F.6030604@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.von.zweigbergk@gmail.com \
    /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.