From: Stephan Beyer <s-beyer@gmx.net>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jakub Narebski <jnareb@gmail.com>,
Pierre Habouzit <madcoder@debian.org>,
Daniel Barkalow <barkalow@iabervon.org>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [RFCv2/FYI] git-sequencer.txt
Date: Thu, 12 Jun 2008 17:29:28 +0200 [thread overview]
Message-ID: <20080612152928.GB6848@leksak.fem-net> (raw)
In-Reply-To: <48507C70.8010402@gnu.org>
Hi,
On Wed, Jun 11, 2008 at 06:31:28PM -0700,
Paolo Bonzini <bonzini@gnu.org> wrote to git@vger.kernel.org:
>> --collect-signoffs;;
>> Collect the Signed-by-off: lines of each commit and
>> add them to the squashed commit message.
>
> I think this makes sense only if -m/-F/-C/-c (see later) is used,
> because otherwise the default behavior would be to concatenate all
> messages and call the editor, right? Would it be a no-op if those
> options are not given?
No, because the default behavior is cat it all together and call the
editor, the user sees in the editor:
Message of commit 1
Signed-off-by: A
Message of commit 2
Signed-off-by: B
Message of commit 3
Signed-off-by: A
Signed-off-by: C
And with --collect-signoffs this could be like:
Message of commit 1
Message of commit 2
Message of commit 3
Signed-off-by: A
Signed-off-by: B
Signed-off-by: C
>> tag <tag>::
>> Set tag `<tag>` to the current HEAD,
>> see also linkgit:git-tag[1].
>> If another commit is tagged `<tag>`, it will lose this tag,
>> i.e. the tag will be reset to HEAD.
>
> Is this a lightweight or a heavyweight tag? I guess lightweight -- the
> tag command should probably support -a, -s and -u like git-tag does.
> Unless -c/-C/-F/-m is given, the sequencer will then run the editor.
It is a lightweight tag currently.
Well, I've taken it because it was in rebase-i of "next" and currently
I use it because it makes one merge test case really simple by tagging
the parents of the planned merge.
I don't know if it is really useful to sequencer users and I don't know
if its better to drop from the documentation but keep it for my test
case ;-)
Because I'm pretty unsure about it, I didn't change anything on "tag"
after Junio's complaints about it.
>> -C <commit-ish>::
>> --reuse-commit=<commit-ish>::
>> --reference=<commit-ish>::
>> Reuse message and authorship data from specified commit.
>
> Why --reference?
I know that it's inconsistent to git-commit and I hoped nobody would
notice. ;-)
The reason why I didn't want `-C' to be `--reuse-message' is:
1. it is a misleading long option name, and
2. some days ago the long option was not really documented,
so everyone and everything is using -C.
(See
git show bc47c29
and/or
git grep -e reuse-message
in git.git)
I think that --reuse-commit is much less misleading, since
--reuse-message-and-authorship is too long ;-)
And Joerg Sommer's patchset which migrated to next introduced the
term "reference merge" (see "git show d9711a80", the first "die" in the
first hunk), and I thought the term "reference" is nicer than
"reuse message and authorship". But, of course, I also see the
disadvantage that it can be mixed up with refs.
I still vote for "-C/--reuse-commit" and because nobody and
nothing uses --reuse-message in git-commit I even dare propose
to change it to --reuse-commit there.
>> -M <commit-ish>
>> --reuse-message=<commit-ish>::
>> Reuse message from specified commit.
>> Note, that only the commit message is reused
>> and not the authorship information.
This is something I'd like to keep.
> For consistency with git-commit I would think it's better to have
>
> -c <commit-ish>::
> -C <commit-ish>::
> --reedit-message=<commit-ish>::
> --reuse-message=<commit-ish>::
> Take existing commit object, and reuse the log message and the
> authorship information (including the timestamp) when creating
> the commit. With -C (or --reuse-message), the editor is not
> invoked; with -c (or --reedit-message) the user can further edit
> the commit message.
>
> (I know it's confusing that it's reusing the message too, but...)
Later you speak of using the -e option to force edit of the message.
I think that "-c" is not needed if you can use "-C f00babe -e".
> and then a separate option:
>
> -A
> --author-override::
> Force authorship information for commits created by the command
> to be the data in git's configuration files.
>
> ... if it is not too complicated to implement.
Currently you can pass --author as a general option.
Perhaps this is not as easy to handle for the user, but if we
really really really want the -A/--author-override, we can add it later.
> To satisfy Pierre's comment, you might also add a "-e" general option,
> which forces an invocation of the editor -- even if -C/-m/-F are given,
> and even if the command is pick/patch/merge. I guess that in order to
> support -C/-m/-F you already have to use git-cherry-pick and git-merge's
> --no-commit options, so it should not be hard to implement.
I hoped someone will come up with -e ;-)
So "reinvent" a general option -e/--edit that just goes sure to invoke
an editor should be fine.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
next prev parent reply other threads:[~2008-06-12 15:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-07 22:01 [RFC] git-sequencer.txt Stephan Beyer
2008-06-09 11:45 ` squashing patches (was: Re: [RFC] git-sequencer.txt) Stephan Beyer
2008-06-09 14:04 ` Johannes Schindelin
2008-06-09 15:10 ` squashing patches Paolo Bonzini
2008-06-09 15:43 ` Paolo Bonzini
2008-06-09 16:29 ` Stephan Beyer
2008-06-09 16:37 ` Paolo Bonzini
2008-06-09 20:29 ` [RFC/PATCH] Add git-squash tool and tests Stephan Beyer
2008-06-09 20:34 ` Johannes Schindelin
2008-06-09 20:53 ` Paolo Bonzini
2008-06-09 21:34 ` Johannes Schindelin
2008-06-09 23:42 ` Stephan Beyer
2008-06-10 0:26 ` Johannes Schindelin
2008-06-09 23:46 ` Stephan Beyer
2008-06-09 19:34 ` squashing patches Junio C Hamano
2008-06-09 20:43 ` Stephan Beyer
2008-06-09 20:53 ` Jeff King
2008-06-09 23:57 ` Stephan Beyer
2008-06-10 1:00 ` Jeff King
2008-06-09 21:02 ` Junio C Hamano
2008-06-10 0:38 ` Stephan Beyer
2008-06-09 16:49 ` [RFC] git-sequencer.txt Jakub Narebski
2008-06-10 1:21 ` Stephan Beyer
2008-06-10 4:46 ` Christian Couder
2008-06-10 8:59 ` Stephan Beyer
2008-06-11 4:10 ` Christian Couder
2008-06-11 17:07 ` Daniel Barkalow
2008-06-10 6:17 ` Jakub Narebski
2008-06-12 0:22 ` [RFCv2/FYI] git-sequencer.txt Stephan Beyer
2008-06-12 1:31 ` Paolo Bonzini
2008-06-12 15:29 ` Stephan Beyer [this message]
2008-06-12 15:38 ` [RFC/PATCH] git-commit: Change --reuse-message to --reuse-commit Stephan Beyer
2008-06-12 15:56 ` [RFCv2/FYI] git-sequencer.txt Paolo Bonzini
2008-06-12 5:16 ` Junio C Hamano
2008-06-12 17:07 ` Stephan Beyer
2008-06-13 5:04 ` Paolo Bonzini
2008-06-13 12:16 ` Stephan Beyer
2008-06-13 14:42 ` Paolo Bonzini
2008-06-13 19:24 ` Olivier Marin
2008-06-12 14:10 ` Jakub Narebski
2008-06-12 17:20 ` Stephan Beyer
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=20080612152928.GB6848@leksak.fem-net \
--to=s-beyer@gmx.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=barkalow@iabervon.org \
--cc=bonzini@gnu.org \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=madcoder@debian.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.
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).