git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pete Harlan <pgit@pcharlan.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git list <git@vger.kernel.org>
Subject: Re: [PATCH/RFC] Allow empty commits during rebase -i
Date: Sun, 17 Jan 2010 18:11:33 -0800	[thread overview]
Message-ID: <4B53C355.1010109@pcharlan.com> (raw)
In-Reply-To: <7vljfww686.fsf@alter.siamese.dyndns.org>

On 01/17/2010 05:29 PM, Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
> 
>> I imagine an ideal version of this fix would make it so the use case I
>> presented here would work, but rebase -i would still prevent
>> introducing a new empty commit, or at least warn when it was
>> introducing one.  In the absence of that ideal fix, I think this
>> behavior is better than failing to handle this case.
> 
> Sorry, I actually tend to think that in the absense of that fix, your
> version introduces risky behaviour that only a corner-case use case
> benefits, and pros-and-cons doesn't look attractive enough.
> 
> Why not do something like:
> 
>     pick X a crap tree with a good message
>     pick Y revert X
>     pick Z a good tree with a crap message
> 
> -->
> 
>     # drop X
>     # drop Y
>     edit Z
> 
> and then run "git commit --amend -C X" when it is Z's turn to be
> processed?

That is another way to accomplish the same thing, but doesn't prevent
the current behavior from being confusing.

Part of the problem is that with the current behavior the user is sent
to the command line with:

  # Not currently on any branch.
  nothing to commit (working directory clean)

  Could not apply a0b17c5... Revert "Crap tree good message"

with HEAD pointed to X^.  Unsure of how to proceed from here, I
--aborted the rebase and copy/pasted the commit message I wanted and
resolved to track this down and fix it when I got a chance.

As it happens, "git rebase --continue" does exactly what I would have
wanted to happen, including putting me in an editor with all three
commit messages and succeeding when I exit the editor.  But without a
better message from git I don't expect a user to discover that.  And,
when rebase can continue just by being told so it would be nice if it
didn't require that user intervention.

If the introduction of empty commits that the user has asked for
(perhaps inadvertently) is considered too undesirable, then perhaps my
fix is too simple.  I'll think about how to do something more
sophisticated.

Thanks for your feedback,

--Pete

  reply	other threads:[~2010-01-18  2:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-18  1:12 [PATCH/RFC] Allow empty commits during rebase -i Pete Harlan
2010-01-18  1:29 ` Junio C Hamano
2010-01-18  2:11   ` Pete Harlan [this message]
2010-01-18  3:11     ` Junio C Hamano
2010-01-18 10:01     ` Johannes Schindelin

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=4B53C355.1010109@pcharlan.com \
    --to=pgit@pcharlan.com \
    --cc=Johannes.Schindelin@gmx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).