All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH 1/1] commit-reach: properly peel tags
Date: Wed, 12 Sep 2018 17:34:08 -0400	[thread overview]
Message-ID: <20180912213407.GA27598@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqpnxijtpd.fsf@gitster-ct.c.googlers.com>

On Wed, Sep 12, 2018 at 02:23:42PM -0700, Junio C Hamano wrote:

> > diff --git a/commit-reach.c b/commit-reach.c
> > index 86715c103c..6de72c6e03 100644
> > --- a/commit-reach.c
> > +++ b/commit-reach.c
> > @@ -544,20 +544,31 @@ int can_all_from_reach_with_flag(struct object_array *from,
> >  {
> >  	struct commit **list = NULL;
> >  	int i;
> > +	int nr_commits;
> >  	int result = 1;
> >  
> >  	ALLOC_ARRAY(list, from->nr);
> > +	nr_commits = 0;
> >  	for (i = 0; i < from->nr; i++) {
> > -		list[i] = (struct commit *)from->objects[i].item;
> > +		struct object *from_one = from->objects[i].item;
> >  
> > -		if (parse_commit(list[i]) ||
> > -		    list[i]->generation < min_generation)
> > -			return 0;
> > +		from_one = deref_tag(the_repository, from_one,
> > +				     "a from object", 0);
> > +		if (!from_one || from_one->type != OBJ_COMMIT) {
> > +			from->objects[i].item->flags |= assign_flag;
> 
> I wondered why this is not futzing with "from_one->flags"; by going
> back to the original from->objects[] array, the code is setting the
> flags on the original tag object and not the non-commit object that
> was pointed at by the tag.

Note that from_one may even be NULL.

> > +			continue;
> > +		}
> > +
> > +		list[nr_commits] = (struct commit *)from_one;
> > +		if (parse_commit(list[nr_commits]) ||
> > +		    list[nr_commits]->generation < min_generation)
> > +			return 0; /* is this a leak? */
> > +		nr_commits++;
> >  	}
> 
> In the original code, the flags bits were left unchanged if the loop
> terminated by hitting a commit whose generation is too young (or
> parse_commit() returns non-zero).  With this updated code, flags bit
> can be modified before the code notices the situation and leave the
> function, bypassing the "cleanup" we see below that clears the
> "assign_flag" bits.
> 
> Would it be a problem that we return early without cleaning up?
> 
> Even if we do not call this early return, the assign_flag bits added
> to the original tag in from->objects[i].item won't be cleaned in
> this new code, as "cleanup:" section now loops over the list[] that
> omits the object whose flags was smudged above before the "continue".
> 
> Would it be a problem that we leave the assign_flags without
> cleaning up?

Yeah, I hadn't thought about the bit cleanup when making my original
suggestion. In the original code (before 4fbcca4eff), I think we did set
flags as we iterated through the loop, and we could still do an early
return when we hit "!reachable(...)". But I don't see any cleanup of
assign_flag there at all.

So I guess I'm pretty confused about what the semantics are supposed to
be.

-Peff

  reply	other threads:[~2018-09-12 21:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 14:22 [PATCH 0/1] Properly peel tags in can_all_from_reach_with_flags() Derrick Stolee via GitGitGadget
2018-09-12 14:22 ` [PATCH 1/1] commit-reach: properly peel tags Derrick Stolee via GitGitGadget
2018-09-12 19:41   ` Jeff King
2018-09-12 21:23   ` Junio C Hamano
2018-09-12 21:34     ` Jeff King [this message]
2018-09-13 16:10 ` [PATCH v2 0/1] Properly peel tags in can_all_from_reach_with_flags() Derrick Stolee via GitGitGadget
2018-09-13 16:10   ` [PATCH v2 1/1] commit-reach: properly peel tags Derrick Stolee via GitGitGadget
2018-09-13 16:38     ` Derrick Stolee
2018-09-13 21:06       ` Junio C Hamano
2018-09-21 15:05   ` [PATCH v3 0/2] Properly peel tags in can_all_from_reach_with_flags() Derrick Stolee via GitGitGadget
2018-09-21 15:05     ` [PATCH v3 1/2] commit-reach: properly peel tags Derrick Stolee via GitGitGadget
2018-09-21 23:56       ` Jeff King
2018-09-24 11:48         ` Derrick Stolee
2018-09-21 15:05     ` [PATCH v3 2/2] commit-reach: fix memory and flag leaks Derrick Stolee via GitGitGadget
2018-09-21 23:58       ` Jeff King
2018-09-24 17:25         ` Derrick Stolee
2018-09-24 19:06           ` Jeff King
2018-09-24 20:57     ` [PATCH v4 0/1] Properly peel tags in can_all_from_reach_with_flags() Derrick Stolee via GitGitGadget
2018-09-24 20:57       ` [PATCH v4 1/1] commit-reach: properly peel tags and clear flags Derrick Stolee via GitGitGadget
2018-09-24 21:09         ` Jeff King
2018-09-25  5:17         ` Eric Sunshine
2018-09-25 13:27       ` [PATCH] commit-reach: cleanups in can_all_from_reach Derrick Stolee
2018-09-25 18:06         ` Junio C Hamano
2018-09-25 18:13           ` Derrick Stolee
2018-09-25 20:29             ` Junio C Hamano

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=20180912213407.GA27598@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.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.