From: Junio C Hamano <gitster@pobox.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Phil Hord <phil.hord@gmail.com>
Subject: Re: [PATCH v4 2/4] git-cherry-pick: Add keep-redundant-commits option
Date: Wed, 11 Apr 2012 20:15:15 -0700 [thread overview]
Message-ID: <7vty0phc8s.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120411235509.GB16937@hmsreliant.think-freely.org> (Neil Horman's message of "Wed, 11 Apr 2012 19:55:09 -0400")
Neil Horman <nhorman@tuxdriver.com> writes:
>> > -static int run_git_commit(const char *defmsg, struct replay_opts *opts)
>> > +int run_git_commit(const char *defmsg, struct replay_opts *opts, int empty)
>> > {
>> > - /* 7 is max possible length of our args array including NULL */
>> > - const char *args[7];
>> > - int i = 0;
>> > + struct argv_array array;
>> > + int rc;
>> > +
>> > + if (!empty && !opts->keep_if_made_empty) {
>> > + unsigned char head_sha1[20];
>> > + struct commit *head_commit;
>> > + int need_free = 0;
>> > +
>> > + resolve_ref_unsafe("HEAD", head_sha1, 1, NULL);
>> > + head_commit = lookup_commit(head_sha1);
>>
>> No error checking whatsoever? HEAD might be pointing at a branch that
>> hasn't been born, for example.
>>
> Sorry, I had presumed that HEAD could be guaranteed to be good here, given that
> we validate it in rollback_single_pick via read_ref_full. But I can add
> additional checking here.
As long as it is clear that we always have "HEAD" here, it is not strictly
necessary, but we'd probably feel better, especially now that the function
is (for some reason) made into a global one and may gain other new callers
outside this file scope.
>> > if (opts->allow_empty)
>> > - args[i++] = "--allow-empty";
>> > + argv_array_push(&array, "--allow-empty");
>>
>> If --keep-if-made-empty is not given but --allow-empty was, it is fine to
>> give --allow-empty here, but otherwise, it logically is iffy and is likely
>> to become a cause of future bugs to pass --allow-empty to "git commit",
>> even though the earlier check _ought_ to catch problematic cases, no?
>>
> Not sure I follow your reasoning here. We need to pass allow-empty to git
> commit here if git cherry-pick set either allow-empty or keep-redundant-commits
> (the latter setting opts->empty), Can you give an example of what might be
> problematic in the future?
Thinking about it again, I think this part of your patch is correct.
We may pass an index that yields the same tree as "HEAD" if the original
was empty, or the original was not empty but the merge found the commit
unneeded. In either case, if "--keep-unnecessary" or "--allow-empty" was
given, we want to record the empty commit, and opts->allow_empty is set
when either option was given from the command line.
Thanks.
next prev parent reply other threads:[~2012-04-12 3:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Enhance git-rebases flexibiilty in handling empty commits>
2012-04-11 20:21 ` [PATCH v4 0/4] Enhance git-rebases flexibiilty in handling empty commits Neil Horman
2012-04-11 20:21 ` [PATCH v4 1/4] git-cherry-pick: add allow-empty option Neil Horman
2012-04-11 20:21 ` [PATCH v4 2/4] git-cherry-pick: Add keep-redundant-commits option Neil Horman
2012-04-11 20:47 ` Junio C Hamano
2012-04-11 23:35 ` Neil Horman
2012-04-11 20:57 ` Junio C Hamano
2012-04-11 23:55 ` Neil Horman
2012-04-12 3:15 ` Junio C Hamano [this message]
2012-04-12 10:49 ` Neil Horman
2012-04-11 20:21 ` [PATCH v4 3/4] git-cherry-pick: Add test to validate new options Neil Horman
2012-04-11 21:06 ` Junio C Hamano
2012-04-11 20:21 ` [PATCH v4 4/4] git-rebase: add keep_empty flag Neil Horman
2012-04-11 21:08 ` Junio C Hamano
2012-04-11 23:59 ` Neil Horman
2012-04-12 3:16 ` Junio C Hamano
2012-04-12 15:58 ` Neil Horman
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=7vty0phc8s.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=peff@peff.net \
--cc=phil.hord@gmail.com \
/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 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 NNTP newsgroup(s).