Re: gitpacker progress report and a question

[Felipe Contreras <felipe.contreras@gmail.com>]

On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> 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.

>> 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.

>> 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.

>>                           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