All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ye Xiaolong <xiaolong.ye@intel.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	git@vger.kernel.org, Stefan Beller <sbeller@google.com>
Subject: Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range
Date: Mon, 4 Jun 2018 10:41:01 +0800	[thread overview]
Message-ID: <20180604024101.GO27396@yexl-desktop> (raw)
In-Reply-To: <xmqqh8mj70w6.fsf@gitster-ct.c.googlers.com>

On 06/04, Junio C Hamano wrote:
>Ye Xiaolong <xiaolong.ye@intel.com> writes:
>
>> I narrowed down the problem to revision walk, if users specify the commit range
>> via "Z..C" pattern, the first prepare_revision_walk function called in
>> cmd_format_patch would mark all parents (ancestors) of Z to be uninteresting,
>> thus the next revision walk in prepare_bases wouldn't be able to reach
>> prerequisite patches, one quick solution I can think of is to clear
>> UNINTERESTING flag in reset_revision_walk, like below:
>>
>> void reset_revision_walk(void)
>> {
>> 	clear_object_flags(SEEN | ADDED | SHOWN| UNINTERESTING);
>> }
>
>When you are done with objects that are UNINTERESTING in your
>application (i.e. only when "format-patch" is told to compute list
>of prereq patches by doing an extra revision walk), your application
>can call clear_object_flags() on the flags you are done with, I
>would think.
>
>But the current callers of reset_revision_walk() do not expect any
>flags other than the ones that are used to keep track of the
>traversal state, so it is likely you will break them if you suddenly
>started to clear flags randomly.

Got it, I'll try to call clear_object_flags in format-patch related codepatch
only, not to touch the global reset_revision_walk.

Thanks,
Xiaolong

  reply	other threads:[~2018-06-04  2:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29 18:46 format-patch: no 'prerequisite-patch-id' info when specifying commit range Eduardo Habkost
2018-05-30  7:04 ` Ye Xiaolong
2018-06-03  6:07 ` Ye Xiaolong
2018-06-04  2:15   ` Junio C Hamano
2018-06-04  2:41     ` Ye Xiaolong [this message]
2018-06-04 15:05     ` [PATCH] format-patch: clear UNINTERESTING flag before prepare_bases Xiaolong Ye
2018-06-04 19:42       ` Eduardo Habkost
2018-06-19  2:40       ` Ye Xiaolong
2018-06-19 18:18       ` Stefan Beller

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=20180604024101.GO27396@yexl-desktop \
    --to=xiaolong.ye@intel.com \
    --cc=ehabkost@redhat.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sbeller@google.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 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.