Re: git-p4import.py robustness changes

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 4, 2007, 06:18 UTC
Message-ID: <20070604061859.GG4507@spearce.org>
In-Reply-To: <56b7f5510706032309w4aee791dnd3bf5d46974bdaba@mail.gmail.com>

Dana How <danahow@gmail.com> wrote:

Show 12 quoted lines

> On 6/3/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >I think writing data to fast-import is much easier than running
> >the raw Git commands, especially when you are talking about an
> >import engine where you need to set all of the special environment
> >variables for git-commit-tree or git-tag to do its job properly.
> >Its a good tool that simply doesn't get enough use, partly because
> >nobody is using it...
> 
> Well,  perhaps they use it *once*,  in that they write a wrapper script for
> it and then forget about it.  At least that's what I did.  And the _only_
> annoyance was the trailing NL requirement on the delimited "data" statement,
> so you don't get much noise/complaints when people use it.

True. I did try to make fast-import take a simple enough format that you could write throwaway code against it, run it, and never look back...

The trailing NL after data was because of cvs2svn. The SVN dump file format apparently does something like this, and the version of cvs2svn that Jon Smirl was working on output that trailing NL. Accepting it in fast-import was easier than fixing cvs2svn to not create it.

I'll admit the error handling in fast-import could probably be easier, and that NL after data probably could be optional. I don't think the input stream parser needs it to understand what is going on. Its just sheer laziness on my part that the code requires it there.

-- 
Shawn.