git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH 2/2] Catch and handle git-commit failures in git-rebase --interactive
Date: Tue, 18 Dec 2007 23:03:59 -0800	[thread overview]
Message-ID: <7vr6hjw4gw.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20071219064500.GB8915@spearce.org> (Shawn O. Pearce's message of "Wed, 19 Dec 2007 01:45:00 -0500")

"Shawn O. Pearce" <spearce@spearce.org> writes:

>  Comments welcome.  This is on top of my 1/2 patch but we could
>  drop my 1/2 and rewrite this to not use --no-verify, but handle
>  the git-commit error correctly.
>
>  However that would force users to fix whitespace errors in later
>  patches in a series if they use -i, even though non-i wouldn't
>  require that sort of fix-up.  So I think we should do both patches
>  in the series.

I agree with both patches.

When one wants to use rebase to fix-up whitespace breakage in patches in
bulk, you can set apply.whitespace to "fix".  One bad side effect of
this is that if you usually have apply.whitespace set to "fix" (because
you need to accept a lot of patches but your contributers tend to give
crappy patches), you need to temporarily change the configuration while
rebasing if you do not want to preserve intentional whitespace breakages
(e.g. ones in test scripts).  This can be argued either a feature or a
misfeature.

But rebase -i breaking and squashing upon commit failure (including
pre-commit safety) cannot be called either feature nor misfeature --- it
is an outright bug.

  reply	other threads:[~2007-12-19  7:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-19  6:45 [PATCH 2/2] Catch and handle git-commit failures in git-rebase --interactive Shawn O. Pearce
2007-12-19  7:03 ` Junio C Hamano [this message]
2007-12-19 12:21 ` 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=7vr6hjw4gw.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /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).