From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Mike Hommey <mh@glandium.org>, git@vger.kernel.org
Subject: Re: Should reset_revision_walk clear more flags?
Date: Sun, 04 Dec 2016 23:26:04 -0800 [thread overview]
Message-ID: <xmqqmvga6dmb.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20161205054013.taosbwjamxiwzocn@sigill.intra.peff.net> (Jeff King's message of "Mon, 5 Dec 2016 00:40:13 -0500")
Jeff King <peff@peff.net> writes:
> Which I think would include both of the flags you mentioned, along with
> others like SYMMETRIC_LEFT, PATCHSAME, etc. Probably really everything
> mentioned in revision.h, which should be summed up as ALL_REV_FLAGS.
> Some callsites already seem to feed that to clear_commit_marks().
>
> I doubt you can go too wrong by clearing more flags.
This and ...
> It's possible that
> some caller is relying on a flag _not_ being cleared between two
> traversals, but in that case it should probably be using
> clear_commit_marks() or clear_object_flags() explicitly to make it clear
> what it expects to be saved.
... this are contradictory, no?
A caller may use two sets of its own flags in addition to letting
the traversal machinery use the basic ones, and it may want to keep
one of its own two sets while clearing the other set. It would
clear_commit_marks() to clear the latter. And then it would let
that the next traversal to reset_revision_walk() clear the basic
ones.
So if you make reset_revision_walk() clear "more flags", that would
break such a caller that is using clear_commit_marks() to make it
clear what its expectations are, no?
I dunno.
next prev parent reply other threads:[~2016-12-05 7:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-04 23:09 Should reset_revision_walk clear more flags? Mike Hommey
2016-12-04 23:24 ` Mike Hommey
2016-12-05 5:40 ` Jeff King
2016-12-05 7:26 ` Junio C Hamano [this message]
2016-12-05 7:36 ` Jeff King
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=xmqqmvga6dmb.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mh@glandium.org \
--cc=peff@peff.net \
/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