From: "Øystein Walle" <oystwa@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] Pass amend to pre-commit hook
Date: Sun, 27 Sep 2015 22:09:02 +0000 (UTC) [thread overview]
Message-ID: <loom.20150928T000850-141@post.gmane.org> (raw)
In-Reply-To: 20150914144727.GA25003@sigill.intra.peff.net
Jeff King <peff <at> peff.net> writes:
>
> On Mon, Sep 14, 2015 at 01:14:20PM +0100, Alan Clucas wrote:
>
> > Pass a single parameter 'amend' to the pre-commit hook when performing a
> > commit amend.
>
> I think this is a sensible thing to want, and it has come up a few
> times. I'm not sure why the last round didn't get merged, though. Looks
> like it just slipped through the cracks.
>
> Here are the relevant threads:
>
> http://thread.gmane.org/gmane.comp.version-control.git/260122
>
> http://thread.gmane.org/gmane.comp.version-control.git/260245
>
> Looks like there was some question of what to pass in the normal,
> non-amend case. I've added interested parties from the original thread
> to the cc here.
>
> -Peff
>
There were so many different ways of solving them that we weren't able
to decide between them:
Assuming we give the string "amend" as the hook's argv[1], what to do
when --amend is not used? We can pass nothing, or the empty string, or
the string "noamend". Then there was the suggestion of exporting
GIT_AMEND=1 or something like that. In any case, what to do when we want
to pass more arguments? Should we let the hook check argv[1] to decide
whether --amend was used, argv[2] to check whether {some scenario here}
is the case? Or make the hook author effectively implement options
parsing?
And then it died out...
In my totally unprofessional opinion anything more complex than maybe
passing "amend" in argv[1] is unwarranted. Since I posted my first patch
almost a year ago there has been no discussion regarding passing other
information along to pre-commit. Furthermore --amend is the only thing I
know of that a pre-commit hook cannot discover on its own. On the other
hand the desire for this has popped up at least twice on #git in the
same time span.
Alan Clucas' solution looks fine to me. It is essentially the same as
mine. But mine had tests and whatnot ;-)
Øsse
prev parent reply other threads:[~2015-09-27 22:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 12:14 [PATCH] Pass amend to pre-commit hook Alan Clucas
2015-09-14 14:47 ` Jeff King
2015-09-14 16:49 ` Alan Clucas
2015-09-27 22:09 ` Øystein Walle [this message]
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=loom.20150928T000850-141@post.gmane.org \
--to=oystwa@gmail.com \
--cc=git@vger.kernel.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.
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.