Jeff King <peff@xxxxxxxx> writes: > Good point. We can't really consider clone to be a blind "init + config > + fetch + checkout" because those middle two steps sometimes overlap > each other. It really does need to be its own beast. > ... > The right solution there is probably pushing that logic down into the > transport layer. Or at the very least abstracting it into a function so > that both clone and fetch can call it without replicating the logic. > >> My patch deals with 'remote.<name>.refspec', i.e. 'remote->fetch'. >> Apparently some extra care is necessary for 'remote.<name>.tagOpt' and >> 'remote->fetch_tags', too. Perhaps there are more, I haven't checked >> again, and maybe we'll add similar config variables in the future. So >> I don't think that dealing with such config variables one by one in >> 'git clone', too, is the right long-term solution... but perhaps it's >> sufficient for the time being? > > I think your patch is a strict improvement and we don't need to hold up > waiting for a perfect fix (and because of the --single-branch thing you > mentioned, this may be the best we can do anyway). OK, so where does this patch stand now? It already is too late for the upcoming release, but should we merge it to 'next' once the release is made, cook it in 'next' and shoot for the next release as-is, or do we want to allow minor tweaks before it hits 'next'? Thanks.