Felipe Contreras <felipe.contre...@gmail.com>:
> Might be easier to just call 'git ls-files --with-three foo', but I
> don't see the point of those calls:
Ah, much is now explained. You were looking at an old version. I had
in fact already fixed the subdirectories bug (I've updated my
regression test to check) and have full support for branchy repos,
preserving tags and branch heads.
> > It doesn't issue delete ops.
> What do you mean?
> out.puts 'deleteall' <- All current files are removed
Yours emits no D ops for files removed after a particular snapshot.
> > Be aware, however, that I consider easy editability by human beings
> > much more important than squeezing the last microsecond out of the
> > processing time. So, for example, I won't use data byte counts rather
> > than end delimiters, the way import streams do.
> Well, if there's a line with a single dot in the commit message ('.'),
> things would go very bad.
Apparently you missed the part where I byte-stuffed the message content.
It's a technique used in a lot of old-school Internet protocols, notably
> Personally I would prefer something like this:
There's a certain elegance to that, but it would be hard to generate by hand.
Remember that a major use case for this tool is making repositories
from projects whose back history exists only as tarballs. So, let's
say you have the following:
What you're going to do before weaving is drop the untarred file trees
in a 'foo' scratch directory, then hand-craft a log file that might
look a bit like this:
Release 1.1 of project foo
..This is an example of a byte-stuffed line.
Release 1.2 of project foo
Release 1.3 of project foo
The main objective of the logfile design is to make hand-crafting
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html