Git development
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2016, #02; Mon, 12)
Date: Mon, 19 Dec 2016 11:49:25 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1612191145080.54750@virtualbox> (raw)
In-Reply-To: <xmqqinqn6c41.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Tue, 13 Dec 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >>  While I think it would make it easier for people to experiment and
> >>  build on if the topic is merged to 'next', I am at the same time a
> >>  bit reluctant to merge an unproven new topic that introduces a new
> >>  file format, which we may end up having to support til the end of
> >>  time.  It is likely that to support a "prime clone from CDN", it
> >>  would need a lot more than just "these are the heads and the pack
> >>  data is over there", so this may not be sufficient.
> >> 
> >>  Will discard.
> >
> > You could mark it as experimental, subject to change, and merge it to
> > `next` safely.
> 
> Are you planning, or do you know somebody who plans to use that code
> soonish?

I am too swamped with other things (most importantly, automate the
identification of the as-of-recent-quite-frequent breakages reported by my
build jobs).

I know that one of my colleagues wanted to have a look at it, and so I
thought that having it as an experimental feature that I could even
integrate into Git for Windows for a wider audience could help justify
alotting the time.

> Otherwise I'd prefer to drop it---at this point, the series is merely
> "just because we can", not "because we need it to further improve this
> or that".

Oh, I thought that this was meant as a starting point for anybody
interested in playing with resumable clones or with easing server loads.

In any case, I just wanted to be sure that you considered making it an
experimental feature instead of dropping it. Just in case that you did not
think of that as a possibility.

Ciao,
Dscho

  reply	other threads:[~2016-12-19 11:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-12 21:30 What's cooking in git.git (Dec 2016, #02; Mon, 12) Junio C Hamano
2016-12-13 15:39 ` Johannes Schindelin
2016-12-13 16:09   ` Junio C Hamano
2016-12-13 15:42 ` Johannes Schindelin
2016-12-13 16:13   ` Junio C Hamano
2016-12-19 10:49     ` Johannes Schindelin [this message]
2016-12-19 18:17       ` Junio C Hamano
2016-12-13 19:19 ` Johannes Schindelin
2016-12-13 19:28   ` Junio C Hamano
2016-12-13 21:37     ` Brandon Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1612191145080.54750@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox