On Wed, Aug 22, 2018 at 02:50:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes. I was thinking it had more purpose than this, but it really is just
> > a flag to check "did we do this already?". Which is one of the main
> > purposes I claimed for the new flag in my commit
Jeff King writes:
> Yes. I was thinking it had more purpose than this, but it really is just
> a flag to check "did we do this already?". Which is one of the main
> purposes I claimed for the new flag in my commit message. :)
OK.
The reason I was on the fence was primarily because
Junio C Hamano writes:
> I think this makes sense, but if we were to give a dedicated field
> in the revs structure, can we lose the local variable at the same
> time, I wonder?
>
> Thanks.
Well, the answer to "can we" is always "yes"; what I was truly
wondering was if it makes sense to do so.
ocal variable at the same
> time, I wonder?
Yes. I was thinking it had more purpose than this, but it really is just
a flag to check "did we do this already?". Which is one of the main
purposes I claimed for the new flag in my commit message. :)
Here it is with that squashed in
Jeff King writes:
> Instead, let's keep two flags: one to denote when we got
> actual input (which triggers both roles) and one for when we
> read stdin (which triggers only the first).
>
> This does mean a caller interested in the first role has to
> check both flags, but there's only one such
al patch. After giving it some
thought, I really do think it's cleaner.
I know we're in a freeze. If you want to pick this up for pu or maybe
next, that's fine. If not, I'll re-send it after the release. It applies
on top of Gábor's text fixup patch.
-- >8 --
Subject: [PATCH] rev-list: make empty
6 matches
Mail list logo
