Felipe Contreras <[email protected]>:
> 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:
foo-1.1.tar.gz
foo-1.2.tar.gz
foo-1.3.tar.gz
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
