Re: [PATCH 2/4] fast-import: define a new option command

From: Shawn O. Pearce <spearce@spearce.org>
Date: Aug 13, 2009, 22:12 UTC
Message-ID: <20090813221213.GR1033@spearce.org>
In-Reply-To: <fabb9a1e0908131501o73807f81mb230530c284ad123@mail.gmail.com>

Sverre Rabbelier <srabbelier@gmail.com> wrote:

Show 17 quoted lines

> On Thu, Aug 13, 2009 at 14:51, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > Sorry if I spoil the party, but maybe if things get so complicated, it may
> > be a sign that the original version (stream overrides command line, since
> > it knows better) is to be preferred? ?After all, if hg fast-export says
> > that the marks should be imported from a certain file, it may be for a
> > _very good_ reason...
> 
> Yes, and that should Just Work (which it does). Also, I'm not sure how
> often one would output a stream on one computer, then move it to
> another and import it there, but I'll methinks Shawn brought it up for
> a reason ;). However, I do think it's better design to only store the
> name of the import file and then do the actual import later on (to
> prevent double imports).
> 
> I don't have a preference either way (both patches are already written
> after all). Shawn?

No, I don't have a really good reason for the command line overrides the file other than this simple rule:

  If the file is likely to be several hundred MiB, or bigger; thou
  shall never try to open it with vi, *especially* vi on a Solaris
  system, as at least one line is likely to be too long.

  If the file header contains paths to other files, it is likely
  one will want to modify that header sometime, because you moved
  the file between systems.

  Given the size of the file above, you can't just fix it with vi.

  Lacking a tool that *can* do this edit safely (and Dscho's simple
  sed wasn't enough, as I already pointed out, oh and Solaris sed
  also fails on long lines), we *should* be able to override this on
  the command line, *especially* since we already have the command
  line option standardized!

What is this, gang up on Shawn's words-of-wisdom week? Both this thread and my intern this week have been argueing with me about what seem to me to be fairly trivial things. Maybe I just need to take vacation. Good thing I have one coming in 5 weeks.

I say use the version where we store the values (e.g. file names) during option parsing, and then actually apply those saved values just before the first non-option command. Which I think only has an impact on the import-marks option, the rest are all just simple variable updates whose values aren't read until after the first non-option command anyway.

-- 
Shawn.