On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond <esr@xxxxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx>:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html