Message ID | cover.1608587839.git.jonathantanmy@google.com (mailing list archive) |
---|---|
Headers | show |
Series | Cloning with remote unborn HEAD | expand |
Jonathan Tan <jonathantanmy@google.com> writes: > Jonathan Tan (3): > ls-refs: report unborn targets of symrefs > connect, transport: add no-op arg for future patch > clone: respect remote unborn HEAD This passes standalone all its tests, but in 'seen', seems to break some tests. https://travis-ci.org/github/git/git/builds/750936755 has just started, but my local tests before publishing the day's integration result failed 5702, 0031, and 5606 with this topic, and all passed without the topic. Thanks.
On Mon, Dec 21, 2020 at 02:30:58PM -0800, Jonathan Tan wrote: > > So I dunno. My biggest complaint is that the config option defaults to > > _off_. So it's helping load-balanced rollouts, but creating complexity > > for everyone else who might want to enable the feature. > > So it seems like you're saying that it should default to "on", but at > the same time you are talking about enabling the feature (which seems > to imply switching it from "off" to "on"). (Also, note that this is a > server-side thing; on the client-side, Git will always use what the > server gives and there is no option to control this.) Sorry, I missed this question over the holidays. Yes, what I meant is that everyone should really want this feature on, because it gives strictly more information and lets the client be smarter. But if it defaults to "off", server operators may well not bother to turn it on (or even know it exists). And the clients who would benefit may have trouble convincing server operators to do so. So I would strongly prefer it default to "on", and the onus be on server operators with non-atomic clusters, etc, to turn it off when deploying in their environments. -Peff