From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@inf.ethz.ch>,
git@vger.kernel.org, Antoine Pelisse <apelisse@gmail.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 4/4] fast-import: only store commit objects
Date: Fri, 3 May 2013 19:01:09 -0500 [thread overview]
Message-ID: <CAMP44s3CPNyrWQoXoNDGaKfH6qniosfFMdjWVD_8FKD+Vge_8Q@mail.gmail.com> (raw)
In-Reply-To: <7vr4hnwru7.fsf@alter.siamese.dyndns.org>
On Fri, May 3, 2013 at 6:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> A safe and sane approach may be to teach these an option to tell
>>> them to omit non-commits or to emit all kinds, and make remote-bzr
>>> use that to exclude non-commits.
>>
>> This has nothing to do with remote-bzr, or any remote helper. These
>> objects are not useful, not even to 'git fast-export'.
>>
>>> If the defaults is matched to the
>>> current behaviour, nobody will get hurt
>>
>> Changing nothing always ensures that nobody will get hurt, but that
>> doesn't improve anything either.
>
> I do not quite follow. Allowing existing code to depend on old
> behaviour, while letting new code that knows it does not need
> anything but commits, will get the best of both worlds. The new code
> will definitely improve (otherwise you won't be writing these
> patches), and the old code will not get hurt. Where is this "doesn't
> improve anything" coming from?
So let's suppose we add a new 'feature no-blob-store' to 'git
fast-import', and some clients of 'git fast-import' enable it, and
benefit from it.
How does that benefit the rest of fast-import clients? You are
worrying about clients that most likely don't exist, and don't let
existing real clients benefit for free. This is like premature
optimization.
But whatever, let's keep writing and discarding these blobs, at least
the previous patches do make such operations fast.
You can drop this patch, because I'm not going to write code for
clients that don't exist. And it seems clear that even if I
investigate client apps of 'git fast-import' and I'm unable to find a
single one that utilizes blobs, you still wouldn't apply this patch.
So there's no point in investigating what are the *actual* users, if
all we are every going to do is worry about hypothetical ones.
My main interest is the previous patches, if anybody has any issues
with the way this patch is handled, they can either work on the patch
itself, or start a new thread in which I will not participate, I will
rather concentrate on issues that affect *real* users, and have real
fixes reachable today, and the previous patches in this series fit
that bill.
Cheers.
--
Felipe Contreras
prev parent reply other threads:[~2013-05-04 0:01 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-03 4:31 [PATCH 0/4] fast-export: speed improvements Felipe Contreras
2013-05-03 4:31 ` [PATCH 1/4] fast-{import,export}: use get_sha1_hex() directly Felipe Contreras
2013-05-03 21:50 ` Junio C Hamano
2013-05-03 4:31 ` [PATCH 2/4] fast-export: improve speed by skipping blobs Felipe Contreras
2013-05-03 21:51 ` Junio C Hamano
2013-05-03 4:31 ` [PATCH 3/4] fast-export: don't parse all the commits Felipe Contreras
2013-05-03 21:54 ` Junio C Hamano
2013-05-04 0:06 ` Felipe Contreras
2013-05-04 19:22 ` Junio C Hamano
2013-05-03 4:31 ` [PATCH 4/4] fast-import: only store commit objects Felipe Contreras
2013-05-03 17:56 ` Thomas Rast
2013-05-03 18:23 ` Felipe Contreras
2013-05-06 10:28 ` Michael Haggerty
2013-05-06 10:32 ` Thomas Rast
2013-05-06 10:45 ` Michael Haggerty
2013-05-06 15:18 ` Junio C Hamano
2013-05-06 21:19 ` Felipe Contreras
2013-05-06 21:36 ` Felipe Contreras
2013-05-07 3:14 ` Michael Haggerty
2013-05-07 4:32 ` Johannes Schindelin
2013-05-07 4:36 ` Felipe Contreras
2013-05-07 2:58 ` Michael Haggerty
2013-05-07 4:37 ` Felipe Contreras
2013-05-06 21:04 ` Felipe Contreras
2013-05-07 3:27 ` Michael Haggerty
2013-05-07 4:39 ` Johannes Schindelin
2013-05-07 4:49 ` Felipe Contreras
2013-05-07 4:47 ` Felipe Contreras
2013-05-07 6:47 ` Michael Haggerty
2013-05-07 7:07 ` Felipe Contreras
2013-05-07 7:12 ` Junio C Hamano
2013-05-07 7:34 ` Michael Haggerty
2013-05-06 12:20 ` Johannes Schindelin
2013-05-06 21:06 ` Felipe Contreras
2013-05-03 22:08 ` Junio C Hamano
2013-05-03 22:19 ` Felipe Contreras
2013-05-03 23:45 ` Junio C Hamano
2013-05-04 0:01 ` Felipe Contreras [this message]
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=CAMP44s3CPNyrWQoXoNDGaKfH6qniosfFMdjWVD_8FKD+Vge_8Q@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=trast@inf.ethz.ch \
/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).