From: Nanako Shiraishi <nanako3@lavabit.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
Michael J Gruber <git@drmicha.warpmail.net>,
Michael Haggerty <mhagger@alum.mit.edu>,
git@vger.kernel.org
Subject: Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
Date: Sat, 05 Dec 2009 06:27:08 +0900 [thread overview]
Message-ID: <20091205062708.6117@nanako3.lavabit.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0912041945161.21557@intel-tinevez-2-302>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Hi,
>
> On Fri, 4 Dec 2009, Junio C Hamano wrote:
>
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>> > Michael J Gruber <git@drmicha.warpmail.net> writes:
>> >
>> >>> If the idea of a "fix" command is acceptable, then I would like to
>> >>> implement a further convenience: if a group of commits to be folded
>> >>> together includes *only* "fix" commits, then the first log message
>> >>> should be used without even opening an editor. But I would like to
>> >>> get a reaction to the "fix" command in general before doing so.
>> >>
>> >> I'd say that would make a useful command ("fix") even more useful, being
>> >> just the right counterpart to "reword" for trivial commit message fixes.
>> >
>> > +1 for fix, and +1 for the "don't even launch the editor" too.
>>
>> I like it, too. Also I vaguely recall that there was a series that died
>> that would have allowed you to give hints to help this behaviour at the
>> time you make "fix-up" commits; we may want to resurrect it on top of this
>> feature.
>
> I'll just repeat this exactly one more time: it is not always possible to
> know whether you make a fix-up commit, and it is not always possible to be
> sure that you want to amend the next time you do a rebase.
>
> So: Commit time is definitely a bad time to decide on the action in some
> future rebase event.
I think Junio is referring to this thread:
http://thread.gmane.org/gmane.comp.version-control.git/127923/focus=121874
The old patch added a convention to mark a fix-up commit
with a special string "!fixup" and refer to which commit
in the series it is fixing. It added --autosquash option
to rebase--interactive that tells it to move such a commit
to an appropriate place in the series and change its 'pick'
to 'squash'. I think with Michael's patches, it can change
'pick' to 'fix' instead.
I too think Michael's "fix" is a good feature, and in the
workflow by Shawn, he knows he is fixing up an earlier
commit, and he knows he doesn't want to add anything to
the message by the fix-up commit when he makes that commit
(how else would he have messages like "a", "s", or "foo").
I don't think your objection should block *others* (like
Shawn and Junio) who can decide when they make commits
from using the feature from my old patch to make it even
easier to clean up their topics. If *you* can't decide if
you want to amend or not when you make a fix-up commit, you
can leave your fix-up commits unmarked, run interactive
rebase without the --autosquash option, and use Michael's
'fix' manually. People who can sometimes but not always
decide when they make commits can do the same when they
can't.
Isn't it what Junio suggested by his "on top of this feature",
and wouldn't that make everybody happy?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
next prev parent reply other threads:[~2009-12-04 21:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 14:36 [PATCH 0/3] Add a "fix" command to "rebase --interactive" Michael Haggerty
2009-12-04 14:36 ` [PATCH 1/3] Better document the original repository layout Michael Haggerty
2009-12-04 14:52 ` Michael J Gruber
2009-12-04 16:51 ` Johannes Schindelin
2009-12-04 14:36 ` [PATCH 2/3] Set a couple more tags in the original repository Michael Haggerty
2009-12-04 16:52 ` Johannes Schindelin
2009-12-04 14:36 ` [PATCH 3/3] Add a command "fix" to rebase --interactive Michael Haggerty
2009-12-04 16:57 ` Johannes Schindelin
2009-12-04 17:40 ` Junio C Hamano
2009-12-04 17:44 ` Matthieu Moy
2009-12-04 18:44 ` Johannes Schindelin
2009-12-05 18:53 ` Junio C Hamano
2009-12-04 15:13 ` [PATCH 0/3] Add a "fix" command to "rebase --interactive" Michael J Gruber
2009-12-04 17:40 ` Matthieu Moy
2009-12-04 17:44 ` Junio C Hamano
2009-12-04 18:47 ` Johannes Schindelin
2009-12-04 21:27 ` Nanako Shiraishi [this message]
2009-12-05 7:39 ` Junio C Hamano
2009-12-08 3:13 ` [PATCH 0/3] Add a "fix" command to "rebase --interactive", [PATCH] rebase -i --autosquash: auto-squash commits Nanako Shiraishi
2009-12-08 3:28 ` [PATCH 0/3] Add a "fix" command to "rebase --interactive" Junio C Hamano
2009-12-08 6:01 ` Nanako Shiraishi
2009-12-08 7:43 ` Junio C Hamano
2009-12-08 9:24 ` Junio C Hamano
2009-12-08 9:35 ` Jeff King
2009-12-08 13:51 ` Sverre Rabbelier
2009-12-09 3:55 ` Nanako Shiraishi
2009-12-09 4:41 ` Aaron Cohen
2009-12-09 6:16 ` Junio C Hamano
2009-12-08 14:39 ` Matthieu Moy
2009-12-04 15:50 ` Shawn O. Pearce
2009-12-04 22:19 ` Björn Gustavsson
2009-12-04 22:29 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091205062708.6117@nanako3.lavabit.com \
--to=nanako3@lavabit.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).