Re: Git clonebundles

Johannes Schindelin [off-list ref] writes:

quoted

If people think it might be useful to have it around to experiment, I
can resurrect and keep that in 'pu' (or rather 'jch'), as long as it
does not overlap and conflict with other topics in flight.  Let me try
that in today's integration cycle.

I would like to remind you of my suggestion to make this more publicly
visible and substantially easier to play with, by adding it as an
experimental feature (possibly guarded via an explicit opt-in config
setting).

I do not understand why you want to give this topic undue prominence
ovver any other random topic that cook in 'pu' and later merged down
to 'next' and then 'master' only after they turn out to be useful
(or at least harmless).

If there were somebody who is the champion of that topic, advocating
that any clone-bundle solution must be based on this topic, it would
be different.  Even though I am not opposed to the topic myself, I
am not that somebody.  That is why I kept it around to wait to see
if somebody finds it potentially useful and then discarded it after
seeing no such person stepped up.

That champion of the topic would spend the necessaly engineering
effort to document it as experimental, to make sure that there is a
reasonable upgrade/transition route if the "v3" format turns out to
be not very useful, etc. by rerolling the patches or following-up on
them to advance it from 'pu' down to 'next' and to 'master' just
like any other topic.

Judging from the tone of his message (i.e. "unfortunately" in it),
Christian may want to be one, or somebody else may want to be one.

Hi Junio,

On Tue, 7 Feb 2017, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

quoted

If people think it might be useful to have it around to experiment, I
can resurrect and keep that in 'pu' (or rather 'jch'), as long as it
does not overlap and conflict with other topics in flight.  Let me try
that in today's integration cycle.

I would like to remind you of my suggestion to make this more publicly
visible and substantially easier to play with, by adding it as an
experimental feature (possibly guarded via an explicit opt-in config
setting).

I do not understand why you want to give this topic undue prominence
ovver any other random topic that cook in 'pu' [...]

Since you ask so nicely for an explanation: clonebundles got a really
lively and active discussion at the Contributors' Summit. So it is not
your run of the mill typo fix, the bundle issue is something that clearly
receives a lot of interest in particular from developers who are
unfamiliar with the idiosynchracies of the code Git development.

And I got the very distinct impression that Git would benefit a lot from
these developers, *in particular* since they come with fresh perspectives.

Now, we can make it hard for them (e.g. expecting them to sift through a
few months' worth of What's Cooking mails, to find out whether there has
been any related work, and what is the branch name, if any, and where to
find that branch), and we can alternatively make it easy for them to help
us make Git better.

I would like us to choose the easier route for them. Because it would
benefit us.

Ciao,
Johannes