patch, 2 partsSmall log simplifications

> get_patch_ids() takes an already initialized rev_info and a
> prefix. The prefix is used when initalizing a second rev_info. Since
> the initialized rev_info already has a prefix and it seems the prefix
> doesn't change, we can used the prefix from the initialized rev_info
> to initialize the second rev_info.

>  builtin/log.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index ecc2793..7a92e3f 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -696,7 +696,7 @@ static int reopen_stdout(struct commit *commit, const char *subject,
>  	return 0;
>  }
>  
> -static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const char *prefix)
> +static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids)
>  {
>  	struct rev_info check_rev;
>  	struct commit *commit;
> @@ -717,7 +717,7 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
>  	init_patch_ids(ids);
>  
>  	/* given a range a..b get all patch ids for b..a */
> -	init_revisions(&check_rev, prefix);
> +	init_revisions(&check_rev, rev->prefix);
>  	o1->flags ^= UNINTERESTING;
>  	o2->flags ^= UNINTERESTING;
>  	add_pending_object(&check_rev, o1, "o1");
> @@ -1306,7 +1306,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
>  			if (hashcmp(o[0].item->sha1, o[1].item->sha1) == 0)
>  				return 0;
>  		}
> -		get_patch_ids(&rev, &ids, prefix);
> +		get_patch_ids(&rev, &ids);
>  	}
>  
>  	if (!use_stdout)
> @@ -1525,7 +1525,7 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
>  			return 0;
>  	}
>  
> -	get_patch_ids(&revs, &ids, prefix);
> +	get_patch_ids(&revs, &ids);
>  
>  	if (limit && add_pending_commit(limit, &revs, UNINTERESTING))
>  		die(_("Unknown commit %s"), limit);

> While walking the revision list in get_patch_ids and cmd_cherry, we
> ignore merges by checking if there is more than one parent. However,
> since the revision walk was initialized with revs.ignore_merges = 1,
> this would never happen. Remove the unnecessary checks.
>
> Also re-initializing rev_info fields to the same values already set in
> init_revisions().
>
> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>

> ---
>  builtin/log.c | 10 ----------
>  1 file changed, 10 deletions(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 7a92e3f..8182a18 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -726,10 +726,6 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids)
>  		die(_("revision walk setup failed"));
>  
>  	while ((commit = get_revision(&check_rev)) != NULL) {
> -		/* ignore merges */
> -		if (commit->parents && commit->parents->next)
> -			continue;
> -
>  		add_commit_patch_id(commit, ids);
>  	}
>  
> @@ -1509,8 +1505,6 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
>  
>  	init_revisions(&revs, prefix);
>  	revs.diff = 1;
> -	revs.combine_merges = 0;
> -	revs.ignore_merges = 1;
>  	DIFF_OPT_SET(&revs.diffopt, RECURSIVE);
>  
>  	if (add_pending_commit(head, &revs, 0))
> @@ -1534,10 +1528,6 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
>  	if (prepare_revision_walk(&revs))
>  		die(_("revision walk setup failed"));
>  	while ((commit = get_revision(&revs)) != NULL) {
> -		/* ignore merges */
> -		if (commit->parents && commit->parents->next)
> -			continue;
> -
>  		commit_list_insert(commit, &list);
>  	}

> I suspect that
> explicit initialization to revs.ignore_merges outself can be called
> belt-and-braces defensive programming to avoid getting surprised by
> future changes to what init_revisions() would do, so I do not have
> strong preference either way.

> On Fri, Jul 27, 2012 at 11:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> It seems to have some interaction with your other topic, though.
>> These two patches alone will pass the existing tests, but merging it
>> with mz/rebase-range breaks t3412.  I didn't look into it, but
>> perhaps this breaks "git cherry" in some way?
>
> Yes, it breaks "git cherry" quite badly, by not ignoring merges at
> all. I incorrectly assumed that ignore_merges was about revision
> traversal, but now I think it's only diff output from 'git log' (and
> possibly others). What I think tricked me was seeing that
> "ignore_merges = 1" closely followed by a comment saying "ignore
> merges". But now I think the explicit code to "ignore merges" is
> necessary (as show by the failing test case), but can be replaced by
> "rev_info.max_parents = 1". Setting "ignore_merges = 1", OTOH, now
> seems doubly redundant: not only does it set the same value as was set
> in init_revisions, but it's also irrelevant. Since cherry doesn't
> generate any diff output, I think ignore_merges is never used.
> Flipping the values of all of "ignore_merges", "combine_merges" and
> "diff" does not have any effect on test cases at least. I hope my
> explanation makes some sense at least...
>
> I'll send a reroll when I get time.