Re: [PATCH] archimport improvements

> Eric,
> 
> 
> On 11/12/05, Eric Wong <normalperson@yhbt.net> wrote:
> > I'm another Arch-user trying out git.  Unfortunately, I encountered
> > several problems with git-archimport that I needed fixed before my
> > development trees could be imported into git.
> 
> Welcome and good stuff! I'll give your patches a try when I sober up.
> In the meantime, some notes after having read the patches a bit...
> 
> > Bug Fixes:
> >
> > * Support for '--branch'-less Arch version names.
> >   Encoding '/' to '--' (as was previously done) is not 100% reversable
> >   because the "--branch" portion of an fully-qualified Arch version name
> >   is optional (though not many people or Arch-related tools know this).
> >
> > * I'm encoding the '/' in the fully-qualified name as ',' to not confuse
> >   other porcelains, but leaving '/' in branch names may be alright
> >   provided porcelains can support them.
> >
> > * Identify git branches as an Arch "archive,category<--branch>--version"
> >   Anything less than that is ambiguous as far as history and patch
> >   relationships go.
> 
> These bug/sanity fixes are _good_. As you mention, I wasn't aware that
> patchnames could show up not having a --branch part. Tricky...

> > * Renamed directories containing renamed/moved files inside didn't get
> >   tracked properly.  The original code was inadequate for this, and
> >   making it support all rename cases that Arch supports is too much
> >   work.  Instead, I maintain full-blown Arch trees in the temp dir and
> >   replay patches + rsync based on that.  Performance is slightly slower
> >   than before, but accuracy is more important to me.
> >
> > * Permission (execute bit only because of git) tracking as a side effect
> >   of the above.
> 
> Hmmm. I understand what you are doing, but I'm not sure we'd want to
> replace the current code with this strategy.  Importing large trees
> with hundreds (thousands) of commits is so slow it is just a no go.
> Renames are described quite well in the 'commit log', and the current
> code does handle file renames...

> > * Pika-escaped filenames unhandled.  This seems fixed in the latest
> >   git, but I fixed it more generally and removed the ShellQuote module
> >   dependency along the way.
> 
> Yes, this got fixed recently. Your change here goes together with the
> 'tla get' + rsync strategy which I'm not sure about.
> 
> > * Don't die() when a merge-base can't be found.  Arch supports
> >   merging between unrelated trees.
> 
> Fair enough. Does it result on a good graft in git?

> > Usability enhancements:
> >
> > * Optionally detect merged branches and attempt to import their history,
> >   too.  Use the -D <depth> option for this.  Specifying a <depth>
> >   greater than 1 is usually not needed unless the tree you're tracking
> >   has had history pruned.
> >
> > * Optionally attempt to auto-register unknown Arch archives from
> >   mirrors.sourcecontrol.net to pull their history with the -a (boolean)
> >   switch.  Not sure how useful users will find this.
> 
> Those two are interesting!
> 
> > * Removed -A <archive> usage (unnecessary in all cases) and made all
> >   Arch calls and output parsing to be compatible with both tla (tested
> >   1.3.3) and baz (1.4.2).  Default is still tla, but the ARCH_CLIENT
> >   environment variable may be changed to baz.
> 
> That's excellent -- thanks!
> 
> > Current weaknesses:
> >
> > * (Present in the original code as well).
> >   The code still assumes that dates in commit logs can be trusted, which is
> >   fine in most cases, but a wayward branch can screw up git-archimport and
> >   cause parents to be missed.
> 
> Fair enough. You mention an alternative strategy (tla ancestry) --
> have you tried it at all?