git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
	Nanako Shiraishi <nanako3@lavabit.com>,
	John Tapsell <johnflux@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] Re: rebase -i: auto-squash commits
Date: Thu, 18 Jun 2009 10:44:06 +0200	[thread overview]
Message-ID: <4A39FE56.8070808@drmicha.warpmail.net> (raw)
In-Reply-To: <alpine.DEB.1.00.0906181030260.4848@intel-tinevez-2-302>

Johannes Schindelin venit, vidit, dixit 18.06.2009 10:33:
> Hi,
> 
> On Thu, 18 Jun 2009, Junio C Hamano wrote:
> 
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Wed, 17 Jun 2009, Junio C Hamano wrote:
>>> ...
>>>> The commit not only must begin with "squash to " but also there has to 
>>>> be a matching commit whose message begins with the remainder of the 
>>>> title of the "squash to" commit _in the range you are rebasing 
>>>> INTERACTIVELY_.
>>>>
>>>> In addition, the resulting rebase insn is presented in the editor, and 
>>>> in a rare case where you do have such a commit, you can rearrange it 
>>>> back.
>>>
>>> Well, that really sounds pretty awkward to me.  I regularly call such 
>>> commits "amend".  If there is a risk I confuse myself as to which commit 
>>> needs to be amended, I use "amend.<short-hint>".
>>>
>>> I'd really rather stay with "fixup".  And as I use single-letter commands 
>>> quite often, I'd also rather stay away from that magic "!".  And by 
>>> "magic" I really mean that: people will not find that magic intuitive at 
>>> all.
>>>
>>> My vote is for "fixup".
>>
>> I am too tired to either make the final judgement nor proposal on this 
>> topic now,
> 
> Okay, I'll add another point that should convince you that the commit 
> message is not the good place to trigger that behavior:
> 
> Interactive rebasing is about having made a quite messy patch series, 
> maybe having a few fixup commits, and then deciding how to clean it up.
> 
> The decision how to clean it up is very much a rebase-time decision, not a 
> commit-time decision.
> 
> For example, it is very easy to decide that you want to squash one fixup 
> after all instead of leaving it stand-alone.
> 
>> Of course we _could_ use notes for that, but that won't play well with
>> rebasing I suppose ...
> 
> Reminds me.  Nothing has happened on that front, right?

<!--#if expr="$SARCASM_ON" -->
No, but isn't that the true purpose of out-sourcing? You've got someone
else to blame now!
<!--#endif -->

Cheers,
Michael

  reply	other threads:[~2009-06-18  8:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-17 12:06 git rebase --interactive squash/squish/fold/rollup Minty
2009-06-17 12:55 ` John Tapsell
2009-06-17 13:45   ` Minty
2009-06-17 16:33   ` Junio C Hamano
2009-06-17 16:40     ` John Tapsell
2009-06-17 16:48     ` Paolo Bonzini
2009-06-17 17:05     ` John Koleszar
2009-06-17 20:50       ` John Tapsell
2009-06-17 18:20     ` Clemens Buchacher
2009-06-18 22:31       ` Minty
2009-06-17 21:33     ` [PATCH] rebase -i: auto-squash commits Nanako Shiraishi
2009-06-17 22:08       ` Johannes Schindelin
2009-06-18  0:11         ` [PATCH] " Nicolas Sebrecht
2009-06-18  5:07           ` Junio C Hamano
2009-06-18  8:06             ` Johannes Schindelin
2009-06-18  8:11               ` Jakub Narebski
2009-06-18  8:21                 ` Junio C Hamano
2009-06-18  8:26                   ` Johannes Schindelin
2009-06-18  8:17               ` Teemu Likonen
2009-06-18  8:29                 ` Johannes Schindelin
2009-06-18  8:44                   ` Teemu Likonen
2009-06-18 12:16                     ` Johannes Schindelin
2009-06-18 13:10                       ` Jakub Narebski
2009-06-18 14:04                   ` John Koleszar
2009-06-18  8:20               ` Junio C Hamano
2009-06-18  8:33                 ` Johannes Schindelin
2009-06-18  8:44                   ` Michael J Gruber [this message]
2009-06-19  7:18                   ` Miles Bader
2009-06-18 11:18                 ` Nicolas Sebrecht
2009-06-18  8:34               ` Matthieu Moy
2009-06-18  8:44                 ` Johannes Schindelin
2009-06-18  8:59                   ` Matthieu Moy
2009-06-18 10:59             ` Nicolas Sebrecht
2009-06-18  5:21       ` [PATCH] " Junio C Hamano
2009-06-18 21:55         ` [PATCH v2] rebase -i --autosquash: " Nanako Shiraishi
2009-06-18 22:35           ` Alex Riesen
2009-06-19 23:07           ` Wincent Colaiuta
2009-06-20  1:46             ` Nanako Shiraishi
2009-06-18  7:20       ` [PATCH] rebase -i: " Michael Haggerty
2009-06-18  7:54         ` Junio C Hamano

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=4A39FE56.8070808@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johnflux@gmail.com \
    --cc=nanako3@lavabit.com \
    --cc=nicolas.s.dev@gmx.fr \
    /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).