From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
git@vger.kernel.org, Antoine Pelisse <apelisse@gmail.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs
Date: Mon, 6 May 2013 22:49:28 -0500 [thread overview]
Message-ID: <CAMP44s0VBiWN5fZachCDkg9EHZKHRU5idNBdktV2a5wBMJvxjQ@mail.gmail.com> (raw)
In-Reply-To: <7vmws7o8hx.fsf@alter.siamese.dyndns.org>
On Mon, May 6, 2013 at 8:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>>> How?
>>>
>>> * if we teach fast-import to optionally not write marks for blobs
>>> and trees out, your remote-bzr can take advantage of it,
>>
>> I already said remote-bzr is irrelevant. *Everybody* benefits.
>
> Everybody who does _not_ need to look at marks for non-commits from
> previous run does.
IOW; everyone.
> What about the others who do?
Like who?
> Surely, some lucky ones may get the benefit of a new optimization
> for free if you turn it on uncondtionally without an escape hatch,
> but that goes against our goal of not to knowingly introduce any
> regression.
That's different. One thing is to turn it on unconditionally, and
another thing is to turn it on by *default*.
> Michael's cvs2git might have a way to work the breakage
> around (I will let him comment on your suggested workaround), but as
> long as he has been coding it using the documented feature, why
> should he even change anything for no gain at all in the first
> place? Even if you have a workaround, that does not change the fact
> that a removal of a feature that somebody has been depending on is a
> regression.
Who is depending on it? Michael didn't say that he used that feature,
merely that it was documented in cvs2git, because Windows doesn't have
'cat'. He claimed that other people *might* be using that "feature",
but we don't *know*.
Is a couple of commands somebody wrote in some documentation which can
be easily fixed, reason enough to punish everyone else?
> What's so difficult to understand that by default the responsibility
> of making sure an optimization applies safely to a program that uses
> a new optmization lies on that program, in other words, a new
> feature is by default an opt-in?
Is that written in some git bible descended from some god that I
missed? If not, everything are guidelines, and guidelines are there
for a reason, and those reasons can be challenged, and so can the
guidelines.
Sometimes it makes sense to make a new feature opt-in, sometimes it
doesn't, there are no absolutes, there should be no dogmas.
--
Felipe Contreras
next prev parent reply other threads:[~2013-05-07 3:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-05 22:38 [PATCH v2 0/3] fast-export: speed improvements Felipe Contreras
2013-05-05 22:38 ` [PATCH v2 1/3] fast-{import,export}: use get_sha1_hex() directly Felipe Contreras
2013-05-07 14:38 ` Junio C Hamano
2013-05-07 22:13 ` Felipe Contreras
2013-05-07 23:19 ` Junio C Hamano
2013-05-05 22:38 ` [PATCH v2 2/3] fast-export: improve speed by skipping blobs Felipe Contreras
2013-05-06 12:31 ` Jeff King
2013-05-06 15:08 ` Junio C Hamano
2013-05-06 16:17 ` Junio C Hamano
2013-05-06 16:20 ` Jeff King
2013-05-06 16:32 ` Junio C Hamano
2013-05-06 16:40 ` Jeff King
2013-05-06 17:17 ` Junio C Hamano
2013-05-06 17:19 ` Jeff King
2013-05-06 17:41 ` Jeff King
2013-05-06 19:12 ` Felipe Contreras
2013-05-06 19:09 ` Felipe Contreras
2013-05-06 20:58 ` Junio C Hamano
2013-05-06 21:30 ` Felipe Contreras
2013-05-07 1:59 ` Junio C Hamano
2013-05-07 3:49 ` Felipe Contreras [this message]
2013-05-06 19:02 ` Felipe Contreras
2013-05-06 19:11 ` Jeff King
2013-05-06 19:15 ` Felipe Contreras
2013-05-05 22:38 ` [PATCH v2 3/3] fast-export: don't parse all the commits Felipe Contreras
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=CAMP44s0VBiWN5fZachCDkg9EHZKHRU5idNBdktV2a5wBMJvxjQ@mail.gmail.com \
--to=felipe.contreras@gmail.com \
--cc=apelisse@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
/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;
as well as URLs for NNTP newsgroup(s).