Re: gitpacker progress report and a question

On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond [off-list ref] wrote:

Felipe Contreras [off-list ref]:

quoted

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.

Might be easier to just call 'git ls-files --with-three foo', but I
don't see the point of those calls:

% git --work-tree=unpacked/1 checkout master
% git --work-tree=unpacked/1 add -A

Should work just fine.

quoted

2) Using 'git fast-import' is probably simpler, and more efficient

That might well be.  I'm not worried about "efficiency" in this context
but reducing the code size is significant and I'm willing to re-code
to do that.

I don't see how the code-size would increase dramatically.

quoted

Here is a proof of concept I wrote in ruby that is half the size, and
seems to implement the same functionality.

Not anywhere near the same.  It only handles commits, not tags.

The attached code doesn't handle tags either.

It doesn't issue delete ops.

What do you mean?

    out.puts 'deleteall' <- All current files are removed

And then added.

And it doesn't rebuild branch heads.

What do you mean? Your code only exports a single branch, the branch
that is currently checked out. And then:

git reset --hard >/dev/null; git checkout master >/dev/null 2>&1

It's resuming to 'master', which might not be the branch the user had
checkout out, and might not even exist.

If I were willing to omit those features, I'm sure I could halve
the size of my implementation, too.  Of course, it would then be
almost completely useless...

That's what the code currently does.

Do you want me to show you step by step how they do *exactly the
same*? Of course, I would need to fix your version first so that it
doesn't crash with sub-directories.

quoted

                          The format is exactly the
same, but I think it should be modified to be more efficient.

I'm not wedded to the log format as it is, so I'll cheerfully
take suggestions about it.

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.

Personally I would prefer something like this:

tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
tag v0.3 gst-av-0.3.tar "Release 0.3"

And the script in bash would be very simple:

#!/bin/sh

tag() {
	d=`mktemp -d` &&
	(
	cd $d &&
	tar -xf "$orig/$2" &&
	cd * &&
	git add --all &&
	git commit -q -m "$3" &&
	git tag $1) || error=1
	rm -rf $d
	test -n "$error" && exit -1
}

orig="$PWD"
repo="$1"

git init -q $repo
export GIT_DIR="$orig/$repo/.git"

source "$orig/$2"

cd "$orig/$repo" && git reset -q --hard

-- 
Felipe Contreras