Thread (7 messages) flat view 7 messages, 3 authors, 2016-12-05

Re: Git v2.11.0 breaks max depth nested alternates

From: Jeff King <hidden>
Date: 2016-12-05 07:14:38

On Sun, Dec 04, 2016 at 01:37:00AM -0800, Kyle J. McKay wrote:
On Dec 3, 2016, at 20:55, Jeff King wrote:
quoted
So I do think this is worth dealing with, but I'm also curious why
you're hitting the depth-5 limit. I'm guessing it has to do with hosting
a hierarchy of related repos. But is your system then always in danger
of busting the 5-limit if people create too deep a repository hierarchy?
No we check for the limit.  Anything at the limit gets broken by the
quarantine change though.
OK. So the limit is an issue for your system, but one that you're able
to deal gracefully with (and the quarantine change makes that a lot
harder). I buy that line of reasoning.
The patch is a step on that road.  It doesn't go that far but all it would
take is connecting the introduced variable to a config item.  But you still
need to bump it by 1 during quarantine operations.  Such support would even
allow alternates to be disallowed (except during quarantine).  I wonder if
there's an opportunity for further pack operation optimizations in such a
case (you know there are no alternates because they're not allowed)?
I doubt it. We look at the list of alternates early on, and in most
cases there aren't any. So any optimization there can be done already at
that point.

The only optimization I know if in that area is 56dfeb626 (pack-objects:
compute local/ignore_pack_keep early, 2016-07-29), which works already.
All true.  And I had similar thoughts.  Perhaps we should add your comments
to the patch description?  There seems to be a trend towards having longer
patch descriptions these days... ;)
Feel free to pick out anything that's useful and add it in verbatim or
rephrased, whichever is more convenient.
You took the words right out of my mouth...   I guess I need to work on
doing a better job of dumping my stream-of-thoughts that go into a patch
into the emails to the list.
It's a lot easier when you're the reviewer, because you don't start
reading through the commit-message with a full understanding of the
problem yet. :)
Most all of your comments could be dumped into the patch description as-is
to pimp it out some.  I have no objection to that, even adding an
"Additional-analysis-by:" (or similar) credit line too.  :)
Sure. I don't really need credit, or even just "reviewed-by" is fine.
Talking and generating a shared understanding of the problem is part of
the review process.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help