From: Johannes Sixt <j.sixt@viscovery.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>,
Nasser Grainawi <nasser@codeaurora.org>,
Martin Fick <mfick@codeaurora.org>,
james.moger@gitblit.com, Thomas Koch <thomas@koch.ro>,
Jeremy Rosen <jeremy.rosen@openwide.fr>,
Git Mailing List <git@vger.kernel.org>,
Shawn Pearce <spearce@spearce.org>
Subject: Re: RFE: support change-id generation natively
Date: Fri, 25 Oct 2013 08:37:28 +0200 [thread overview]
Message-ID: <526A11A8.90200@viscovery.net> (raw)
In-Reply-To: <xmqqzjpymo4y.fsf@gitster.dls.corp.google.com>
Am 10/24/2013 22:04, schrieb Junio C Hamano:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>> That said, I don't think that --change-id option that the user must not
>> forget to use is any better than a hook that the user must not forget to
>> install.
>
> That is why I said this in my first response to this thread:
>
>>> ... We may even want to
>>> introduce commit.changeId boolean configuration variable if we did
>>> so.
That's only slightly different and still "must not forget to set".
But I am more concerned that a non-volatile change-id is totally outside
the Git data model. After we have git commit --change-id, what will be the
next requests for enhancement? 'git merge' and 'git cherry-pick' take a
change-id? Where will it end?
We could ship a git-gerrit-commit wrapper script in contrib that adds the
change-id and that people can alias their 'git ci' to globally or on a
per-repo basis.
-- Hannes
next prev parent reply other threads:[~2013-10-25 6:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 14:48 RFE: support change-id generation natively james.moger
2013-10-21 14:51 ` Jeremy Rosen
2013-10-21 15:41 ` james.moger
2013-10-21 16:35 ` Shawn Pearce
2013-10-21 16:38 ` Ondřej Bílka
2013-10-21 23:07 ` Shawn Pearce
2013-10-21 18:29 ` Thomas Koch
2013-10-21 18:40 ` james.moger
2013-10-21 18:49 ` Martin Fick
2013-10-22 19:50 ` Junio C Hamano
2013-10-22 20:06 ` Pyeron, Jason J CTR (US)
2013-10-22 20:43 ` Junio C Hamano
2013-10-23 6:36 ` Duy Nguyen
2013-10-23 16:00 ` Junio C Hamano
2013-10-24 2:07 ` Duy Nguyen
2013-10-24 4:11 ` Nasser Grainawi
2013-10-24 5:25 ` Duy Nguyen
2013-10-24 6:01 ` Johannes Sixt
2013-10-24 12:11 ` james.moger
2013-10-24 12:51 ` Thomas Koch
2013-10-24 13:31 ` Duy Nguyen
2013-10-24 20:04 ` Junio C Hamano
2013-10-25 6:37 ` Johannes Sixt [this message]
2013-10-21 23:10 ` Shawn Pearce
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=526A11A8.90200@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=james.moger@gitblit.com \
--cc=jeremy.rosen@openwide.fr \
--cc=mfick@codeaurora.org \
--cc=nasser@codeaurora.org \
--cc=pclouds@gmail.com \
--cc=spearce@spearce.org \
--cc=thomas@koch.ro \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.