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
in SMTP.
> 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:

commit 1
directory foo-1.1

Release 1.1 of project foo
commit 2
directory foo-1.2

..This is an example of a byte-stuffed line.

Release 1.2 of project foo
commit 3
directory foo-1.3

Release 1.3 of project foo

The main objective of the logfile design is to make hand-crafting 
these easy.  
                <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

Reply via email to