* Re: git cherry unkillable
From: sean @ 2006-01-22 14:51 UTC (permalink / raw)
To: sean; +Cc: arvidjaar, git
In-Reply-To: <BAYC1-PASMTP10435A067270A659801A48AE110@CEZ.ICE>
On Sun, 22 Jan 2006 06:39:04 -0500
sean <seanlkml@sympatico.ca> wrote:
> The attached patch works for me but i'm concerned about it a bit.
Below is a better version that doesn't obscure the proper exit value in the normal
case and exits with 1 if interrupted by the user. It also ensures that the cleanup
isn't executed twice when the script is interrupted.
However, for Bash (at least) none of this is necessary; all the traps could just
be changed to only trap 0 and the cleanup will be executed for all cases. However,
I don't know how compatible that is with other shells. If other shells behave
the same, the best fix is just to strip the 1,2,3 and 15 from each of the existing
trap lines and not bother with the patch given below.
Sean
diff --git a/git-cherry.sh b/git-cherry.sh
index 1a62320..0b2ef1f 100755
--- a/git-cherry.sh
+++ b/git-cherry.sh
@@ -49,7 +49,8 @@ ours=`git-rev-list $ours ^$limit` || exi
tmp=.cherry-tmp$$
patch=$tmp-patch
mkdir $patch
-trap "rm -rf $tmp-*" 0 1 2 3 15
+trap "rm -rf $tmp-*" 0
+trap "exit 1" 1 2 3 15
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 7e67c4e..6ba6339 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -77,7 +77,8 @@ tt)
esac
tmp=.tmp-series$$
-trap 'rm -f $tmp-*' 0 1 2 3 15
+trap "rm -f $tmp-*" 0
+trap "exit 1" 1 2 3 15
series=$tmp-series
commsg=$tmp-commsg
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index f699268..7dc224b 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -38,7 +38,8 @@ peek_repo="$(get_remote_url "$@")"
shift
tmp=.ls-remote-$$
-trap "rm -fr $tmp-*" 0 1 2 3 15
+trap "rm -rf $tmp-*" 0
+trap "exit 1" 1 2 3 15
tmpdir=$tmp-d
case "$peek_repo" in
diff --git a/git-reset.sh b/git-reset.sh
index 6c9e58a..166b635 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -4,7 +4,8 @@ USAGE='[--mixed | --soft | --hard] [<co
. git-sh-setup
tmp=${GIT_DIR}/reset.$$
-trap 'rm -f $tmp-*' 0 1 2 3 15
+trap "rm -f $tmp-*" 0
+trap "exit 1" 1 2 3 15
reset_type=--mixed
case "$1" in
^ permalink raw reply related
* [INFO] new qgit public repo
From: Marco Costalba @ 2006-01-22 11:50 UTC (permalink / raw)
To: git
The public git repository of qgit has been changed to
http://digilander.libero.it/mcostalba/scm/qgit.git
For a while both the old and the new repos will be updated, then the
old one will be removed.
The new archive supports packed objects and is much faster to clone from.
More info at http://digilander.libero.it/mcostalba/#Download
Marco
^ permalink raw reply
* Re: git cherry unkillable
From: sean @ 2006-01-22 11:39 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200601221323.33377.arvidjaar@mail.ru>
On Sun, 22 Jan 2006 13:23:26 +0300
Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> Hash: SHA1
>
> I mistakenly run git cherry on linus tree which was a bit too much for my poor
> old system. Trying to kill (^C) it I got
>
> {pts/0}% git cherry ali1535 linus
> external diff died, stopping at include/linux/sysctl.h.
> external diff died, stopping at drivers/serial/suncore.c.
> diff: /home/bor/tmp/.diff_Y6CvCw: No such file or directory
> diff: /home/bor/tmp/.diff_tBqCCk: No such file or directory
> external diff died, stopping at include/asm-arm/arch-pxa/pxa-regs.h.
> external diff died, stopping at fs/cifs/file.c.
> external diff died, stopping at MAINTAINERS.
> diff: /home/bor/tmp/.diff_P12uX9: No such file or directory
> diff: /home/bor/tmp/.diff_R4v0g0: No such file or directory
> external diff died, stopping at net/ipv4/route.c.
> ....
>
> and it jut goes on. This takes really some time here so ability to stop it
> would be really nice. It still runs with CPU temp rocketing.
>
Ouch yeah, you'd have to explicitly kill -9 from another command line. The
same problem exists in a few other scripts too, although probably none that
can be as long lived as git-cherry.
The attached patch works for me but i'm concerned about it a bit. With this
patch it looks like the signal handler is executed twice; once as normal and
a second time in response to the added "exit" statement. By adding
";trap - 0;exit" it is only executed once, but i'm not sure how universal that
is, and letting it run twice shouldn't be a big deal anyway.
The other minor concern is that exit should maybe return an error value
instead; but that isn't approprirate when handling signal zero. So it
might be better to have a separate trap for signal zero, but in the end
it doesn't seem worth the bother.
Sean
diff --git a/git-cherry.sh b/git-cherry.sh
index 1a62320..a1e4d70 100755
--- a/git-cherry.sh
+++ b/git-cherry.sh
@@ -49,7 +49,7 @@ ours=`git-rev-list $ours ^$limit` || exi
tmp=.cherry-tmp$$
patch=$tmp-patch
mkdir $patch
-trap "rm -rf $tmp-*" 0 1 2 3 15
+trap "rm -rf $tmp-*;exit" 0 1 2 3 15
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 7e67c4e..38adaad 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -77,7 +77,7 @@ tt)
esac
tmp=.tmp-series$$
-trap 'rm -f $tmp-*' 0 1 2 3 15
+trap 'rm -f $tmp-*;exit' 0 1 2 3 15
series=$tmp-series
commsg=$tmp-commsg
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index f699268..ba96969 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -38,7 +38,7 @@ peek_repo="$(get_remote_url "$@")"
shift
tmp=.ls-remote-$$
-trap "rm -fr $tmp-*" 0 1 2 3 15
+trap "rm -fr $tmp-*;exit" 0 1 2 3 15
tmpdir=$tmp-d
case "$peek_repo" in
diff --git a/git-reset.sh b/git-reset.sh
index 6c9e58a..1b6781f 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -4,7 +4,7 @@ USAGE='[--mixed | --soft | --hard] [<co
. git-sh-setup
tmp=${GIT_DIR}/reset.$$
-trap 'rm -f $tmp-*' 0 1 2 3 15
+trap 'rm -f $tmp-*;exit' 0 1 2 3 15
reset_type=--mixed
case "$1" in
^ permalink raw reply related
* git cherry unkillable
From: Andrey Borzenkov @ 2006-01-22 10:23 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I mistakenly run git cherry on linus tree which was a bit too much for my poor
old system. Trying to kill (^C) it I got
{pts/0}% git cherry ali1535 linus
external diff died, stopping at include/linux/sysctl.h.
external diff died, stopping at drivers/serial/suncore.c.
diff: /home/bor/tmp/.diff_Y6CvCw: No such file or directory
diff: /home/bor/tmp/.diff_tBqCCk: No such file or directory
external diff died, stopping at include/asm-arm/arch-pxa/pxa-regs.h.
external diff died, stopping at fs/cifs/file.c.
external diff died, stopping at MAINTAINERS.
diff: /home/bor/tmp/.diff_P12uX9: No such file or directory
diff: /home/bor/tmp/.diff_R4v0g0: No such file or directory
external diff died, stopping at net/ipv4/route.c.
....
and it jut goes on. This takes really some time here so ability to stop it
would be really nice. It still runs with CPU temp rocketing.
Regards
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD010lR6LMutpd94wRArDIAKC4yNPpwZ2AEKpXwjeZREMRCL3VyACeJaYu
UMZUpX3D3UfHSm0m44pvAmY=
=0Cxg
-----END PGP SIGNATURE-----
^ permalink raw reply
* [ANNOUNCE] Stacked GIT 0.8.1
From: Catalin Marinas @ 2006-01-22 10:20 UTC (permalink / raw)
To: git
Stacked GIT 0.8.1 release is available from http://www.procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
This is a bug-fix release:
- Fix the removal vs. change merging conflict
- 'clone' command fixed
- 'status --reset <file>' command fixed
- typos corrected
Acknowledgements (generated with 'git shortlog'):
Catalin Marinas:
Fix the clone command failure
Fix the 'status --reset' for individual files
Release 0.8.1
Kirill Smelkov:
[trivial] fix spelling typos
Paolo 'Blaisorblade' Giarrusso:
Stgit - gitmergeonefile.py: handle removal vs. changes
Pavel Roskin:
stgit: typo fixes
--
Catalin
^ permalink raw reply
* Re: StGIT: "stg new" vs "stg new --force"
From: Pavel Roskin @ 2006-01-22 5:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, git, Charles Lever
In-Reply-To: <b0943d9e0601211024s76528ce8m@mail.gmail.com>
Hello, Catalin!
Quoting Catalin Marinas <catalin.marinas@gmail.com>:
> On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:
> > I think if would be better to improve "stg fold" to work on arbitrary
> > patches. This way, you prepare the patch in the editor (which would not
> > be harder than finding hunk numbers) and fold it into the patch of your
> > choice. stg should check that the stack remains valid, possibly doing
> > trivial adjustments to the higher patches. The current tree should not
> > be impacted.
>
> Note that 'stg fold' uses git-apply-patch which doesn't take fuzzy
> patches (a feature I began to like actually). Modifying the patch in
> an editor might create some problems with applying.
Actually, the safest way would be to keep the original patch as presented to the
user. Then the new patch would be "subtracted" from the original patch (using
e.g. interdiff from diff-utils). The the difference would be "added" to the
current version of the patch. Changes to "binary files differ" and similar
line should be ignored. This way, changes to binary files are preserved.
For additional safety (and at expense or concurrency), it could be required that
the patch is unchanged since the editor was launched. Editors tend to run for
a long time compared to non-interactive utilities.
Fuzziness should be tolerated to a point. Removing hunks could mean that the
line numbers would be slightly off. If needed, the patch should be applied to
a temporary copy and regenerated from it.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] git-count-objects --all support
From: Junio C Hamano @ 2006-01-22 3:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060122030215.GT28365@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> The point of counting objects is to see if it is time to repack,
>> so the warning is something I am quite hesitant to accept, even
>> with a suppression option.
>
> Then please change the command name - it is very confusing this way;
True. count-loose-objects would have been a good name, if it
were named that way from the beginning.
^ permalink raw reply
* Re: [PATCH] git-{fetch,peek-remote} handling of --upload-pack
From: Junio C Hamano @ 2006-01-22 3:41 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: git
In-Reply-To: <E1F019M-0003Cf-Ln@heater.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> git-peek-remote needs to handle a -u|--upload-pack parameter just like
> git-fetch (and git-fetch has to pass it on to git-peek-remote).
>
> (This is actually a follow-up to my previous git-fetch patch.)
Thanks.
Everything else looks good, but I have one question. What is
this hunk about?
> diff --git a/git-ls-remote.sh b/git-ls-remote.sh
> index f699268..64f37af 100755
> --- a/git-ls-remote.sh
> +++ b/git-ls-remote.sh
>...
> @@ -34,7 +41,7 @@ case ",$heads,$tags," in
> esac
>
> . git-parse-remote
> -peek_repo="$(get_remote_url "$@")"
> +peek_repo="$(get_remote_url $*)"
> shift
>
> tmp=.ls-remote-$$
^ permalink raw reply
* Re: [PATCH] Mention install-doc in INSTALL
From: Junio C Hamano @ 2006-01-22 3:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: J. Bruce Fields, git
In-Reply-To: <20060122001255.GR28365@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> But you really do not want to build the documentation as root.
True.
> Cogito's "solution" is:
>
> + - By default, separate documentation (manpages, text, HTML) is not built
> + since it requires asciidoc and xmlto, and those tools are not so common.
That's cheating ;-), but I cannot blame you.
I'll push out this hopefully tonight.
---
From: J. Bruce Fields <bfields@fieldses.org>
Date: Sat Jan 21 18:54:12 2006 -0500
[PATCH] Mention install-doc in INSTALL
I think most people will want to install the man pages as well.
[jc: incorporated Pasky's comment on not building them as root.
Some people may not want to install asciidoc/xmlto toolchain, so
redirect them to the man and html branches of the git.git
repository as well.]
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
INSTALL | 28 ++++++++++++++++++++++++++--
1 files changed, 26 insertions(+), 2 deletions(-)
eff351c957975055643f2e1359652ab3aac30256
diff --git a/INSTALL b/INSTALL
index 916ddd4..433449f 100644
--- a/INSTALL
+++ b/INSTALL
@@ -5,8 +5,8 @@ Normally you can just do "make" followed
will install the git programs in your own ~/bin/ directory. If you want
to do a global install, you can do
- $ make prefix=/usr ;# as yourself
- # make prefix=/usr install ;# as root
+ $ make prefix=/usr all doc ;# as yourself
+ # make prefix=/usr install install-doc ;# as root
(or prefix=/usr/local, of course). Just like any program suite
that uses $prefix, the built results have some paths encoded,
@@ -90,3 +90,27 @@ Issues of note:
You can place local settings in config.mak and the Makefile
will include them. Note that config.mak is not distributed;
the name is reserved for local settings.
+
+ - To build and install documentation suite, you need to have the
+ asciidoc/xmlto toolchain. Alternatively, pre-formatted
+ documentation are available in "html" and "man" branches of the git
+ repository itself. For example, you could:
+
+ $ mkdir manual && cd manual
+ $ git init-db
+ $ git clone-pack git://git.kernel.org/pub/scm/git/git.git man html |
+ while read a b
+ do
+ echo $a >.git/$b
+ done
+ $ cp .git/refs/heads/man .git/refs/heads/master
+ $ git checkout
+
+ to checkout the pre-built man pages. Also in this repository:
+
+ $ git checkout html
+
+ would instead give you a copy of what you see at:
+
+ http://www.kernel.org/pub/software/scm/git/docs/
+
--
1.1.4.g73f3
^ permalink raw reply related
* Re: What is in git.git
From: Petr Baudis @ 2006-01-22 3:12 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git
In-Reply-To: <200601220033.26321.Josef.Weidendorfer@gmx.de>
Just-in-case panic response...
Dear diary, on Sun, Jan 22, 2006 at 12:33:25AM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > You need to keep a file that describes how your repository is
> > tracking the development histories of each subproject in
> > $GIT_DIR/bind, that would look like:
> >
> > master main=/ subpro=sub/
>
> What about putting $GITDIR/bind information directly into reference files?
>
> $HOME/gitproj> cat .git/refs/heads/master
> 92347432598...
> bind main=/
> bind subpro=sub/
>
> This way, you can rename/copy heads, and the binding info will stay with
> the commit.
Please don't. I can see no real advantage to separate files (except for
the very rare case of rename/copy/removal of heads) except for massive
porcelain breakage and significant clutter-up of all the code dealing
with refs.
Please leave our poor refs alone. :) They are fine as they are - simple
one-value thing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] git-count-objects --all support
From: Junio C Hamano @ 2006-01-22 3:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vslrhht8b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The point of counting objects is to see if it is time to repack,
> so the warning is something I am quite hesitant to accept, even
> with a suppression option. The other way around is probably OK
> ("please warn me if I have packs"), but feels somewhat pointless.
>
> The --all option might be a welcome addition, though.
I think your patch counts the same object twice if it is packed
in more than one packs and/or it has a loose copy _and_ also in
a pack. If it is a good thing or not is totally up to the
reason why we are counting.
We might be better off if we did this kind of additions by
building on fsck-objects. For example, you could give a --stat
option that might say something like this:
$ git fsck-objects --full --stat
commit 2488
tree 43343
blob 212234
total 258065
packed 184382
loose 78115
dups 4432
where "dups" is number of duplicated copies --- an object packed
in more than two packs, or appearing in a pack and also having a
loose copy. I dunno.
^ permalink raw reply
* Re: [PATCH] git-count-objects --all support
From: Petr Baudis @ 2006-01-22 3:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslrhht8b.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jan 22, 2006 at 03:49:40AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Having command called "git-count-objects" count only unpacked objects is
> > a little strange and confusing. This patch adds a warning if packs are
> > already present in the current repository,
>
> The point of counting objects is to see if it is time to repack,
> so the warning is something I am quite hesitant to accept, even
> with a suppression option.
Then please change the command name - it is very confusing this way;
I've been "burnt" (well, no big deal but wrong numbers, but anyway...)
multiple times and I know others who were as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] Add git-pack-ls-objects tool
From: Petr Baudis @ 2006-01-22 3:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmlphtct.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jan 22, 2006 at 03:46:58AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > This tool takes pack index on stdin and produces the list of indexed
> > objects on stdout.
>
> Isn't this essentially what git-show-index does?
Yes, I just had no idea this existed. ;)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] git-count-objects --all support
From: Junio C Hamano @ 2006-01-22 2:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060122022718.16375.78611.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Having command called "git-count-objects" count only unpacked objects is
> a little strange and confusing. This patch adds a warning if packs are
> already present in the current repository,
The point of counting objects is to see if it is time to repack,
so the warning is something I am quite hesitant to accept, even
with a suppression option. The other way around is probably OK
("please warn me if I have packs"), but feels somewhat pointless.
The --all option might be a welcome addition, though.
^ permalink raw reply
* Re: [PATCH] Add git-pack-ls-objects tool
From: Junio C Hamano @ 2006-01-22 2:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060122022711.16333.93404.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> This tool takes pack index on stdin and produces the list of indexed
> objects on stdout.
Isn't this essentially what git-show-index does?
^ permalink raw reply
* Re: What is in git.git
From: Junio C Hamano @ 2006-01-22 2:44 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200601220033.26321.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> The original gitlink proposal did exactly this: it recorded
> the place where a subproject is bound by putting a gitlink into
> a tree. This way, the binding point can be changed, and is subject to
> versioning itself.
>
> I just realized that this is not currently possible with the bind lines.
> What about the following usage szenario:
> - in a superproject, I use a subproject X implementing some lib by
> binding it at X/. My Makefile recurses into X/ for this.
> This is recorded at commit point (A)
> - later on, I realize I need another lib from a probject Y; I want
> to put the libs X and Y into subdirectory lib/ of my superproject;
> i.e. I bind Y at lib/Y/ and move the binding point of X to lib/X/.
> The Makefile is changed accordingly to build the subprojects.
> This is recorded at commit point (B)
The original gitlink proposal records commit object name in the
link object itself, so do bind lines in the commit object in
bound commit proposal. In either way, you need to deal with the
subproject relocation at the Porcelain level.
I was hoping that, upon seeing these two commits (let's say we
are dealing with two-way merge aka "checkout"):
In commit 1:
bind xxxxx... X/
In commit 2:
bind yyyyy... lib/X/
bind zzzzz... lib/Y/
the tool could notice that xxxxx... and yyyyy... are related in
their ancestry chain, detect the relocation of subprojects, and
update the $GIT_DIR/bind file (maybe with some help from the end
user). We can do something similar in gitlink approach as well.
> A $GITDIR/bind alone will no work, as moving back to (A) would keep
> the binding point of subproject, and make is broken.
I do not see why. $GIT_DIR/bind can be adjusted by the tool
upon checkout to reflect the reorganized tree.
> What about putting $GITDIR/bind information directly into reference files?
>
> $HOME/gitproj> cat .git/refs/heads/master
> 92347432598...
> bind main=/
> bind subpro=sub/
I think that would also work. Although I do not immediately see
major difference in expressiveness either way, that may be a
cleaner way to achieve what we want to do.
^ permalink raw reply
* [PATCH] git-count-objects --all support
From: Petr Baudis @ 2006-01-22 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Having command called "git-count-objects" count only unpacked objects is
a little strange and confusing. This patch adds a warning if packs are
already present in the current repository, an --unpacked argument to
suppress the warning, and an --all argument to count even packed objects
(useful at least for statistics).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-count-objects.txt | 9 ++++----
git-count-objects.sh | 41 ++++++++++++++++++++++++++++++++---
2 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index 36888d9..105721b 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -3,16 +3,17 @@ git-count-objects(1)
NAME
----
-git-count-objects - Reports on unpacked objects.
+git-count-objects - Reports on objects count.
SYNOPSIS
--------
-'git-count-objects'
+'git-count-objects' [--unpacked | --all]
DESCRIPTION
-----------
-This counts the number of unpacked object files and disk space consumed by
-them, to help you decide when it is a good time to repack.
+This counts the number of objects and disk space consumed by them.
+It by default counts only unpacked objects in order to help you decide
+when it is a good time to repack.
Author
------
diff --git a/git-count-objects.sh b/git-count-objects.sh
index 40c58ef..986ff14 100755
--- a/git-count-objects.sh
+++ b/git-count-objects.sh
@@ -3,7 +3,8 @@
# Copyright (c) 2005 Junio C Hamano
#
-GIT_DIR=`git-rev-parse --git-dir` || exit $?
+USAGE='[--unpacked | --all]'
+. git-sh-setup
dc </dev/null 2>/dev/null || {
# This is not a real DC at all -- it just knows how
@@ -20,12 +21,44 @@ dc </dev/null 2>/dev/null || {
}
}
-echo $(find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l) objects, \
+all= unpacked=
+while case "$#" in 0) break;; esac
+do
+ case "$1" in
+ -a|--a|--al|--all)
+ all=t
+ shift ;;
+ -u|--u|--un|--unp|--unpa|--unpac|--unpack|--unpacke|--unpacked)
+ unpacked=t
+ shift ;;
+ *)
+ usage ;;
+ esac
+done
+
+has_packs=
+test -d "$GIT_DIR/objects/pack" && test -n "$(ls "$GIT_DIR/objects/pack")" &&
+ has_packs=objects/pack
+test -n "$has_packs" && test -z "$all" && test -z "$unpacked" &&
+ echo "Warning: Ignoring packed objects"
+test -z "$all" &&
+ has_packs=
+
+
+objcount=$(find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l)
+test -n "$has_packs" && for pack in "$GIT_DIR/objects/pack"/*.idx; do
+ objcount=$((objcount+$(git-pack-ls-objects <"$pack" 2>/dev/null | wc -l)))
+done
+
+echo $objcount objects, \
$({
echo 0
+
+ cd "$GIT_DIR"
# "no-such" is to help Darwin folks by not using xargs -r.
- find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null |
- xargs du -k "$GIT_DIR/objects/no-such" 2>/dev/null |
+ find objects/?? $has_packs -type f -print 2>/dev/null |
+ xargs du -k "objects/no-such" 2>/dev/null |
sed -e 's/[ ].*/ +/'
+
echo p
} | dc) kilobytes
^ permalink raw reply related
* [PATCH] Add git-pack-ls-objects tool
From: Petr Baudis @ 2006-01-22 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This tool takes pack index on stdin and produces the list of indexed
objects on stdout.
Very simple, but I've been always somewhat nervous that I cannot list
all (even unreferenced) objects in a repository, and in a given pack in
particular. The immediate use will be in the git-count-objects script,
but I can imagine it being useful also in various troubleshooting
situations.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-pack-ls-objects.txt | 32 ++++++++++++++++++++++++++++++++
Makefile | 2 +-
pack-ls-objects.c | 31 +++++++++++++++++++++++++++++++
3 files changed, 64 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-pack-ls-objects.txt b/Documentation/git-pack-ls-objects.txt
new file mode 100644
index 0000000..bf2a4a4
--- /dev/null
+++ b/Documentation/git-pack-ls-objects.txt
@@ -0,0 +1,32 @@
+git-pack-ls-objects(1)
+======================
+
+NAME
+----
+git-pack-ls-objects - List objects in a pack based on its index
+
+
+SYNOPSIS
+--------
+'git-pack-ls-objects' < pack-index
+
+
+DESCRIPTION
+-----------
+Reads a packed archive index (.idx) from its standard input and
+produces the list of indexed objects (that is, the objects packed
+in the corresponding .pack file) on its standard output.
+
+
+Author
+------
+Written by Petr Baudis <pasky@suse.cz>
+
+Documentation
+-------------
+Documentation by Petr Baudis
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index a291bb1..7c54507 100644
--- a/Makefile
+++ b/Makefile
@@ -143,7 +143,7 @@ PROGRAMS = \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
- git-describe$X
+ git-describe$X git-pack-ls-objects$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
diff --git a/pack-ls-objects.c b/pack-ls-objects.c
new file mode 100644
index 0000000..caee59c
--- /dev/null
+++ b/pack-ls-objects.c
@@ -0,0 +1,31 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Petr Baudis, 2006
+ */
+
+#include <stdio.h>
+#include "cache.h"
+
+static const char pack_usage[] = "git-pack-ls-objects < pack-idx";
+
+int main(int argc, char **argv)
+{
+ unsigned char buf[1024];
+ unsigned char entry[24];
+
+ if (argc > 1)
+ usage(pack_usage);
+
+ /* We are doing these charades because we do not want to print
+ * the last sha1. */
+
+ if (!fread(buf, 256 * 4, 1, stdin) || !fread(entry, 24, 1, stdin))
+ die("invalid pack index");
+
+ while (fread(buf, 24, 1, stdin)) {
+ printf("%s\n", sha1_to_hex(entry + 4));
+ memcpy(entry, buf, 24);
+ }
+ return 0;
+}
^ permalink raw reply related
* [PATCH] Document git-ls-files --directory
From: Petr Baudis @ 2006-01-22 0:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Add the appropriate bit of documentation.
I did not review GIT patches for missing documentation updates during
Christmas and around the New Year, but I guess that I will have to start
again. ;-)
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-ls-files.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index e42af5e..e433407 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -46,6 +46,10 @@ OPTIONS
-s|--stage::
Show stage files in the output
+--directory::
+ If a whole directory is classified as "other", show just its
+ name (with a trailing slash) and not its whole contents.
+
-u|--unmerged::
Show unmerged files in the output (forces --stage)
^ permalink raw reply related
* Re: [PATCH] Mention install-doc in INSTALL
From: Petr Baudis @ 2006-01-22 0:12 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <E1F0SYe-0005ix-WB@puzzle.fieldses.org>
Dear diary, on Sun, Jan 22, 2006 at 12:54:12AM CET, I got a letter
where "J. Bruce Fields" <bfields@fieldses.org> said that...
> I think most people will want to install the man pages as well.
>
> (I'm less sure about the case of the home directory, as I assume there's
> unlikely to be a reasonable place to install man pages to in that case.)
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
But you really do not want to build the documentation as root.
Cogito's "solution" is:
diff --git a/INSTALL b/INSTALL
index 916ddd4..464bfbb 100644
--- a/INSTALL
+++ b/INSTALL
@@ -90,3 +90,10 @@ Issues of note:
You can place local settings in config.mak and the Makefile
will include them. Note that config.mak is not distributed;
the name is reserved for local settings.
+
+ - By default, separate documentation (manpages, text, HTML) is not built
+ since it requires asciidoc and xmlto, and those tools are not so common.
+ You can build it by "make doc" and install it later by "make install-doc"
+ in the project root, or you can build directly in the "Documentation/"
+ subdirectory, where you can also choose to build only documentation in
+ particular format. See Documentation/Makefile for further details.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply related
* [PATCH] Mention install-doc in INSTALL
From: J. Bruce Fields @ 2006-01-21 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I think most people will want to install the man pages as well.
(I'm less sure about the case of the home directory, as I assume there's
unlikely to be a reasonable place to install man pages to in that case.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
INSTALL | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
81333d4427d75d039c6b5b5bd3c5b71e236ff187
diff --git a/INSTALL b/INSTALL
index 916ddd4..6fb826a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -6,7 +6,7 @@ will install the git programs in your ow
to do a global install, you can do
$ make prefix=/usr ;# as yourself
- # make prefix=/usr install ;# as root
+ # make prefix=/usr install install-doc ;# as root
(or prefix=/usr/local, of course). Just like any program suite
that uses $prefix, the built results have some paths encoded,
--
0.99.8b-g58e3
^ permalink raw reply related
* [PATCH] minor git-reset and git-commit documentation fixes
From: J. Bruce Fields @ 2006-01-21 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Minor copyediting of recent additions to git-commit and git-reset documentation
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-commit.txt | 2 +-
Documentation/git-reset.txt | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
18d55bf231ae7116e0f0c4da144de46fe0cb2cbf
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e35984d..72f96fc 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -27,7 +27,7 @@ OPTIONS
-a|--all::
Update all paths in the index file. This flag notices
files that have been modified and deleted, but new files
- you have not told about git are not affected.
+ you have not told git about are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 315683a..b4e737e 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -147,8 +147,8 @@ and resets the tip of the branch to that
Interrupted workflow::
+
-You can get interrupted by an ungent fix request while you are
-still in the middle of a large change. The files in your
+Suppose you are interrupted by an urgent fix request while you
+are in the middle of a large change. The files in your
working tree are not in any shape to be committed yet, but you
need to get to the other branch for a quick bugfix.
+
@@ -164,8 +164,8 @@ $ git reset --soft HEAD^ ;# go back to W
$ git reset <3>
<1> This commit will get blown away so a throw-away log message is OK.
-<2> This removes the 'WIP' commit from the commit history, and makes
- your working tree in the state just before you made that snapshot.
+<2> This removes the 'WIP' commit from the commit history, and sets
+ your working tree to the state just before you made that snapshot.
<3> After <2>, the index file still has all the WIP changes you
committed in <1>. This sets it to the last commit you were
basing the WIP changes on.
--
0.99.8b-g58e3
^ permalink raw reply related
* Re: What is in git.git
From: Josef Weidendorfer @ 2006-01-21 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek31mkyg.fsf@assigned-by-dhcp.cox.net>
On Saturday 21 January 2006 20:37, you wrote:
> Alexander Litvinov <lan@ac-sw.com> writes:
> >> 1. Can I bind some branch instead of tag (commit) ?
> ...
> If you mean by "binding a branch", to record how each subproject
> relates to the toplevel project (i.e. "the subproject bound to
> X/ subdirectory of the toplevel project comes from branch Y"),
> that information needs to be somewhere, but recording it in the
> commit object goes against the whole git philosophy.
The original gitlink proposal did exactly this: it recorded
the place where a subproject is bound by putting a gitlink into
a tree. This way, the binding point can be changed, and is subject to
versioning itself.
I just realized that this is not currently possible with the bind lines.
What about the following usage szenario:
- in a superproject, I use a subproject X implementing some lib by
binding it at X/. My Makefile recurses into X/ for this.
This is recorded at commit point (A)
- later on, I realize I need another lib from a probject Y; I want
to put the libs X and Y into subdirectory lib/ of my superproject;
i.e. I bind Y at lib/Y/ and move the binding point of X to lib/X/.
The Makefile is changed accordingly to build the subprojects.
This is recorded at commit point (B)
A $GITDIR/bind alone will no work, as moving back to (A) would keep
the binding point of subproject, and make is broken.
I understand that "moving binding point of X from X/ to lib/X/" is not
representable within the index as a simple change. Is this the main issue
for your "against the whole git philosophy"?
I think it still is quite useful to put the binding point into bind lines of the
commit. Of course, moving a binding point has to go together with a new commit.
> You need to keep a file that describes how your repository is
> tracking the development histories of each subproject in
> $GIT_DIR/bind, that would look like:
>
> master main=/ subpro=sub/
What about putting $GITDIR/bind information directly into reference files?
$HOME/gitproj> cat .git/refs/heads/master
92347432598...
bind main=/
bind subpro=sub/
This way, you can rename/copy heads, and the binding info will stay with
the commit.
This also is nice for subprojects that do not need the bind lines, but similar
to current cogito subproject proposal:
92347432598...
main=/
subpro=sub/
would be the same superproject/subproject configuration without commiting
bind lines.
Josef
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Andrey Borzenkov @ 2006-01-21 23:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060121200615.GM28365@pasky.or.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 21 January 2006 23:06, Petr Baudis wrote:
> Dear diary, on Sat, Jan 21, 2006 at 08:58:55PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>
> > You might be able to cauterize the history at a specific commit
> > and then re-clone. I've talked about how in "[QUESTION] about
> > .git/info/grafts file" thread yesterday, so I won't repeat that.
>
> Shouldn't the git-prune be sufficient after cauterizing the history?
this did not work for me, at least applied naively. May be, it is due to the
way I setup repository - first I created local version from 2.6.15 tree and
then pulled in remote one.
Anyway repacking and pruning resulted in over 500MB size reduction so its OK
for me so far. I'll probably try fetching cleanly later.
thank you and best regards
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD0sN8R6LMutpd94wRAt1WAKC18LjAl+MbyfmvSvvNQGUF/mlbIgCfcu6s
nuZtYttRsd673Yqlq3aKr+A=
=B6jN
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: What is in git.git
From: Junio C Hamano @ 2006-01-21 22:22 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <7vek31mkyg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Alexander Litvinov <lan@ac-sw.com> writes:
>...
>> subpro and main are separate projects and master is the join
>> of them. If I want to modify subpro I have to checkout subpro
>> branch, edit files. When I have to got to master and bind new
>> version of subpro to it.
>
> I do not see any problem with this....
>...
>> Worse, if I will edit subpro's files bined to master branch
>> changes will go to master branch instead of subpro's history.
>
> Simply untrue.
Sorry, these came out somewhat in a wrong way, so let me
clarify.
What I meant was that there isn't anything coded so far that
makes your worries real issues yet, and I do not intend to code
Porcelainish scripts that are broken in the ways you see as
problems in your message.
The point you raised are valid concerns. You need to keep them
in mind when you start writing subproject aware version of
git-checkout, git-commit and git-merge commands (among other
things I might have forgotten, but I think these three covers
pretty much everything). You are welcome to beat me to it,
since I am not planning to do them right away.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox