Jeff Garzik [off-list ref] writes:
Junio C Hamano wrote:
quoted
- One important newcomer is git-pack-redundant...
IMHO git-prune-packed should prune redundant pack files...
Maybe not in git-prune-packed, but you are right. We should at
least do that in git-prune. Maybe with something like the patch
at the end?
quoted
Oh, and we will not be moving things out of /usr/bin/ during 1.0
timeframe.
:( bummer. I do like the elegance of having /usr/bin/git executing
stuff out of /usr/libexec/git.
Bummer here as well. This is not my first preference, but more
or less "all things considered...". I can go over cogito and
stgit with Pasky and Catalin and coordinate the transition, but
at the same time, everybody's existing scripts need to be
adjusted. As Linus said, we broke kernel.org snapshot scripts
number of times.
Also places we execute git-upload-pack and git-receive-pack over
an SSH connection need to be updated to execute 'git' with the
first parameter 'upload-pack' and 'receive-pack' to make sure it
would keep working with older or newer git on the other end.
After all that happens, we can start installing things in
/usr/lib/git/. During the transition, the C rewrite of git
wrapper posted by Andreas Ericsson might help, so I am planning
to merge it before 1.0, after deciding what the right word for
the "path to the rest of git executables" should be.
So let's say 1.0 will ship with all things in /usr/bin/, with
updated docs that explain the situation: (1) the dash form
'git-frotz' is being deprecated, and you are encouraged to spell
it as 'git frotz'; (2) if you want to use the dash form in your
scripts for performance reasons, you need to have something like
PATH="$(git --exec-path):$PATH" at the beginning of your script.
And after some time (say 2 months) we can switch.
I just do not want to wait that long before 1.0.
-- >8 -- cut here -- >8 --
[PATCH] git-prune: prune redundant packs.
---
diff --git a/git-prune.sh b/git-prune.sh
index ef31bd2..aa79807 100755
--- a/git-prune.sh
+++ b/git-prune.sh
@@ -27,3 +27,14 @@ sed -ne '/unreachable /{
}
git-prune-packed $dryrun
+
+redundant=$(git-pack-redundant --all)
+if test "" != "$redundant"
+then
+ if test "" = $dryrun
+ then
+ echo "$redundant" | xargs rm -f
+ else
+ echo rm -f "$redundant"
+ fi
+fiJunio C Hamano wrote:
quoted
quoted
Oh, and we will not be moving things out of /usr/bin/ during 1.0
timeframe.
:( bummer. I do like the elegance of having /usr/bin/git executing
stuff out of /usr/libexec/git.
Bummer here as well. This is not my first preference, but more
or less "all things considered...". I can go over cogito and
stgit with Pasky and Catalin and coordinate the transition, but
at the same time, everybody's existing scripts need to be
adjusted. As Linus said, we broke kernel.org snapshot scripts
number of times.
Also places we execute git-upload-pack and git-receive-pack over
an SSH connection need to be updated to execute 'git' with the
first parameter 'upload-pack' and 'receive-pack' to make sure it
would keep working with older or newer git on the other end.
I've cooked up a patch that takes care of this if;
git daemon
is executed (rather than git-daemon). Otherwise we could just mention in
the docs that git-daemon must be run with the --libdir parameter (or
whatever we decide to call it). If it prepends the libdir to the path
everything will work same as always in the rest of the code so it'll be
a very small change.
After all that happens, we can start installing things in
/usr/lib/git/. During the transition, the C rewrite of git
wrapper posted by Andreas Ericsson might help, so I am planning
to merge it before 1.0,> after deciding what the right word for
the "path to the rest of git executables" should be.
All I really need to finalize it is that name, so It's up to you how
fast you want it. Perhaps we could take a poll?
The suggestions so far come from the threads "git binary directory?" and
"[PATCH] C implementation of the 'git' program" and some I just thought
up. And here are the nominees;
libdir
path
exec-path
Kay Sievers pointed out that libexec is not "LSB conformant" so it might
be going away and is thus not listed.
exec-path was the last suggested name I got from Junio.
The form will be
exec_path=$(prefix)/lib/git-@@VERSION@@
GIT_EXEC_PATH
--exec-path
for Makefile, environment and 'git', respectively. Substitute the
obvious part with whatever you prefer.
So let's say 1.0 will ship with all things in /usr/bin/, with
updated docs that explain the situation: (1) the dash form
'git-frotz' is being deprecated, and you are encouraged to spell
it as 'git frotz'; (2) if you want to use the dash form in your
scripts for performance reasons, you need to have something like
PATH="$(git --exec-path):$PATH" at the beginning of your script.
And after some time (say 2 months) we can switch.
Sounds sensible, although I'm implementing Linus' idea of prepending the
GIT_EXEC_PATH to $PATH so the porcelainish scripts in git-core shouldn't
have to do it. If someone executes git-<script> from command-line I
think it's safe to assume that they've added the exec-path to $PATH
themselves. Someone *might* run
/usr/lib/git-$GIT_VERSION/git-<script>
which should be cautioned against in the documentation.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231