From: "Shawn O. Pearce" <spearce@spearce.org>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)
Date: Thu, 8 Oct 2009 10:39:00 -0700 [thread overview]
Message-ID: <20091008173900.GI9261@spearce.org> (raw)
In-Reply-To: <fabb9a1e0910072349q68d6756cgebb041a0bbe2ba65@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Oct 8, 2009 at 08:49, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Shawn, last time I heard of this issue, it was stuck in your review queue.
>
> Correct, am waiting for Shawn's decision on whether to drop options
> and replace them with additional features or not.
Uh. Wow, it has been a while.
IIRC my problem with options was we weren't enforcing them, and yet
they were necessary for a successful import, e.g. import-marks or
export-marks. A minor error could cause a successful looking import
that is wrong due to the marks being messed up, or not saved out.
So I was leaning towards making these features, but then they
aren't necessarily compatible with the other fast-import tools.
Which led me to a stalemate, and I forgot about the thread.
Dammit.
We should run this past the fast-import list but I think we want
to declare features for import-marks and export-marks:
feature import-marks=in.marks
feature export-marks=out.marks
and define these as paths to local files which store a VCS specific
formatted mapping of fast-import mark numbers to VCS labels.
Other options that are clearly git should be declared as:
option git max-pack-size=2048
with the meaning of option being declared something like:
If the parsing VCS name appears as the first argument, the parsing
VCS must recognize and support the supplied option, and if not
recognized or not supported must abort parsing altogether.
If the parsing VCS name is not the first argument, it must entirely
ignore the option command and not try to process its contents.
--
Shawn.
next prev parent reply other threads:[~2009-10-08 17:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-08 6:33 What's cooking in git.git (Oct 2009, #01; Wed, 07) Junio C Hamano
2009-10-08 6:49 ` Johannes Schindelin
2009-10-08 6:49 ` Sverre Rabbelier
2009-10-08 17:39 ` Shawn O. Pearce [this message]
2009-10-08 17:58 ` Sverre Rabbelier
2009-10-11 11:40 ` [Vcs-fast-import-devs] " Matt McClure
2009-10-11 11:58 ` Sverre Rabbelier
2009-10-28 22:08 ` Sverre Rabbelier
2009-10-28 23:19 ` [Vcs-fast-import-devs] " Ian Clatworthy
2009-10-29 10:54 ` Johannes Schindelin
2009-10-30 3:50 ` [Vcs-fast-import-devs] " Ian Clatworthy
2009-10-30 12:41 ` Sverre Rabbelier
2009-10-08 6:58 ` Marius Storm-Olsen
2009-10-08 18:15 ` Erik Faye-Lund
2009-10-09 6:47 ` Junio C Hamano
2009-10-09 1:38 ` Jakub Narebski
2009-10-09 6:46 ` Junio C Hamano
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=20091008173900.GI9261@spearce.org \
--to=spearce@spearce.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=srabbelier@gmail.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;
as well as URLs for NNTP newsgroup(s).