git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	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: Mon, 6 May 2013 16:19:03 -0500	[thread overview]
Message-ID: <CAMP44s1HASAuF0ECCvJr66WeqopDzLZQ12pKFsc-j5_VCDrizg@mail.gmail.com> (raw)
In-Reply-To: <7v38u0t9va.fsf@alter.siamese.dyndns.org>

On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> Yes, it can be handy to start loading the first "blobfile" in parallel
>> with the later stages of the conversion, before the second "dumpfile" is
>> ready.  In that case the user needs to pass --export-marks to the first
>> fast-import process to export marks on blobs so that the marks can be
>> passed to the second fast-import via --import-marks.
>>
>> So the proposed change would break a documented use of cvs2git.
>>
>> Making the export of blob marks optional would of course be OK, as long
>> as the default is to export them.
>
> Thanks for a concise summary.  Your use case fits exactly what
> Felipe conjectured as the nonexistent minority.

Not true. cvs2git does *not* rely on the blobs being stored in a marks
file, because cvs2git does not rely on mark files at all.

> An option that lets the caller say "I only care about marks on these
> types of objects to be written to (and read from) the exported marks
> file" would help Felipe's use case without harming your use case,
> and would be a sane and safe way to go.

His case is not harmed at all. It's only the unfortunate command that
is mentioned in the documentation that didn't need to be mentioned at
all in the first place.

It should be the other way around, if it's only this documentation
that is affected, we could add a switch for that particular command,
and the documentation should be updated, but it's overkill to add a
switch for one odd command in some documentation somewhere, it would
be much better to update the odd command to avoid using marks at all,
which is what the more appropriate command does, right below in the
same documentation.

  cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git fast-import

Should the rest of the real world be punished because somebody added a
command in some documentation somewhere, which wasn't actually needed
in the first place?

-- 
Felipe Contreras

  reply	other threads:[~2013-05-06 21:19 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 [this message]
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

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=CAMP44s1HASAuF0ECCvJr66WeqopDzLZQ12pKFsc-j5_VCDrizg@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=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).