All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] rebase: learn --discard subcommand
Date: Sun, 29 May 2011 08:50:19 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1105290841400.28815@debian> (raw)
In-Reply-To: <BANLkTim-Wva018BFeTUPqZuiK02-X01XJQ@mail.gmail.com>

On Sat, 28 May 2011, Ramkumar Ramachandra wrote:

> > I used "rm -r" without -f to match how it is done in --abort, but
> > maybe -f should be used? That is what we recommend to the end-user to
> > use today.
> 
> If you've verified that a rebase is already in progress, I don't see
> the point of using '-f'. Otherwise, it should error out and say that
> "no rebase is in progress", like the other command-line options
> currently do.

Yep, it does verify that a rebase is in progress. I think rm without
-f still asks the user to confirm if the file is read-only. I can't
see why that would happen, so maybe it's good to have the user confirm
it it does happen.

> > A difference from --abort is that --discard does not clear
> > rerere. Need this be mentioned in the documentation?
> 
> It depends on what you're expecting the user to do in this detached
> HEAD state, no?

The subcommand will most likely be run when the user had forgotten the
current rebase and tries to start a new rebase and get's the message
that a rebase is already in progress. At this point, the user is not
necessarily in a detached HEAD state any more.

/Martin

  reply	other threads:[~2011-05-29 12:50 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 [this message]
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
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=alpine.DEB.2.00.1105290841400.28815@debian \
    --to=martin.von.zweigbergk@gmail.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.