threads / patch / 33966

v2, 8 partscherry-pick: improvements

Subject: [PATCH v2 0/8] cherry-pick: improvements

## tl;dr

33 messages between May 29, 2013 and Jun 6, 2013. Diffs are folded; open one to read it.

replies: 32people: 5as markdown or json

Felipe Contreras· May 29, 2013, 03:56 UTC · lore
Hi,

Here's a bunch of changes to make cherry-pick (and revert) more useful. In particular; this makes it more friendly for 'git rebase.

Felipe Contreras (8):
  sequencer: remove useless indentation
  sequencer: trivial fix
  cherry-pick: add --skip-empty option
  cherry-pick: store rewritten commits
  sequencer: run post-rewrite hook
  cherry-pick: add support to copy notes
  revert/cherry-pick: add --quiet option
  revert/cherry-pick: add --skip option
 Documentation/git-cherry-pick.txt   |  10 +-
 Documentation/git-revert.txt        |   7 +-
 Documentation/sequencer.txt         |   3 +
 builtin/revert.c                    |  11 ++
 sequencer.c                         | 230 ++++++++++++++++++++++++++++++++++--
 sequencer.h                         |   7 +-
 t/t3500-cherry.sh                   |  32 +++++
 t/t3508-cherry-pick-many-commits.sh |  13 ++
 t/t3510-cherry-pick-sequence.sh     |  12 ++
 9 files changed, 310 insertions(+), 15 deletions(-)
-- 
1.8.3.rc3.312.g47657de
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 1/8] sequencer: remove useless indentation

By using good ol' goto.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 sequencer.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)
Show changes to sequencer.c +9 −7
diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..b4989ba 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -474,7 +474,7 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 	struct commit_message msg = { NULL, NULL, NULL, NULL, NULL };
 	char *defmsg = NULL;
 	struct strbuf msgbuf = STRBUF_INIT;
-	int res, unborn = 0;
+	int res, unborn = 0, allow;
 
 	if (opts->no_commit) {
 		/*
@@ -624,14 +624,16 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 		      msg.subject);
 		print_advice(res == 1, opts);
 		rerere(opts->allow_rerere_auto);
-	} else {
-		int allow = allow_empty(opts, commit);
-		if (allow < 0)
-			return allow;
-		if (!opts->no_commit)
-			res = run_git_commit(defmsg, opts, allow);
+		goto leave;
 	}
 
+	allow = allow_empty(opts, commit);
+	if (allow < 0)
+		return allow;
+	if (!opts->no_commit)
+		res = run_git_commit(defmsg, opts, allow);
+
+leave:
 	free_message(&msg);
 	free(defmsg);
 
-- 
1.8.3.rc3.312.g47657de
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 2/8] sequencer: trivial fix

We should free objects before leaving.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 sequencer.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
Show changes to sequencer.c +4 −2
diff --git a/sequencer.c b/sequencer.c
index b4989ba..f7be7d8 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -628,8 +628,10 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 	}
 
 	allow = allow_empty(opts, commit);
-	if (allow < 0)
-		return allow;
+	if (allow < 0) {
+		res = allow;
+		goto leave;
+	}
 	if (!opts->no_commit)
 		res = run_git_commit(defmsg, opts, allow);
 
-- 
1.8.3.rc3.312.g47657de
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 3/8] cherry-pick: add --skip-empty option

Pretty much what it says on the tin.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/git-cherry-pick.txt   |  3 +++
 builtin/revert.c                    |  2 ++
 sequencer.c                         |  6 ++++++
 sequencer.h                         |  1 +
 t/t3508-cherry-pick-many-commits.sh | 13 +++++++++++++
 5 files changed, 25 insertions(+)
Show changes to 5 files +25 −0

Documentation/git-cherry-pick.txt, builtin/revert.c, sequencer.c, sequencer.h, t/t3508-cherry-pick-many-commits.sh

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index c205d23..fccd936 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -129,6 +129,9 @@ effect to your index in a row.
 	redundant commits are ignored.  This option overrides that behavior and
 	creates an empty commit object.  Implies `--allow-empty`.
 
+--skip-empty::
+	Instead of failing, skip commits that are or become empty.
+
 --strategy=<strategy>::
 	Use the given merge strategy.  Should only be used once.
 	See the MERGE STRATEGIES section in linkgit:git-merge[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 0401fdb..0e5ce71 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -118,6 +118,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 		OPT_END(),
 		OPT_END(),
 		OPT_END(),
+		OPT_END(),
 	};
 
 	if (opts->action == REPLAY_PICK) {
@@ -127,6 +128,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 			OPT_BOOLEAN(0, "allow-empty", &opts->allow_empty, N_("preserve initially empty commits")),
 			OPT_BOOLEAN(0, "allow-empty-message", &opts->allow_empty_message, N_("allow commits with empty messages")),
 			OPT_BOOLEAN(0, "keep-redundant-commits", &opts->keep_redundant_commits, N_("keep redundant, empty commits")),
+			OPT_BOOLEAN(0, "skip-empty", &opts->skip_empty, N_("skip empty commits")),
 			OPT_END(),
 		};
 		if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra))
diff --git a/sequencer.c b/sequencer.c
index f7be7d8..d3c7d72 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -627,6 +627,12 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 		goto leave;
 	}
 
+	if (opts->skip_empty && is_index_unchanged() == 1) {
+		warning(_("skipping %s... %s"),
+			find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
+			msg.subject);
+		goto leave;
+	}
 	allow = allow_empty(opts, commit);
 	if (allow < 0) {
 		res = allow;
diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..3b04844 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -34,6 +34,7 @@ struct replay_opts {
 	int allow_empty;
 	int allow_empty_message;
 	int keep_redundant_commits;
+	int skip_empty;
 
 	int mainline;
 
diff --git a/t/t3508-cherry-pick-many-commits.sh b/t/t3508-cherry-pick-many-commits.sh
index 19c99d7..3dc19c6 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -187,4 +187,17 @@ test_expect_success 'cherry-pick --stdin works' '
 	check_head_differs_from fourth
 '
 
+test_expect_success 'cherry-pick skip empty' '
+	git clean -fxd &&
+	git checkout -b empty fourth &&
+	git commit --allow-empty -m empty &&
+	test_commit ontop &&
+	git checkout -f master &&
+	git reset --hard fourth &&
+	git cherry-pick --skip-empty fourth..empty &&
+	echo ontop > expected &&
+	git log --format=%s fourth..HEAD > actual
+	test_cmp expected actual
+'
+
 test_done
-- 
1.8.3.rc3.312.g47657de
Junio C Hamano· Jun 3, 2013, 18:40 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 21 quoted lines
> Pretty much what it says on the tin.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  Documentation/git-cherry-pick.txt   |  3 +++
>  builtin/revert.c                    |  2 ++
>  sequencer.c                         |  6 ++++++
>  sequencer.h                         |  1 +
>  t/t3508-cherry-pick-many-commits.sh | 13 +++++++++++++
>  5 files changed, 25 insertions(+)
>
> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
> index c205d23..fccd936 100644
> --- a/Documentation/git-cherry-pick.txt
> +++ b/Documentation/git-cherry-pick.txt
> @@ -129,6 +129,9 @@ effect to your index in a row.
>  	redundant commits are ignored.  This option overrides that behavior and
>  	creates an empty commit object.  Implies `--allow-empty`.
>  
> +--skip-empty::
> +	Instead of failing, skip commits that are or become empty.

Not quite sure. Is this "instead of recording an empty commit," (which may or may not fail depending on the allow-empty settings)?

If that is what this patch is meant to do, I think the change makes sense.

Show 74 quoted lines
>  --strategy=<strategy>::
>  	Use the given merge strategy.  Should only be used once.
>  	See the MERGE STRATEGIES section in linkgit:git-merge[1]
> diff --git a/builtin/revert.c b/builtin/revert.c
> index 0401fdb..0e5ce71 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -118,6 +118,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
>  		OPT_END(),
>  		OPT_END(),
>  		OPT_END(),
> +		OPT_END(),
>  	};
>  
>  	if (opts->action == REPLAY_PICK) {
> @@ -127,6 +128,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
>  			OPT_BOOLEAN(0, "allow-empty", &opts->allow_empty, N_("preserve initially empty commits")),
>  			OPT_BOOLEAN(0, "allow-empty-message", &opts->allow_empty_message, N_("allow commits with empty messages")),
>  			OPT_BOOLEAN(0, "keep-redundant-commits", &opts->keep_redundant_commits, N_("keep redundant, empty commits")),
> +			OPT_BOOLEAN(0, "skip-empty", &opts->skip_empty, N_("skip empty commits")),
>  			OPT_END(),
>  		};
>  		if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra))
> diff --git a/sequencer.c b/sequencer.c
> index f7be7d8..d3c7d72 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -627,6 +627,12 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
>  		goto leave;
>  	}
>  
> +	if (opts->skip_empty && is_index_unchanged() == 1) {
> +		warning(_("skipping %s... %s"),
> +			find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
> +			msg.subject);
> +		goto leave;
> +	}
>  	allow = allow_empty(opts, commit);
>  	if (allow < 0) {
>  		res = allow;
> diff --git a/sequencer.h b/sequencer.h
> index 1fc22dc..3b04844 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -34,6 +34,7 @@ struct replay_opts {
>  	int allow_empty;
>  	int allow_empty_message;
>  	int keep_redundant_commits;
> +	int skip_empty;
>  
>  	int mainline;
>  
> diff --git a/t/t3508-cherry-pick-many-commits.sh b/t/t3508-cherry-pick-many-commits.sh
> index 19c99d7..3dc19c6 100755
> --- a/t/t3508-cherry-pick-many-commits.sh
> +++ b/t/t3508-cherry-pick-many-commits.sh
> @@ -187,4 +187,17 @@ test_expect_success 'cherry-pick --stdin works' '
>  	check_head_differs_from fourth
>  '
>  
> +test_expect_success 'cherry-pick skip empty' '
> +	git clean -fxd &&
> +	git checkout -b empty fourth &&
> +	git commit --allow-empty -m empty &&
> +	test_commit ontop &&
> +	git checkout -f master &&
> +	git reset --hard fourth &&
> +	git cherry-pick --skip-empty fourth..empty &&
> +	echo ontop > expected &&
> +	git log --format=%s fourth..HEAD > actual
> +	test_cmp expected actual
> +'
> +
>  test_done
Junio C Hamano· Jun 3, 2013, 19:21 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Junio C Hamano <gitster@pobox.com> writes:
Show 29 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Pretty much what it says on the tin.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>  Documentation/git-cherry-pick.txt   |  3 +++
>>  builtin/revert.c                    |  2 ++
>>  sequencer.c                         |  6 ++++++
>>  sequencer.h                         |  1 +
>>  t/t3508-cherry-pick-many-commits.sh | 13 +++++++++++++
>>  5 files changed, 25 insertions(+)
>>
>> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
>> index c205d23..fccd936 100644
>> --- a/Documentation/git-cherry-pick.txt
>> +++ b/Documentation/git-cherry-pick.txt
>> @@ -129,6 +129,9 @@ effect to your index in a row.
>>  	redundant commits are ignored.  This option overrides that behavior and
>>  	creates an empty commit object.  Implies `--allow-empty`.
>>  
>> +--skip-empty::
>> +	Instead of failing, skip commits that are or become empty.
>
> Not quite sure.  Is this "instead of recording an empty commit,"
> (which may or may not fail depending on the allow-empty settings)?
>
> If that is what this patch is meant to do, I think the change makes
> sense.
Also what I noticed while looking at 4-5/8.
Wouldn't "revert --skip-empty A..B" make sense as well?
Felipe Contreras· Jun 3, 2013, 21:10 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 26 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Pretty much what it says on the tin.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>  Documentation/git-cherry-pick.txt   |  3 +++
>>  builtin/revert.c                    |  2 ++
>>  sequencer.c                         |  6 ++++++
>>  sequencer.h                         |  1 +
>>  t/t3508-cherry-pick-many-commits.sh | 13 +++++++++++++
>>  5 files changed, 25 insertions(+)
>>
>> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
>> index c205d23..fccd936 100644
>> --- a/Documentation/git-cherry-pick.txt
>> +++ b/Documentation/git-cherry-pick.txt
>> @@ -129,6 +129,9 @@ effect to your index in a row.
>>       redundant commits are ignored.  This option overrides that behavior and
>>       creates an empty commit object.  Implies `--allow-empty`.
>>
>> +--skip-empty::
>> +     Instead of failing, skip commits that are or become empty.
>
> Not quite sure.  Is this "instead of recording an empty commit,"
> (which may or may not fail depending on the allow-empty settings)?
We are explaining --skip-empty, not --allow-empty.
-- 
Felipe Contreras
Junio C Hamano· Jun 3, 2013, 21:45 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 29 quoted lines
> On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Pretty much what it says on the tin.
>>>
>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>> ---
>>>  Documentation/git-cherry-pick.txt   |  3 +++
>>>  builtin/revert.c                    |  2 ++
>>>  sequencer.c                         |  6 ++++++
>>>  sequencer.h                         |  1 +
>>>  t/t3508-cherry-pick-many-commits.sh | 13 +++++++++++++
>>>  5 files changed, 25 insertions(+)
>>>
>>> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
>>> index c205d23..fccd936 100644
>>> --- a/Documentation/git-cherry-pick.txt
>>> +++ b/Documentation/git-cherry-pick.txt
>>> @@ -129,6 +129,9 @@ effect to your index in a row.
>>>       redundant commits are ignored.  This option overrides that behavior and
>>>       creates an empty commit object.  Implies `--allow-empty`.
>>>
>>> +--skip-empty::
>>> +     Instead of failing, skip commits that are or become empty.
>>
>> Not quite sure.  Is this "instead of recording an empty commit,"
>> (which may or may not fail depending on the allow-empty settings)?
>
> We are explaining --skip-empty, not --allow-empty.

Exactly. That is why I found the "Instead of failing" questionable. It is very easy to read the above as "commits that are or become empty usually causes the command to fail, and this is a way to cause it not to fail.".

It is true that
    cherry-pick A
when A becomes empty, dies.  But
    cherry-pick --allow-empty A

when A becomes empty, does not fail, but still does create an empty commit. A large difference with --skip-empty, which applies to use scenario different from --allow-empty was meant to address, is that

    cherry-pick --skip-empty A

when A becomes empty, does not fail and does not create an empty commit, either.

I think just "Skip commits that are or become empty" without saying "Instead of failing," is fine, too.

Felipe Contreras· Jun 4, 2013, 17:10 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Mon, Jun 3, 2013 at 4:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 53 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> Pretty much what it says on the tin.
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>> ---
>>>>  Documentation/git-cherry-pick.txt   |  3 +++
>>>>  builtin/revert.c                    |  2 ++
>>>>  sequencer.c                         |  6 ++++++
>>>>  sequencer.h                         |  1 +
>>>>  t/t3508-cherry-pick-many-commits.sh | 13 +++++++++++++
>>>>  5 files changed, 25 insertions(+)
>>>>
>>>> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
>>>> index c205d23..fccd936 100644
>>>> --- a/Documentation/git-cherry-pick.txt
>>>> +++ b/Documentation/git-cherry-pick.txt
>>>> @@ -129,6 +129,9 @@ effect to your index in a row.
>>>>       redundant commits are ignored.  This option overrides that behavior and
>>>>       creates an empty commit object.  Implies `--allow-empty`.
>>>>
>>>> +--skip-empty::
>>>> +     Instead of failing, skip commits that are or become empty.
>>>
>>> Not quite sure.  Is this "instead of recording an empty commit,"
>>> (which may or may not fail depending on the allow-empty settings)?
>>
>> We are explaining --skip-empty, not --allow-empty.
>
> Exactly.  That is why I found the "Instead of failing" questionable.
> It is very easy to read the above as "commits that are or become
> empty usually causes the command to fail, and this is a way to cause
> it not to fail.".
>
> It is true that
>
>     cherry-pick A
>
> when A becomes empty, dies.  But
>
>     cherry-pick --allow-empty A
>
> when A becomes empty, does not fail, but still does create an empty
> commit.  A large difference with --skip-empty, which applies to use
> scenario different from --allow-empty was meant to address, is that
>
>     cherry-pick --skip-empty A
>
> when A becomes empty, does not fail and does not create an empty
> commit, either.
We are not explaining --allow-empty.

What happens when you do --skip-empty --allow-empty? Somebody suggested a new option, so we could do --foo-empty=skip,allow to clarify that.

> I think just "Skip commits that are or become empty" without saying
> "Instead of failing," is fine, too.

I think "Instead of failing" makes perfect sense, because it's not our job to describe what other options do, simply explain what this option do. If the user is interested in other options, he can read them in the help for those.

-- 
Felipe Contreras
Junio C Hamano· Jun 4, 2013, 17:35 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 8 quoted lines
>> I think just "Skip commits that are or become empty" without saying
>> "Instead of failing," is fine, too.
>
> I think "Instead of failing" makes perfect sense, because it's not our
> job to describe what other options do,...
> ...
> simply explain what this option
> do.

Which means "Skip commits" and nothing else. Saying "Instead of failing" explains what would happen if you ran the command without any option, which is entirely irrelevant, just like the case when you ran the command without an unrelated option --allow-empty.

We share the same "the --skip-empty option does not have anything to do with the --allow-empty option, and we do not have to say anything about what happens when the command is run with that unrelated option".

But we are viewing it from a different angle.
Felipe Contreras· Jun 4, 2013, 17:40 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Tue, Jun 4, 2013 at 12:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> I think just "Skip commits that are or become empty" without saying
>>> "Instead of failing," is fine, too.
>>
>> I think "Instead of failing" makes perfect sense, because it's not our
>> job to describe what other options do,...
>> ...
>> simply explain what this option
>> do.
>
> Which means "Skip commits" and nothing else.  Saying "Instead of
> failing" explains what would happen if you ran the command without
> any option,
Which *BY FAR* the most widely use-case of cherry-pick. What? 99% of the time?
> which is entirely irrelevant,
It's totally and completely relevant. It couldn't be more relevant.
> We share the same "the --skip-empty option does not have anything to
> do with the --allow-empty option, and we do not have to say anything
> about what happens when the command is run with that unrelated
> option".
You didn't answer, what happens when you run --skip-empty and --allow-empty?
-- 
Felipe Contreras
Junio C Hamano· Jun 4, 2013, 18:30 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Felipe Contreras <felipe.contreras@gmail.com> writes:
> You didn't answer, what happens when you run --skip-empty and --allow-empty?
I'll answer to a slightly different question: What should happen?

I think it should error out, because --allow-empty is about "allowing empty commits to be preserved", and --skip-empty is about "skipping empty commits (as it says on the package)".

Felipe Contreras· Jun 5, 2013, 14:52 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Tue, Jun 4, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> You didn't answer, what happens when you run --skip-empty and --allow-empty?
>
> I'll answer to a slightly different question: What should happen?
>
> I think it should error out, because --allow-empty is about
> "allowing empty commits to be preserved", and --skip-empty is about
> "skipping empty commits (as it says on the package)".
Exactly, so they are related after all. However, --allow-empty says this:
"By default, cherry-picking an empty commit will fail,"
Should we change that too if we introduce --skip-empty?

I don't think so. I think it makes more sense to have a new --empty-commits=[keep|skip|fail] option, so we don't have to document how each option affects the other, and what is the default. Or rather; the option documents that.

In fact, it might make sense to change the default in v2.0 to --empty-commits=skip. If it makes sense in 'git rebase', why doesn't it in 'git cherry-pick'?

-- 
Felipe Contreras
Junio C Hamano· Jun 5, 2013, 18:13 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 14 quoted lines
> On Tue, Jun 4, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> You didn't answer, what happens when you run --skip-empty and --allow-empty?
>>
>> I'll answer to a slightly different question: What should happen?
>>
>> I think it should error out, because --allow-empty is about
>> "allowing empty commits to be preserved", and --skip-empty is about
>> "skipping empty commits (as it says on the package)".
>
> Exactly, so they are related after all. However, --allow-empty says this:
>
> "By default, cherry-picking an empty commit will fail,"

OK, that is a very good point. Especially because by the time reader reaches this new description, --allow-empty has already mentioned this, we can just be brief and it is sufficient to say "Instead of failing," upfront.

> In fact, it might make sense to change the default in v2.0 to
> --empty-commits=skip. If it makes sense in 'git rebase', why doesn't
> it in 'git cherry-pick'?

I think the primary reason behind the "Why are you picking a no-op? Let me stop to make sure you didn't make a mistake." is because cherry-pick and revert have long been operations for a single commit explicitly given by the user, not bunch of commits in a range.

These two operating modes are conceptually very different, even when we consider scripted use. A script that feeds one commit at a time has a chance to do patch equivalence or user-interactive filtering on its own, and would be helped by the "are you sure you meant to record that no-op?" check if it filtered in a wrong way (e.g. the user specified an empty commit by mistake). One that feeds a range, on the other hand, relies on or at least expects cherry-pick to have such smart, and a smarter cherry-pick could select what to pick from the given range.

In the longer term, especially if we envision to move large part of logic to prepare the sequencer insn list from rebase to cherry-pick, a ranged cherry-pick should learn a way to filter the range with patch equivalence, for example. Once that happens, the behaviour would become inconsistent at the end-user level if we stopped at a commit only because it was not exactly patch equivalent to another one that is already on the branch we are cherry-picking to, but ended up to be a no-op, while we did not stop at another commit because patch equivalence filtered it out beforehand to skip it. Skipping a no-op by default would remove that inconsistency.

So in that sense, one could argue that it may be a bugfix to skip commits that become no-op when replayed, when picking a range of commits (but not a single one). And I do not think you would need to wait until 2.0 for such a change.

Felipe Contreras· Jun 6, 2013, 05:01 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Wed, Jun 5, 2013 at 1:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 30 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, Jun 4, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> You didn't answer, what happens when you run --skip-empty and --allow-empty?
>>>
>>> I'll answer to a slightly different question: What should happen?
>>>
>>> I think it should error out, because --allow-empty is about
>>> "allowing empty commits to be preserved", and --skip-empty is about
>>> "skipping empty commits (as it says on the package)".
>>
>> Exactly, so they are related after all. However, --allow-empty says this:
>>
>> "By default, cherry-picking an empty commit will fail,"
>
> OK, that is a very good point.  Especially because by the time
> reader reaches this new description, --allow-empty has already
> mentioned this, we can just be brief and it is sufficient to say
> "Instead of failing," upfront.
>
>> In fact, it might make sense to change the default in v2.0 to
>> --empty-commits=skip. If it makes sense in 'git rebase', why doesn't
>> it in 'git cherry-pick'?
>
> I think the primary reason behind the "Why are you picking a no-op?
> Let me stop to make sure you didn't make a mistake." is because
> cherry-pick and revert have long been operations for a single commit
> explicitly given by the user, not bunch of commits in a range.
Yeah, but this has changed already.
Show 9 quoted lines
> These two operating modes are conceptually very different, even when
> we consider scripted use.  A script that feeds one commit at a time
> has a chance to do patch equivalence or user-interactive filtering
> on its own, and would be helped by the "are you sure you meant to
> record that no-op?" check if it filtered in a wrong way (e.g. the
> user specified an empty commit by mistake).  One that feeds a range,
> on the other hand, relies on or at least expects cherry-pick to have
> such smart, and a smarter cherry-pick could select what to pick from
> the given range.

How would a script know that a single pick ends up as a no-op? It can't know what is the reason the cherry-pick failed. The only way to know for sure is to check the last commit, and for that we don't need the last cherry-pick to fail.

Show 15 quoted lines
> In the longer term, especially if we envision to move large part of
> logic to prepare the sequencer insn list from rebase to cherry-pick,
> a ranged cherry-pick should learn a way to filter the range with
> patch equivalence, for example.  Once that happens, the behaviour
> would become inconsistent at the end-user level if we stopped at a
> commit only because it was not exactly patch equivalent to another
> one that is already on the branch we are cherry-picking to, but
> ended up to be a no-op, while we did not stop at another commit
> because patch equivalence filtered it out beforehand to skip it.
> Skipping a no-op by default would remove that inconsistency.
>
> So in that sense, one could argue that it may be a bugfix to skip
> commits that become no-op when replayed, when picking a range of
> commits (but not a single one).  And I do not think you would need
> to wait until 2.0 for such a change.

Right. But first we need to agree that failing an empty cherry-pick serves no purpose.

-- 
Felipe Contreras
Antoine Pelisse· Jun 4, 2013, 06:31 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Mon, Jun 3, 2013 at 11:10 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 29 quoted lines
> On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Pretty much what it says on the tin.
>>>
>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>> ---
>>>  Documentation/git-cherry-pick.txt   |  3 +++
>>>  builtin/revert.c                    |  2 ++
>>>  sequencer.c                         |  6 ++++++
>>>  sequencer.h                         |  1 +
>>>  t/t3508-cherry-pick-many-commits.sh | 13 +++++++++++++
>>>  5 files changed, 25 insertions(+)
>>>
>>> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
>>> index c205d23..fccd936 100644
>>> --- a/Documentation/git-cherry-pick.txt
>>> +++ b/Documentation/git-cherry-pick.txt
>>> @@ -129,6 +129,9 @@ effect to your index in a row.
>>>       redundant commits are ignored.  This option overrides that behavior and
>>>       creates an empty commit object.  Implies `--allow-empty`.
>>>
>>> +--skip-empty::
>>> +     Instead of failing, skip commits that are or become empty.
>>
>> Not quite sure.  Is this "instead of recording an empty commit,"
>> (which may or may not fail depending on the allow-empty settings)?
>
> We are explaining --skip-empty, not --allow-empty.

By the way, I guess both options are incompatible ? I think it would be nice to fail if both are specified.

Antoine,
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 4/8] cherry-pick: store rewritten commits

Will be useful for the next commits.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 sequencer.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 sequencer.h |  1 +
 2 files changed, 95 insertions(+), 1 deletion(-)
Show changes to 2 files +95 −1

sequencer.c, sequencer.h

diff --git a/sequencer.c b/sequencer.c
index d3c7d72..c217716 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -20,6 +20,18 @@
 const char sign_off_header[] = "Signed-off-by: ";
 static const char cherry_picked_prefix[] = "(cherry picked from commit ";
 
+struct rewritten_list_item {
+	unsigned char from[20];
+	unsigned char to[20];
+};
+
+struct rewritten_list {
+	struct rewritten_list_item *items;
+	unsigned int nr, alloc;
+};
+
+static struct rewritten_list rewritten;
+
 static int is_rfc2822_line(const char *buf, int len)
 {
 	int i;
@@ -102,6 +114,19 @@ static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
 	return 1;
 }
 
+static void add_rewritten(unsigned char *from, unsigned char *to)
+{
+	struct rewritten_list_item *item;
+	if (rewritten.nr + 1 >= rewritten.alloc) {
+		rewritten.alloc += 32;
+		rewritten.items = xrealloc(rewritten.items, rewritten.alloc * sizeof(*rewritten.items));
+	}
+	item = &rewritten.items[rewritten.nr];
+	hashcpy(item->from, from);
+	hashcpy(item->to, to);
+	rewritten.nr++;
+}
+
 static void remove_sequencer_state(void)
 {
 	struct strbuf seq_dir = STRBUF_INIT;
@@ -641,6 +666,14 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 	if (!opts->no_commit)
 		res = run_git_commit(defmsg, opts, allow);
 
+	if (!res) {
+		unsigned char to[20];
+
+		if (read_ref("HEAD", to))
+			goto leave;
+
+		add_rewritten(commit->object.sha1, to);
+	}
 leave:
 	free_message(&msg);
 	free(defmsg);
@@ -786,6 +819,40 @@ static void read_populate_todo(struct commit_list **todo_list,
 		die(_("Unusable instruction sheet: %s"), todo_file);
 }
 
+static void read_populate_rewritten(void)
+{
+	const char *rewritten_file = git_path(SEQ_REWR_FILE);
+	struct strbuf buf = STRBUF_INIT;
+	char *p;
+	int fd;
+
+	fd = open(rewritten_file, O_RDONLY);
+	if (fd < 0)
+		return;
+	if (strbuf_read(&buf, fd, 0) < 0) {
+		close(fd);
+		strbuf_release(&buf);
+		return;
+	}
+	close(fd);
+
+	for (p = buf.buf; *p;) {
+		unsigned char from[20];
+		unsigned char to[20];
+		char *eol = strchrnul(p, '\n');
+		if (eol - p != 81)
+			/* wrong size */
+			break;
+		if (get_sha1_hex(p, from))
+			break;
+		if (get_sha1_hex(p + 41, to))
+			break;
+		add_rewritten(from, to);
+		p = *eol ? eol + 1 : eol;
+	}
+	strbuf_release(&buf);
+}
+
 static int populate_opts_cb(const char *key, const char *value, void *data)
 {
 	struct replay_opts *opts = data;
@@ -958,6 +1025,29 @@ static void save_todo(struct commit_list *todo_list, struct replay_opts *opts)
 	strbuf_release(&buf);
 }
 
+static void save_rewritten(void)
+{
+	const char *todo_file = git_path(SEQ_REWR_FILE);
+	static struct lock_file rewritten_lock;
+	struct strbuf buf = STRBUF_INIT;
+	int fd, i;
+
+	fd = hold_lock_file_for_update(&rewritten_lock, todo_file, LOCK_DIE_ON_ERROR);
+	for (i = 0; i < rewritten.nr; i++) {
+		struct rewritten_list_item *item = &rewritten.items[i];
+		strbuf_addf(&buf, "%s %s\n", sha1_to_hex(item->from), sha1_to_hex(item->to));
+	}
+	if (write_in_full(fd, buf.buf, buf.len) < 0) {
+		strbuf_release(&buf);
+		die_errno(_("Could not write to %s"), todo_file);
+	}
+	if (commit_lock_file(&rewritten_lock) < 0) {
+		strbuf_release(&buf);
+		die(_("Error wrapping up %s."), todo_file);
+	}
+	strbuf_release(&buf);
+}
+
 static void save_opts(struct replay_opts *opts)
 {
 	const char *opts_file = git_path(SEQ_OPTS_FILE);
@@ -1003,8 +1093,10 @@ static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
 	for (cur = todo_list; cur; cur = cur->next) {
 		save_todo(cur, opts);
 		res = do_pick_commit(cur->item, opts);
-		if (res)
+		if (res) {
+			save_rewritten();
 			return res;
+		}
 	}
 
 	/*
@@ -1033,6 +1125,7 @@ static int sequencer_continue(struct replay_opts *opts)
 		return continue_single_pick();
 	read_populate_opts(&opts);
 	read_populate_todo(&todo_list, opts);
+	read_populate_rewritten();
 
 	/* Verify that the conflict has been resolved */
 	if (file_exists(git_path("CHERRY_PICK_HEAD")) ||
diff --git a/sequencer.h b/sequencer.h
index 3b04844..84b9957 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -5,6 +5,7 @@
 #define SEQ_HEAD_FILE	"sequencer/head"
 #define SEQ_TODO_FILE	"sequencer/todo"
 #define SEQ_OPTS_FILE	"sequencer/opts"
+#define SEQ_REWR_FILE	"sequencer/rewritten"
 
 #define APPEND_SIGNOFF_DEDUP (1u << 0)
 
-- 
1.8.3.rc3.312.g47657de
Junio C Hamano· Jun 3, 2013, 18:49 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 4/8] cherry-pick: store rewritten commits

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 7 quoted lines
> +static void add_rewritten(unsigned char *from, unsigned char *to)
> +{
> +	struct rewritten_list_item *item;
> +	if (rewritten.nr + 1 >= rewritten.alloc) {
> +		rewritten.alloc += 32;
> +		rewritten.items = xrealloc(rewritten.items, rewritten.alloc * sizeof(*rewritten.items));
> +	}
Is there a compelling reason not to use ALLOC_GROW() here?
Felipe Contreras· Jun 3, 2013, 20:55 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 4/8] cherry-pick: store rewritten commits

On Mon, Jun 3, 2013 at 1:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> +static void add_rewritten(unsigned char *from, unsigned char *to)
>> +{
>> +     struct rewritten_list_item *item;
>> +     if (rewritten.nr + 1 >= rewritten.alloc) {
>> +             rewritten.alloc += 32;
>> +             rewritten.items = xrealloc(rewritten.items, rewritten.alloc * sizeof(*rewritten.items));
>> +     }
>
> Is there a compelling reason not to use ALLOC_GROW() here?
Nope, I just copied the logic from another part of Git.
-- 
Felipe Contreras
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 5/8] sequencer: run post-rewrite hook

As we should.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 sequencer.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 44 insertions(+), 1 deletion(-)
Show changes to sequencer.c +44 −1
diff --git a/sequencer.c b/sequencer.c
index c217716..3aa480e 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -127,6 +127,37 @@ static void add_rewritten(unsigned char *from, unsigned char *to)
 	rewritten.nr++;
 }
 
+static void run_rewrite_hook(void)
+{
+	struct strbuf buf = STRBUF_INIT;
+	struct child_process proc;
+	const char *argv[3];
+	int code, i;
+
+	argv[0] = find_hook("post-rewrite");
+	if (!argv[0])
+		return;
+
+	argv[1] = "rebase";
+	argv[2] = NULL;
+
+	memset(&proc, 0, sizeof(proc));
+	proc.argv = argv;
+	proc.in = -1;
+	proc.stdout_to_stderr = 1;
+
+	code = start_command(&proc);
+	if (code)
+		return;
+	for (i = 0; i < rewritten.nr; i++) {
+		struct rewritten_list_item *item = &rewritten.items[i];
+		strbuf_addf(&buf, "%s %s\n", sha1_to_hex(item->from), sha1_to_hex(item->to));
+	}
+	write_in_full(proc.in, buf.buf, buf.len);
+	close(proc.in);
+	finish_command(&proc);
+}
+
 static void remove_sequencer_state(void)
 {
 	struct strbuf seq_dir = STRBUF_INIT;
@@ -1099,6 +1130,8 @@ static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
 		}
 	}
 
+	run_rewrite_hook();
+
 	/*
 	 * Sequence of picks finished successfully; cleanup by
 	 * removing the .git/sequencer directory
@@ -1136,14 +1169,24 @@ static int sequencer_continue(struct replay_opts *opts)
 	}
 	if (index_differs_from("HEAD", 0))
 		return error_dirty_index(opts);
+	{
+		unsigned char to[20];
+		if (!read_ref("HEAD", to))
+			add_rewritten(todo_list->item->object.sha1, to);
+	}
 	todo_list = todo_list->next;
 	return pick_commits(todo_list, opts);
 }
 
 static int single_pick(struct commit *cmit, struct replay_opts *opts)
 {
+	int ret;
 	setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
-	return do_pick_commit(cmit, opts);
+	ret = do_pick_commit(cmit, opts);
+	if (ret)
+		return ret;
+	run_rewrite_hook();
+	return 0;
 }
 
 int sequencer_pick_revisions(struct replay_opts *opts)
-- 
1.8.3.rc3.312.g47657de
Junio C Hamano· Jun 3, 2013, 18:57 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 5/8] sequencer: run post-rewrite hook

Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 28 quoted lines
> As we should.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  sequencer.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index c217716..3aa480e 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -127,6 +127,37 @@ static void add_rewritten(unsigned char *from, unsigned char *to)
>  	rewritten.nr++;
>  }
>  
> +static void run_rewrite_hook(void)
> +{
> +	struct strbuf buf = STRBUF_INIT;
> +	struct child_process proc;
> +	const char *argv[3];
> +	int code, i;
> +
> +	argv[0] = find_hook("post-rewrite");
> +	if (!argv[0])
> +		return;
> +
> +	argv[1] = "rebase";
> +	argv[2] = NULL;

When the end-user action is "git cherry-pick A..B", shouldn't the rewrite hook be called with "cherry-pick" not "rebase" as its first argument?

More importantly, doesn't "git revert A..B" also trigger the codepath for [4/8] and hence this function?

I think [3/8] --skip-empty makes sense also for revert, but I do not think this one does as-is. As what [4/8] introduces is a record of "rewrite", the patch does not make sense either. These two steps would want to limit themselves to cherry-pick only, no?

Show 55 quoted lines
> +	memset(&proc, 0, sizeof(proc));
> +	proc.argv = argv;
> +	proc.in = -1;
> +	proc.stdout_to_stderr = 1;
> +
> +	code = start_command(&proc);
> +	if (code)
> +		return;
> +	for (i = 0; i < rewritten.nr; i++) {
> +		struct rewritten_list_item *item = &rewritten.items[i];
> +		strbuf_addf(&buf, "%s %s\n", sha1_to_hex(item->from), sha1_to_hex(item->to));
> +	}
> +	write_in_full(proc.in, buf.buf, buf.len);
> +	close(proc.in);
> +	finish_command(&proc);
> +}
> +
>  static void remove_sequencer_state(void)
>  {
>  	struct strbuf seq_dir = STRBUF_INIT;
> @@ -1099,6 +1130,8 @@ static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
>  		}
>  	}
>  
> +	run_rewrite_hook();
> +
>  	/*
>  	 * Sequence of picks finished successfully; cleanup by
>  	 * removing the .git/sequencer directory
> @@ -1136,14 +1169,24 @@ static int sequencer_continue(struct replay_opts *opts)
>  	}
>  	if (index_differs_from("HEAD", 0))
>  		return error_dirty_index(opts);
> +	{
> +		unsigned char to[20];
> +		if (!read_ref("HEAD", to))
> +			add_rewritten(todo_list->item->object.sha1, to);
> +	}
>  	todo_list = todo_list->next;
>  	return pick_commits(todo_list, opts);
>  }
>  
>  static int single_pick(struct commit *cmit, struct replay_opts *opts)
>  {
> +	int ret;
>  	setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
> -	return do_pick_commit(cmit, opts);
> +	ret = do_pick_commit(cmit, opts);
> +	if (ret)
> +		return ret;
> +	run_rewrite_hook();
> +	return 0;
>  }
>  
>  int sequencer_pick_revisions(struct replay_opts *opts)
Felipe Contreras· Jun 3, 2013, 21:01 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 5/8] sequencer: run post-rewrite hook

On Mon, Jun 3, 2013 at 1:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 34 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> As we should.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>  sequencer.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/sequencer.c b/sequencer.c
>> index c217716..3aa480e 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -127,6 +127,37 @@ static void add_rewritten(unsigned char *from, unsigned char *to)
>>       rewritten.nr++;
>>  }
>>
>> +static void run_rewrite_hook(void)
>> +{
>> +     struct strbuf buf = STRBUF_INIT;
>> +     struct child_process proc;
>> +     const char *argv[3];
>> +     int code, i;
>> +
>> +     argv[0] = find_hook("post-rewrite");
>> +     if (!argv[0])
>> +             return;
>> +
>> +     argv[1] = "rebase";
>> +     argv[2] = NULL;
>
> When the end-user action is "git cherry-pick A..B", shouldn't
> the rewrite hook be called with "cherry-pick" not "rebase" as its
> first argument?
Indeed.
> More importantly, doesn't "git revert A..B" also trigger the
> codepath for [4/8] and hence this function?
True.
> I think [3/8] --skip-empty makes sense also for revert, but I do not
> think this one does as-is.  As what [4/8] introduces is a record of
> "rewrite", the patch does not make sense either.  These two steps
> would want to limit themselves to cherry-pick only, no?
Probably.
-- 
Felipe Contreras
Thomas Rast· Jun 4, 2013, 09:03 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 5/8] sequencer: run post-rewrite hook

Junio C Hamano <gitster@pobox.com> writes:
Show 19 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> +static void run_rewrite_hook(void)
>> +{
>> +	struct strbuf buf = STRBUF_INIT;
>> +	struct child_process proc;
>> +	const char *argv[3];
>> +	int code, i;
>> +
>> +	argv[0] = find_hook("post-rewrite");
>> +	if (!argv[0])
>> +		return;
>> +
>> +	argv[1] = "rebase";
>> +	argv[2] = NULL;
>
> When the end-user action is "git cherry-pick A..B", shouldn't
> the rewrite hook be called with "cherry-pick" not "rebase" as its
> first argument?

The whole function was copied from builtin/commit.c except for that string. So it should be refactored anyway, with the "cherry-pick" being an argument.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 6/8] cherry-pick: add support to copy notes

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/revert.c  |  2 ++
 sequencer.c       | 33 ++++++++++++++++++++++++++++++++-
 sequencer.h       |  1 +
 t/t3500-cherry.sh | 32 ++++++++++++++++++++++++++++++++
 4 files changed, 67 insertions(+), 1 deletion(-)
Show changes to 4 files +67 −1

builtin/revert.c, sequencer.c, sequencer.h, t/t3500-cherry.sh

diff --git a/builtin/revert.c b/builtin/revert.c
index 0e5ce71..b977124 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -119,6 +119,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 		OPT_END(),
 		OPT_END(),
 		OPT_END(),
+		OPT_END(),
 	};
 
 	if (opts->action == REPLAY_PICK) {
@@ -129,6 +130,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 			OPT_BOOLEAN(0, "allow-empty-message", &opts->allow_empty_message, N_("allow commits with empty messages")),
 			OPT_BOOLEAN(0, "keep-redundant-commits", &opts->keep_redundant_commits, N_("keep redundant, empty commits")),
 			OPT_BOOLEAN(0, "skip-empty", &opts->skip_empty, N_("skip empty commits")),
+			OPT_BOOLEAN(0, "copy-notes", &opts->copy_notes, N_("copy notes")),
 			OPT_END(),
 		};
 		if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra))
diff --git a/sequencer.c b/sequencer.c
index 3aa480e..cc9c2bc 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -127,6 +127,27 @@ static void add_rewritten(unsigned char *from, unsigned char *to)
 	rewritten.nr++;
 }
 
+static void copy_notes(void)
+{
+	unsigned char note_commit[20];
+	struct strbuf buf = STRBUF_INIT;
+	struct notes_tree *t = &default_notes_tree;
+	int i;
+
+	init_notes(t, NULL, NULL, 0);
+
+	for (i = 0; i < rewritten.nr; i++) {
+		struct rewritten_list_item *item = &rewritten.items[i];
+		copy_note(t, item->from, item->to, 0, NULL);
+	}
+
+	strbuf_addstr(&buf, "Notes added by 'git cherry-pick'\n");
+	create_notes_commit(&default_notes_tree, NULL, &buf, note_commit);
+	strbuf_insert(&buf, 0, "notes: ", 7);
+	update_ref(buf.buf, t->ref, note_commit, NULL, 0, MSG_ON_ERR);
+	strbuf_release(&buf);
+}
+
 static void run_rewrite_hook(void)
 {
 	struct strbuf buf = STRBUF_INIT;
@@ -908,7 +929,10 @@ static int populate_opts_cb(const char *key, const char *value, void *data)
 	else if (!strcmp(key, "options.strategy-option")) {
 		ALLOC_GROW(opts->xopts, opts->xopts_nr + 1, opts->xopts_alloc);
 		opts->xopts[opts->xopts_nr++] = xstrdup(value);
-	} else
+	}
+	else if (!strcmp(key, "options.copy-notes"))
+		opts->copy_notes = git_config_bool_or_int(key, value, &error_flag);
+	else
 		return error(_("Invalid key: %s"), key);
 
 	if (!error_flag)
@@ -1108,6 +1132,8 @@ static void save_opts(struct replay_opts *opts)
 							"options.strategy-option",
 							opts->xopts[i], "^$", 0);
 	}
+	if (opts->copy_notes)
+		git_config_set_in_file(opts_file, "options.copy-notes", "true");
 }
 
 static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
@@ -1132,6 +1158,9 @@ static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
 
 	run_rewrite_hook();
 
+	if (opts->copy_notes)
+		copy_notes();
+
 	/*
 	 * Sequence of picks finished successfully; cleanup by
 	 * removing the .git/sequencer directory
@@ -1186,6 +1215,8 @@ static int single_pick(struct commit *cmit, struct replay_opts *opts)
 	if (ret)
 		return ret;
 	run_rewrite_hook();
+	if (opts->copy_notes)
+		copy_notes();
 	return 0;
 }
 
diff --git a/sequencer.h b/sequencer.h
index 84b9957..6cc072c 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -36,6 +36,7 @@ struct replay_opts {
 	int allow_empty_message;
 	int keep_redundant_commits;
 	int skip_empty;
+	int copy_notes;
 
 	int mainline;
 
diff --git a/t/t3500-cherry.sh b/t/t3500-cherry.sh
index f038f34..79c1219 100755
--- a/t/t3500-cherry.sh
+++ b/t/t3500-cherry.sh
@@ -55,4 +55,36 @@ test_expect_success \
      expr "$(echo $(git cherry master my-topic-branch) )" : "+ [^ ]* - .*"
 '
 
+test_expect_success \
+    'copy notes' \
+    'git checkout master &&
+    echo notes > C &&
+    test_tick &&
+    git commit -a -m "Update C" &&
+    git notes add -m "a note" &&
+    git checkout -b note-test HEAD^ &&
+    git cherry-pick --copy-notes -x master &&
+    test "a note" = "$(git notes show HEAD)"
+'
+
+test_expect_success \
+    'copy multiple notes' \
+    'git checkout master &&
+    echo "multiple notes" > C &&
+    git commit -a -m "Update C again" &&
+    git notes add -m "another note" &&
+    git commit -a -m "Empty" --allow-empty &&
+    echo "more notes" > C &&
+    git commit -a -m "Update C once more" &&
+    git notes add -m "final note" &&
+    git checkout note-test &&
+    git reset --hard master~3 &&
+    test_expect_code 1 git cherry-pick --copy-notes -x HEAD..master &&
+    git reset --hard &&
+    git cherry-pick --continue
+    test "a note" = "$(git notes show HEAD~2)" &&
+    test "another note" = "$(git notes show HEAD~1)" &&
+    test "final note" = "$(git notes show HEAD)"
+'
+
 test_done
-- 
1.8.3.rc3.312.g47657de
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 7/8] revert/cherry-pick: add --quiet option

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/git-cherry-pick.txt | 6 +++++-
 Documentation/git-revert.txt      | 6 +++++-
 builtin/revert.c                  | 1 +
 sequencer.c                       | 9 ++++++---
 sequencer.h                       | 1 +
 5 files changed, 18 insertions(+), 5 deletions(-)
Show changes to 5 files +18 −5

Documentation/git-cherry-pick.txt, Documentation/git-revert.txt, builtin/revert.c, sequencer.c, sequencer.h

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index fccd936..da0bd81 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -8,7 +8,7 @@ git-cherry-pick - Apply the changes introduced by some existing commits
 SYNOPSIS
 --------
 [verse]
-'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
+'git cherry-pick' [-q] [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
 'git cherry-pick' --continue
 'git cherry-pick' --quit
 'git cherry-pick' --abort
@@ -51,6 +51,10 @@ OPTIONS
 	feed all <commit>... arguments to a single revision walk
 	(see a later example that uses 'maint master..next').
 
+-q::
+--quiet::
+	Quiet, suppress feedback messages.
+
 -e::
 --edit::
 	With this option, 'git cherry-pick' will let you edit the commit
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index f79c9d8..98a8e7a 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -8,7 +8,7 @@ git-revert - Revert some existing commits
 SYNOPSIS
 --------
 [verse]
-'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] <commit>...
+'git revert' [-q] [--[no-]edit] [-n] [-m parent-number] [-s] <commit>...
 'git revert' --continue
 'git revert' --quit
 'git revert' --abort
@@ -40,6 +40,10 @@ OPTIONS
 	default, see linkgit:git-rev-list[1] and its '--no-walk'
 	option.
 
+-q::
+--quiet::
+	Quiet, suppress feedback messages.
+
 -e::
 --edit::
 	With this option, 'git revert' will let you edit the commit
diff --git a/builtin/revert.c b/builtin/revert.c
index b977124..d63b4a6 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -100,6 +100,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 	int contin = 0;
 	int rollback = 0;
 	struct option options[] = {
+		OPT__QUIET(&opts->quiet, N_("suppress progress reporting")),
 		OPT_BOOLEAN(0, "quit", &remove_state, N_("end revert or cherry-pick sequence")),
 		OPT_BOOLEAN(0, "continue", &contin, N_("resume revert or cherry-pick sequence")),
 		OPT_BOOLEAN(0, "abort", &rollback, N_("cancel revert or cherry-pick sequence")),
diff --git a/sequencer.c b/sequencer.c
index cc9c2bc..b7391d6 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -466,6 +466,8 @@ static int run_git_commit(const char *defmsg, struct replay_opts *opts,
 	argv_array_init(&array);
 	argv_array_push(&array, "commit");
 	argv_array_push(&array, "-n");
+	if (opts->quiet)
+		argv_array_push(&array, "-q");
 
 	if (opts->signoff)
 		argv_array_push(&array, "-s");
@@ -705,9 +707,10 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
 	}
 
 	if (opts->skip_empty && is_index_unchanged() == 1) {
-		warning(_("skipping %s... %s"),
-			find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
-			msg.subject);
+		if (!opts->quiet)
+			warning(_("skipping %s... %s"),
+				find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
+				msg.subject);
 		goto leave;
 	}
 	allow = allow_empty(opts, commit);
diff --git a/sequencer.h b/sequencer.h
index 6cc072c..41e19d0 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -37,6 +37,7 @@ struct replay_opts {
 	int keep_redundant_commits;
 	int skip_empty;
 	int copy_notes;
+	int quiet;
 
 	int mainline;
 
-- 
1.8.3.rc3.312.g47657de
Ramkumar Ramachandra· May 29, 2013, 12:33 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 7/8] revert/cherry-pick: add --quiet option

Felipe Contreras wrote:
Show 10 quoted lines
>         if (opts->skip_empty && is_index_unchanged() == 1) {
> -               warning(_("skipping %s... %s"),
> -                       find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
> -                       msg.subject);
> +               if (!opts->quiet)
> +                       warning(_("skipping %s... %s"),
> +                               find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
> +                               msg.subject);
>                 goto leave;
>         }

All this trouble just to suppress the "skipping ..." message. Do you see anything else --quiet can be used to suppress?

Felipe Contreras· May 29, 2013, 13:28 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH v2 7/8] revert/cherry-pick: add --quiet option

On Wed, May 29, 2013 at 7:33 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 14 quoted lines
> Felipe Contreras wrote:
>>         if (opts->skip_empty && is_index_unchanged() == 1) {
>> -               warning(_("skipping %s... %s"),
>> -                       find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
>> -                       msg.subject);
>> +               if (!opts->quiet)
>> +                       warning(_("skipping %s... %s"),
>> +                               find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV),
>> +                               msg.subject);
>>                 goto leave;
>>         }
>
> All this trouble just to suppress the "skipping ..." message.  Do you
> see anything else --quiet can be used to suppress?
Did you miss the -q option passed to 'git commit'?
-- 
Felipe Contreras
Ramkumar Ramachandra· May 29, 2013, 13:32 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 7/8] revert/cherry-pick: add --quiet option

Felipe Contreras wrote:
> Did you miss the -q option passed to 'git commit'?
Ah, yes.
It would help if you mentioned:
    Introduce --quiet to suppress warning about skipped commits (when
using --skip-empty) and output from 'git commit'.
in the commit message.
Thanks.
Felipe Contreras· May 29, 2013, 13:40 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH v2 7/8] revert/cherry-pick: add --quiet option

On Wed, May 29, 2013 at 8:32 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 9 quoted lines
> Felipe Contreras wrote:
>> Did you miss the -q option passed to 'git commit'?
>
> Ah, yes.
>
> It would help if you mentioned:
>
>     Introduce --quiet to suppress warning about skipped commits (when
> using --skip-empty) and output from 'git commit'.

I would switch them around, as the former is not important, in fact, it's so unimportant that I wouldn't even mention it.

And in fact, it wasn't even there when I wrote this commit message I sent for v1, it was only squashed later on.

The only really important thing this patch does is 'commit -q', and I cannot imagine what the purpose of a -q option to cherry-pick would be if it's not that. But yeah, it wouldn't hurt.

-- 
Felipe Contreras
Felipe Contreras· May 29, 2013, 03:56 UTC · re: Felipe Contreras · lore

[PATCH v2 8/8] revert/cherry-pick: add --skip option

Akin to 'am --skip' and 'rebase --skip'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/git-cherry-pick.txt |  1 +
 Documentation/git-revert.txt      |  1 +
 Documentation/sequencer.txt       |  3 +++
 builtin/revert.c                  |  6 ++++++
 sequencer.c                       | 32 +++++++++++++++++++++++++++++---
 sequencer.h                       |  3 ++-
 t/t3510-cherry-pick-sequence.sh   | 12 ++++++++++++
 7 files changed, 54 insertions(+), 4 deletions(-)
Show changes to 7 files +54 −4

Documentation/git-cherry-pick.txt, Documentation/git-revert.txt, Documentation/sequencer.txt, builtin/revert.c, sequencer.c, sequencer.h, t/t3510-cherry-pick-sequence.sh

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index da0bd81..d95c63c 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -10,6 +10,7 @@ SYNOPSIS
 [verse]
 'git cherry-pick' [-q] [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
 'git cherry-pick' --continue
+'git cherry-pick' --skip
 'git cherry-pick' --quit
 'git cherry-pick' --abort
 
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 98a8e7a..52e146e 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -10,6 +10,7 @@ SYNOPSIS
 [verse]
 'git revert' [-q] [--[no-]edit] [-n] [-m parent-number] [-s] <commit>...
 'git revert' --continue
+'git revert' --skip
 'git revert' --quit
 'git revert' --abort
 
diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt
index 5747f44..df2d355 100644
--- a/Documentation/sequencer.txt
+++ b/Documentation/sequencer.txt
@@ -3,6 +3,9 @@
 	'.git/sequencer'.  Can be used to continue after resolving
 	conflicts in a failed cherry-pick or revert.
 
+--skip::
+	Skip the current commit, and then continue.
+
 --quit::
 	Forget about the current operation in progress.  Can be used
 	to clear the sequencer state after a failed cherry-pick or
diff --git a/builtin/revert.c b/builtin/revert.c
index d63b4a6..6afd990 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -99,11 +99,13 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 	int remove_state = 0;
 	int contin = 0;
 	int rollback = 0;
+	int skip = 0;
 	struct option options[] = {
 		OPT__QUIET(&opts->quiet, N_("suppress progress reporting")),
 		OPT_BOOLEAN(0, "quit", &remove_state, N_("end revert or cherry-pick sequence")),
 		OPT_BOOLEAN(0, "continue", &contin, N_("resume revert or cherry-pick sequence")),
 		OPT_BOOLEAN(0, "abort", &rollback, N_("cancel revert or cherry-pick sequence")),
+		OPT_BOOLEAN(0, "skip", &skip, N_("skip current commit in the sequence")),
 		OPT_BOOLEAN('n', "no-commit", &opts->no_commit, N_("don't automatically commit")),
 		OPT_BOOLEAN('e', "edit", &opts->edit, N_("edit the commit message")),
 		OPT_NOOP_NOARG('r', NULL),
@@ -160,6 +162,8 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 		opts->subcommand = REPLAY_CONTINUE;
 	else if (rollback)
 		opts->subcommand = REPLAY_ROLLBACK;
+	else if (skip)
+		opts->subcommand = REPLAY_SKIP;
 	else
 		opts->subcommand = REPLAY_NONE;
 
@@ -170,6 +174,8 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
 			this_operation = "--quit";
 		else if (opts->subcommand == REPLAY_CONTINUE)
 			this_operation = "--continue";
+		else if (opts->subcommand == REPLAY_SKIP)
+			this_operation = "--skip";
 		else {
 			assert(opts->subcommand == REPLAY_ROLLBACK);
 			this_operation = "--abort";
diff --git a/sequencer.c b/sequencer.c
index b7391d6..46bbe29 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1182,7 +1182,9 @@ static int continue_single_pick(void)
 	return run_command_v_opt(argv, RUN_GIT_CMD);
 }
 
-static int sequencer_continue(struct replay_opts *opts)
+static void add_rewritten(unsigned char *from, unsigned char *to);
+
+static int sequencer_continue(struct replay_opts *opts, int skip)
 {
 	struct commit_list *todo_list = NULL;
 
@@ -1201,7 +1203,7 @@ static int sequencer_continue(struct replay_opts *opts)
 	}
 	if (index_differs_from("HEAD", 0))
 		return error_dirty_index(opts);
-	{
+	if (!skip) {
 		unsigned char to[20];
 		if (!read_ref("HEAD", to))
 			add_rewritten(todo_list->item->object.sha1, to);
@@ -1210,6 +1212,28 @@ static int sequencer_continue(struct replay_opts *opts)
 	return pick_commits(todo_list, opts);
 }
 
+static int sequencer_skip(struct replay_opts *opts)
+{
+	const char *argv[4]; /* reset --hard HEAD + NULL */
+	struct string_list merge_rr = STRING_LIST_INIT_DUP;
+	int ret;
+
+	if (setup_rerere(&merge_rr, 0) >= 0) {
+		rerere_clear(&merge_rr);
+		string_list_clear(&merge_rr, 1);
+	}
+
+	argv[0] = "reset";
+	argv[1] = "--hard";
+	argv[2] = "HEAD";
+	argv[3] = NULL;
+	ret = run_command_v_opt(argv, RUN_GIT_CMD);
+	if (ret)
+		return ret;
+
+	return sequencer_continue(opts, 1);
+}
+
 static int single_pick(struct commit *cmit, struct replay_opts *opts)
 {
 	int ret;
@@ -1246,7 +1270,9 @@ int sequencer_pick_revisions(struct replay_opts *opts)
 	if (opts->subcommand == REPLAY_ROLLBACK)
 		return sequencer_rollback(opts);
 	if (opts->subcommand == REPLAY_CONTINUE)
-		return sequencer_continue(opts);
+		return sequencer_continue(opts, 0);
+	if (opts->subcommand == REPLAY_SKIP)
+		return sequencer_skip(opts);
 
 	for (i = 0; i < opts->revs->pending.nr; i++) {
 		unsigned char sha1[20];
diff --git a/sequencer.h b/sequencer.h
index 41e19d0..b9e09ac 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -18,7 +18,8 @@ enum replay_subcommand {
 	REPLAY_NONE,
 	REPLAY_REMOVE_STATE,
 	REPLAY_CONTINUE,
-	REPLAY_ROLLBACK
+	REPLAY_ROLLBACK,
+	REPLAY_SKIP
 };
 
 struct replay_opts {
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index 7b7a89d..f58a83d 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick-sequence.sh
@@ -511,4 +511,16 @@ test_expect_success 'commit descriptions in insn sheet are optional' '
 	test_line_count = 4 commits
 '
 
+test_expect_success 'skip' '
+	pristine_detach conflicting &&
+	test_must_fail git cherry-pick initial..picked &&
+
+	git checkout HEAD -- unrelated &&
+	test_must_fail git cherry-pick --continue &&
+	git cherry-pick --skip &&
+
+	git rev-list initial..HEAD >commits &&
+	test_line_count = 3 commits
+'
+
 test_done
-- 
1.8.3.rc3.312.g47657de
Ramkumar Ramachandra· May 29, 2013, 12:27 UTC · re: Felipe Contreras · lore

Re: [PATCH v2 8/8] revert/cherry-pick: add --skip option

Felipe Contreras wrote:
> Akin to 'am --skip' and 'rebase --skip'.

This ranged-cherry-pick can be useful for small ranges. As pointed out by others on the list, it hemorrhages memory quite horribly (and this problem is non-trivial to fix). Perhaps we should document this in limitations or bugs if we intend to make it more useful?

Show 9 quoted lines
> diff --git a/builtin/revert.c b/builtin/revert.c
> index d63b4a6..6afd990 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -99,11 +99,13 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
>         int remove_state = 0;
>         int contin = 0;
>         int rollback = 0;
> +       int skip = 0;

Ugh, one more integer. Can't we use an OPT_BIT and store the action in one variable? No hurry ofcourse: just asking.

Show 9 quoted lines
> @@ -1201,7 +1203,7 @@ static int sequencer_continue(struct replay_opts *opts)
>         }
>         if (index_differs_from("HEAD", 0))
>                 return error_dirty_index(opts);
> -       {
> +       if (!skip) {
>                 unsigned char to[20];
>                 if (!read_ref("HEAD", to))
>                         add_rewritten(todo_list->item->object.sha1, to);
Couldn't you just say if (skip) todo_list = todo_list -> next?
> +       if (setup_rerere(&merge_rr, 0) >= 0) {
> +               rerere_clear(&merge_rr);
> +               string_list_clear(&merge_rr, 1);
> +       }
Why exactly?  Why doesn't rebase --skip 'rerere clear'?
Show 5 quoted lines
> +       argv[0] = "reset";
> +       argv[1] = "--hard";
> +       argv[2] = "HEAD";
> +       argv[3] = NULL;
> +       ret = run_command_v_opt(argv, RUN_GIT_CMD);

Unrelated to your patch, but any clue why reset doesn't have an api yet? Does it leak memory too?

Felipe Contreras· May 29, 2013, 13:27 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH v2 8/8] revert/cherry-pick: add --skip option

On Wed, May 29, 2013 at 7:27 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 7 quoted lines
> Felipe Contreras wrote:
>> Akin to 'am --skip' and 'rebase --skip'.
>
> This ranged-cherry-pick can be useful for small ranges.  As pointed
> out by others on the list, it hemorrhages memory quite horribly (and
> this problem is non-trivial to fix).  Perhaps we should document this
> in limitations or bugs if we intend to make it more useful?
Is there a test-case that triggers this?
I don't see why we shouldn't try to fix this.
Show 12 quoted lines
>> diff --git a/builtin/revert.c b/builtin/revert.c
>> index d63b4a6..6afd990 100644
>> --- a/builtin/revert.c
>> +++ b/builtin/revert.c
>> @@ -99,11 +99,13 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
>>         int remove_state = 0;
>>         int contin = 0;
>>         int rollback = 0;
>> +       int skip = 0;
>
> Ugh, one more integer.  Can't we use an OPT_BIT and store the action
> in one variable? No hurry ofcourse: just asking.

I thought of switching to bit fields, but then I opened builtin/checkout.c to see how many options were implemented, and I saw more ints, so I left it like that.

Show 11 quoted lines
>> @@ -1201,7 +1203,7 @@ static int sequencer_continue(struct replay_opts *opts)
>>         }
>>         if (index_differs_from("HEAD", 0))
>>                 return error_dirty_index(opts);
>> -       {
>> +       if (!skip) {
>>                 unsigned char to[20];
>>                 if (!read_ref("HEAD", to))
>>                         add_rewritten(todo_list->item->object.sha1, to);
>
> Couldn't you just say if (skip) todo_list = todo_list -> next?

We are already doing that. And after that we need to continue with the rest of the commits.

Show 6 quoted lines
>> +       if (setup_rerere(&merge_rr, 0) >= 0) {
>> +               rerere_clear(&merge_rr);
>> +               string_list_clear(&merge_rr, 1);
>> +       }
>
> Why exactly?  Why doesn't rebase --skip 'rerere clear'?
It does, and so does 'git am', so why shouldn't 'git cherry-pick'.
Also, I think the same should happen in --abort.
-- 
Felipe Contreras

← back to recent threads