Re: gitpacker progress report and a question

2012-11-27 Thread Felipe Contreras
On Tue, Nov 27, 2012 at 9:36 AM, Eric S. Raymond wrote: > Felipe Contreras : >> Most of those old projects have a linear history, > > INTERCAL didn't. There were two branches for platform ports. Fine: tag v0.1 gst-av-0.1.tar "Release 0.1" tag v0.2 gst-av-0.2.tar "Release 0.2" checkout port1 tag

Re: gitpacker progress report and a question

2012-11-27 Thread Eric S. Raymond
Felipe Contreras : > Most of those old projects have a linear history, INTERCAL didn't. There were two branches for platform ports. > But different commit/author and respective dates, and merges? Sounds > like overkill. I felt it was important that the metadata format be able to specify git's e

Re: gitpacker progress report and a question

2012-11-26 Thread Eric S. Raymond
Felipe Contreras : > > The main objective of the logfile design is to make hand-crafting > > these easy. > > Here's another version with YAML: Clever. Now I have to decide if I should allow my aesthetic dislike of YAML to prevail despite the fact that it's pretty well suited to this job. Ther

Re: gitpacker progress report and a question

2012-11-26 Thread Eric S. Raymond
Felipe Contreras : > I believe that log file is much more human readable. Yet I still fail > to see why would anybody want so much detail only to import tarballs. The first time I needed such a tool (and I really should have built it then) was during the events I wrote up in 2010 the INTERCAL Rec

Re: gitpacker progress report and a question

2012-11-26 Thread Felipe Contreras
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond wrote: > --- > 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 > director

Re: gitpacker progress report and a question

2012-11-26 Thread Felipe Contreras
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond wrote: > Felipe Contreras : >> 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 subdire

Re: gitpacker progress report and a question

2012-11-26 Thread Eric S. Raymond
Felipe Contreras : > 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 ful

Re: gitpacker progress report and a question

2012-11-26 Thread Felipe Contreras
On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond wrote: > Felipe Contreras : >> 1) I tried it, and it doesn't seem to import (pack?) are repository >> with sub-directories in it > > I'll make sure my regression test checks this case. The options to git > ls-files are a bit confusing and it's pos

Re: gitpacker progress report and a question

2012-11-26 Thread Eric S. Raymond
Felipe Contreras : > 1) I tried it, and it doesn't seem to import (pack?) are repository > with sub-directories in it I'll make sure my regression test checks this case. The options to git ls-files are a bit confusing and it's possible my invocation of it needs to change. > 2) Using 'git fast-

Re: gitpacker progress report and a question

2012-11-26 Thread Felipe Contreras
On Thu, Nov 15, 2012 at 10:28 PM, Eric S. Raymond wrote: > Some days ago I reported that I was attempting to write a tool that could > (a) take a git repo and unpack it into a tarball sequence plus a metadata log, > (b) reverse that operation, packing a tarball and log sequence into a repo. > > Th

Re: gitpacker progress report and a question

2012-11-16 Thread Andreas Schwab
"Eric S. Raymond" writes: > if commitcount > 1: > do_or_die("rm `git ls-tree --name-only HEAD`") This will fail on file names containing whitespace or glob meta characters. Better use "git rm -qr ." here. You don't have to care about the index since

Re: gitpacker progress report and a question

2012-11-15 Thread Eric S. Raymond
Max Horn : > > I'm still looking for a better name for it and would welcome suggestions. > > Isn't "gitar" the kind of natural choice? ;) At least for a stand-alone tool, > not for a git subcommand. I just renamed it git-weave. I keep talking about tarballs because I keep thinking about using i

Re: gitpacker progress report and a question

2012-11-15 Thread Max Horn
On 15.11.2012, at 22:28, Eric S. Raymond wrote: > Some days ago I reported that I was attempting to write a tool that could > (a) take a git repo and unpack it into a tarball sequence plus a metadata log, > (b) reverse that operation, packing a tarball and log sequence into a repo. Ah, I could h

gitpacker progress report and a question

2012-11-15 Thread Eric S. Raymond
Some days ago I reported that I was attempting to write a tool that could (a) take a git repo and unpack it into a tarball sequence plus a metadata log, (b) reverse that operation, packing a tarball and log sequence into a repo. Thanks in part to advice by Andreas Schwab and in part to looking at