git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).