* Re: RFC: German translation vocabulary
From: David Kastrup @ 2007-09-17 12:42 UTC (permalink / raw)
To: git
In-Reply-To: <20070917075433.GF17021@cip.informatik.uni-erlangen.de>
Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de> writes:
> On 070916 23:34, David Kastrup <dak@gnu.org> wrote:
>> Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de> writes:
>>
>> > On 070916 14:46, Christian Stimming <stimming@tuhh.de> wrote:
>> >> msgid "commit [noun]"
>> >> msgstr "?bertragung (Sendung?, ?bergabe?, Einspielung?, Ablagevorgang?)"
>> >
>> > "Vorgang"? (think Beamtendeutsch)
>>
>> Buchung, Einbuchung, Verbuchung, Registrierung?
>
> Transaktion?
Well, I might be biased against anything not from myself, but
"Transaktion" is anything with a permanent effect, so I find this term
too unspecific: it would equally well cover resetting, tagging,
and a number of other things.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Andreas Ericsson @ 2007-09-17 12:39 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <11900314321506-git-send-email-hjemli@gmail.com>
Lars Hjemli wrote:
> This new option forces all merges to create a "true" merge commit, i.e. a
> commit with multiple parents.
>
> Although a fast-forward would normally be The Right Thing, it isn't when the
> branches to be merged originated in subversion and the merge commit will
> be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> forward merge simply will not work.
>
> If there is no `-s` option, a built-in list of strategies
> is used instead (`git-merge-recursive` when merging a single
> head, `git-merge-octopus` otherwise).
> +
> +--no-ff::
> + Force the creation of a merge commit even when the merge would
> + have resolved as a fast-forward operation.
+ Although a fast-forward would normally be The Right Thing, it isn't when the
+ branches to be merged originated in subversion and the merge commit will
+ be pushed back by means of 'git svn dcommit'. In these cases, a fast-
+ forward merge simply will not work.
Otherwise someone will sit down and try to figure out why this is necessary.
I'm having trouble understanding why this is needed, but I'll take your word
for it ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-17 12:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This new option forces all merges to create a "true" merge commit, i.e. a
commit with multiple parents.
Although a fast-forward would normally be The Right Thing, it isn't when the
branches to be merged originated in subversion and the merge commit will
be pushed back by means of 'git svn dcommit'. In these cases, a fast-
forward merge simply will not work.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/merge-options.txt | 4 ++++
git-merge.sh | 13 +++++++++++--
t/t6028-merge-up-to-date.sh | 25 +++++++++++++++++++++++++
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index d64c259..ed28017 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -25,3 +25,7 @@
If there is no `-s` option, a built-in list of strategies
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise).
+
+--no-ff::
+ Force the creation of a merge commit even when the merge would
+ have resolved as a fast-forward operation.
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..13b98e6 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -165,6 +165,10 @@ do
merge_msg="$1"
have_message=t
;;
+ --no-ff)
+ no_ff=t
+ no_fast_forward_strategies=$all_strategies
+ ;;
-*) usage ;;
*) break ;;
esac
@@ -444,7 +448,12 @@ done
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ if test $no_ff = 't'
+ then
+ parents=$(git rev-parse "$head" "$@" | sed -e 's/^/-p /')
+ else
+ parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ fi
result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge made by $wt_strategy."
dropsave
diff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh
index f8f3e3f..afd74e2 100755
--- a/t/t6028-merge-up-to-date.sh
+++ b/t/t6028-merge-up-to-date.sh
@@ -10,12 +10,14 @@ test_expect_success setup '
test_tick &&
git commit -m initial &&
git tag c0 &&
+ c0=$(git rev-parse c0)
echo second >file &&
git add file &&
test_tick &&
git commit -m second &&
git tag c1 &&
+ c1=$(git rev-parse c1)
git branch test
'
@@ -41,6 +43,16 @@ test_expect_success 'merge -s recursive fast-forward' '
'
+test_expect_success 'merge -s recursive --no-ff' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge -s recursive --no-ff c1 &&
+ test $c0 = $(git rev-parse HEAD^1) &&
+ test $c1 = $(git rev-parse HEAD^2)
+
+'
+
test_expect_success 'merge -s ours up-to-date' '
git reset --hard c1 &&
@@ -63,6 +75,19 @@ test_expect_success 'merge -s ours fast-forward' '
'
+test_expect_success 'merge -s ours --no-ff' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge -s ours --no-ff c1 &&
+ expect=$(git rev-parse c0^{tree}) &&
+ current=$(git rev-parse HEAD^{tree}) &&
+ test "$expect" = "$current" &&
+ test $c0 = $(git rev-parse HEAD^1) &&
+ test $c1 = $(git rev-parse HEAD^2)
+
+'
+
test_expect_success 'merge -s subtree up-to-date' '
git reset --hard c1 &&
--
1.5.3.1.92.g2f5e
^ permalink raw reply related
* Re: [PATCH] instaweb: support for Ruby's WEBrick server
From: Florian Weimer @ 2007-09-17 12:25 UTC (permalink / raw)
To: Thomas Adam; +Cc: Eric Wong, Mike Dalessio, git
In-Reply-To: <18071eea0709170502s397331c5j7d77aa9531f73704@mail.gmail.com>
* Thomas Adam:
> This is what /usr/bin/env is useful for, but it's not that portable.
Yeah, it's /bin/env exclusively on some systems. 8-(
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* Re: [PATCH] instaweb: support for Ruby's WEBrick server
From: Thomas Adam @ 2007-09-17 12:02 UTC (permalink / raw)
To: Eric Wong; +Cc: Mike Dalessio, git
In-Reply-To: <20070917115518.GA26815@soma>
On 17/09/2007, Eric Wong <normalperson@yhbt.net> wrote:
> Could we make the shebang dynamic? (capturing the output of `which ruby`
> maybe, or just breaking down and using /usr/bin/env ruby). The ruby
> binary seems to appear all over the place on the filesystem from my
> experience, especially with its popularity amongst OSX users.
This is what /usr/bin/env is useful for, but it's not that portable.
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH] instaweb: support for Ruby's WEBrick server
From: Eric Wong @ 2007-09-17 11:55 UTC (permalink / raw)
To: Mike Dalessio; +Cc: git
In-Reply-To: <618c07250709161935g333f0536q31b453bd58f2d75d@mail.gmail.com>
Mike Dalessio <mike@csa.net> wrote:
> running the webrick server with git requires Ruby and Ruby's YAML and
> Webrick libraries (both of which come standard with Ruby). nice for
> single-user standalone invocations.
>
> the --httpd=webrick option generates a (short!) ruby script on the fly to
> read httpd.conf options and invoke the web server via library call. this
> script is placed in the .git/gitweb directory.
Nice. I'm in favor of adding WEBrick since it's fairly commonly
installed on developer boxes and is more consistently available
if available at all. Apache and lighttpd may not be compiled
with some modules we need.
I'm having trouble applying this patch, however. It's
whitespace-mangled and using long lines doesn't help mailers much.
> Signed-off-by: Mike Dalessio <mike.dalessio@gmail.com>
> ---
> Documentation/git-instaweb.txt | 3 ++-
> git-instaweb.sh | 29 ++++++++++++++++++++++++++++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> +webrick_conf () {
> + # generate a standalone server script in $fqgitdir/gitweb.
> + cat > "$fqgitdir/gitweb/$httpd" <<EOF
> +#! /usr/bin/ruby
Could we make the shebang dynamic? (capturing the output of `which ruby`
maybe, or just breaking down and using /usr/bin/env ruby). The ruby
binary seems to appear all over the place on the filesystem from my
experience, especially with its popularity amongst OSX users.
--
Eric Wong
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Jeff King @ 2007-09-17 11:42 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20070917112136.GA30201@glandium.org>
On Mon, Sep 17, 2007 at 01:21:36PM +0200, Mike Hommey wrote:
> ... and I happen to not have done the "followed by a blank line" part.
If this isn't a published repo, you can fix it with filter-branch:
git filter-branch --msg-filter 'sed "1a
"'
> Now, git log --pretty=oneline (for instance), shows me the full commit
> message on one line, which is not really what I would expect...
>
> On the other hand, and that's how I got trapped into this, gitweb and
> gitk only display the first line, be it followed by a blank line or not.
This was changed recently for git-log and company, but gitk and gitweb
have not followed suit. Traditionally, the behavior was to take the
first line. This was changed in 4234a761 to take the first paragraph.
The rationale was that people without the nice one-line summaries are
typically importing old histories, and the paragraph makes a much more
sensible summary (as opposed to cutting off the summary in
mid-sentence).
> So, IMHO, there would be 2 solutions:
> - either change --pretty=oneline,short and other similar things to take
> only the first line and change the git-commit manpage (and whenever
> else this might be written)
> - or change gitweb, gitk and any other tool that would only take the
> first line so that it takes the same summary as --pretty=oneline.
>
> What do you think ?
It depends on whether people like the new behavior. I think it is more
sensible in every case _except_ the one you have mentioned, but your
case is hopefully somewhat rare (though it just made it to the public in
1.5.3, so yours might be the first of many comments).
I do agree that it makes sense for all of the tools to be consistent.
-Peff
^ permalink raw reply
* commit summary, --pretty=short and other tools
From: Mike Hommey @ 2007-09-17 11:21 UTC (permalink / raw)
To: git
Hi,
I kind of shot myself in the foot with how to type proper commit
messages.
The git-commit manual page reads:
Though not required, it´s a good idea to begin the commit message with a
single short (less than 50 character) line summarizing the change,
followed by a blank line and then a more thorough description.
... and I happen to not have done the "followed by a blank line" part.
Now, git log --pretty=oneline (for instance), shows me the full commit
message on one line, which is not really what I would expect...
On the other hand, and that's how I got trapped into this, gitweb and
gitk only display the first line, be it followed by a blank line or not.
So, IMHO, there would be 2 solutions:
- either change --pretty=oneline,short and other similar things to take
only the first line and change the git-commit manpage (and whenever
else this might be written)
- or change gitweb, gitk and any other tool that would only take the
first line so that it takes the same summary as --pretty=oneline.
What do you think ?
Mike
^ permalink raw reply
* Re: [PATCH 3/8] repack -A -d: use --keep-unreachable when repacking
From: Andreas Ericsson @ 2007-09-17 10:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709171027400.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 17 Sep 2007, Junio C Hamano wrote:
>
>> -USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
>> +USAGE='[-a|-A] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
>
> Would "[-a] [-A]" not be better? In other usage lines, we have the "|"
> for alternative forms of the _same_ option, like "[-m|--merge]".
>
Well, that depends on how you look at it. -m and --merge are (sort of) mutually
exclusive, as the use of one voids the use of the other.
Likewise, using -a and -A together on the same command-line doesn't make much
sense (although -A implies -a rather than meaning the same thing).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: rename detection limit checking, cherry picking, and git am -3
From: Karl Hasselström @ 2007-09-17 9:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Mark Levedahl, Git Mailing List, Catalin Marinas,
David Kågedal
In-Reply-To: <7v3axd5325.fsf@gitster.siamese.dyndns.org>
On 2007-09-16 21:27:46 -0700, Junio C Hamano wrote:
> I think it would make sense to do the consolidated backend for
> rebase, revert, cherry-pick and am (I have been tentatively calling
> this "git replay") primarily based on the "patch with fallback to
> 3-way" like format-patch piped to "am -3", with an option to do
> merge-recursive.
I guess such a backend would be useful for StGit as well.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 8/8] git-gc --auto: run "repack -A -d -l" as necessary.
From: Johannes Schindelin @ 2007-09-17 9:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190018716666-git-send-email-gitster@pobox.com>
Hi,
On Mon, 17 Sep 2007, Junio C Hamano wrote:
> diff --git a/builtin-gc.c b/builtin-gc.c
> index 34ce35b..a82f6be 100644
> --- a/builtin-gc.c
> +++ b/builtin-gc.c
> @@ -78,6 +83,9 @@ static int too_many_loose_objects(void)
> int num_loose = 0;
> int needed = 0;
>
> + if (gc_auto_threshold <= 0)
> + return 0;
> +
Heh, patch 6/8 explicitely moved this check out of the function.
> @@ -100,21 +108,58 @@ static int too_many_loose_objects(void)
> return needed;
> }
>
> +static int too_many_packs(void)
> +{
> + struct packed_git *p;
> + int cnt;
> +
> + if (gc_auto_pack_limit <= 0)
> + return 0;
> +
> + for (cnt = 0, p = packed_git; p; p = p->next) {
> + char *suffix;
> + int keep;
> + if (!p->pack_local)
> + continue;
> + suffix = p->pack_name + strlen(p->pack_name) - 5;
I suspect that you need something like
int len;
len = strlen(p->pack_name);
if (len < 5)
continue;
before this.
> + if (memcmp(suffix, ".pack", 6))
> + continue;
> + memcpy(suffix, ".keep", 6);
> + keep = access(p->pack_name, F_OK) && (errno == ENOENT);
> + memcpy(suffix, ".pack", 6);
Heh. Took me some looking around to see why this is allowed...
> static int need_to_gc(void)
> {
> int ac = 0;
>
> /*
> - * Setting gc.auto to 0 or negative can disable the
> - * automatic gc
> + * Setting gc.auto and gc.autopacklimit to 0 or negative can
> + * disable the automatic gc.
> */
> - if (gc_auto_threshold <= 0)
> - return 0;
> -
> - if (!too_many_loose_objects())
> + if (gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0)
> return 0;
>
> + /*
> + * If there are too many loose objects, but not too many
> + * packs, we run "repack -d -l". If there are too many packs,
> + * we run "repack -A -d -l". Otherwise we tell the caller
> + * there is no need.
> + */
> argv_repack[ac++] = "repack";
> + if (too_many_packs())
> + argv_repack[ac++] = "-A";
> + if (!too_many_loose_objects() && ac == 1)
> + return 0;
Why not
else if (!too_many_loose_objects())
return 0;
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch
From: Karl Hasselström @ 2007-09-17 9:49 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87veaab93v.fsf@morpheus.local>
On 2007-09-16 23:20:36 +0200, David Kågedal wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > Another idea that's been kicked around is to have a general
> > reorder command, that spawns an editor and lets you move around
> > (and delete) patch names until you're satisfied. (This too would
> > be implemented in terms of push and pop of single patches.)
>
> This of course sounds very much like "git rebase -i", but the
> semantics would maybe not be identical.
For one, the StGit version would have to update StGit's metadata. :-)
> One feature from rebase I'd like to see if this was implemented is
> the "squash" option to join two patches. But it would probably be
> called "fold" to keep with stgit terminology.
I actually started to write such a command this weekend, but I didn't
have time to finish it. I did however come to the conclusion that I'd
want to refactor the relationship between patches and commits first.
(Which was why I was so pleasantly surprised that you spent part of
the weekend doing precisely that!)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH 6/8] git-gc --auto: protect ourselves from accumulated cruft
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
Deciding to run "repack -d -l" when there are too many
loose objects would backfire when there are too many loose
objects that are unreachable, because repacking that way would
never improve the situation. Detect that case by checking the
number of loose objects again after automatic garbage collection
runs, and issue an warning to run "prune" manually.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-gc.c | 25 +++++++++++++++++--------
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index f046a2a..bf29f5e 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -64,7 +64,7 @@ static void append_option(const char **cmd, const char *opt, int max_length)
cmd[i] = NULL;
}
-static int need_to_gc(void)
+static int too_many_loose_objects(void)
{
/*
* Quickly check if a "gc" is needed, by estimating how
@@ -80,13 +80,6 @@ static int need_to_gc(void)
int num_loose = 0;
int needed = 0;
- /*
- * Setting gc.auto to 0 or negative can disable the
- * automatic gc
- */
- if (gc_auto_threshold <= 0)
- return 0;
-
if (sizeof(path) <= snprintf(path, sizeof(path), "%s/17", objdir)) {
warning("insanely long object directory %.*s", 50, objdir);
return 0;
@@ -109,6 +102,18 @@ static int need_to_gc(void)
return needed;
}
+static int need_to_gc(void)
+{
+ /*
+ * Setting gc.auto to 0 or negative can disable the
+ * automatic gc
+ */
+ if (gc_auto_threshold <= 0)
+ return 0;
+
+ return too_many_loose_objects();
+}
+
int cmd_gc(int argc, const char **argv, const char *prefix)
{
int i;
@@ -170,5 +175,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (run_command_v_opt(argv_rerere, RUN_GIT_CMD))
return error(FAILED_RUN, argv_rerere[0]);
+ if (auto_gc && too_many_loose_objects())
+ warning("There are too many unreachable loose objects; "
+ "run 'git prune' to remove them.");
+
return 0;
}
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 5/8] git-gc --auto: add documentation.
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
This documents the auto-packing of loose objects performed by
git-gc --auto.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 7 +++++++
Documentation/git-gc.txt | 11 ++++++++++-
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 866e053..3643c0b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -439,6 +439,13 @@ gc.aggressiveWindow::
algorithm used by 'git gc --aggressive'. This defaults
to 10.
+gc.auto::
+ When there are approximately more than this many loose
+ objects in the repository, `git gc --auto` that is
+ invoked by some Porcelain commands will create a new
+ pack and prune them. Setting this to 0 disables the
+ auto garbage collection.
+
gc.packrefs::
`git gc` does not run `git pack-refs` in a bare repository by
default so that older dumb-transport clients can still fetch
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index c7742ca..40c1ce4 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
-'git-gc' [--prune] [--aggressive]
+'git-gc' [--prune] [--aggressive] [--auto]
DESCRIPTION
-----------
@@ -43,6 +43,15 @@ OPTIONS
persistent, so this option only needs to be used occasionally; every
few hundred changesets or so.
+--auto::
+ With this option, `git gc` checks if there are too many
+ loose objects in the repository and runs
+ gitlink:git-repack[1] with `-d -l` option to pack them.
+ The threshold is set with `gc.auto` configuration
+ variable, and can be disabled by setting it to 0. Some
+ Porcelain commands use this after they perform operation
+ that could create many loose objects automatically.
+
Configuration
-------------
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 4/8] git-gc --auto: move threshold check to need_to_gc() function.
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
That is where we decide if we are going to run gc
automatically.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-gc.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 093b3dd..f046a2a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -80,6 +80,13 @@ static int need_to_gc(void)
int num_loose = 0;
int needed = 0;
+ /*
+ * Setting gc.auto to 0 or negative can disable the
+ * automatic gc
+ */
+ if (gc_auto_threshold <= 0)
+ return 0;
+
if (sizeof(path) <= snprintf(path, sizeof(path), "%s/17", objdir)) {
warning("insanely long object directory %.*s", 50, objdir);
return 0;
@@ -129,8 +136,6 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--auto")) {
- if (gc_auto_threshold <= 0)
- return 0;
auto_gc = 1;
continue;
}
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 0/8] Updated git-gc --auto series.
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git
An updated series of "git-gc --auto", on top of 'next',
consisting of 8 patches, will follow this message.
Differences from the previous round are:
- Earlier if you have too many unreachable loose objects,
automated gc would have tried to "repack -d -l" which would
not improve the situation at all every time it was run. It
now at least warns upon such a situation;
- pack-objects learned --keep-unreachable option which helps
"repack -a -d" not to lose packed but unreachable objects
while repacking existing packs into a new pack;
- repack learned -A option which is similar to -a but gives
--keep-unreachable to underlying pack-objects;
- "git-gc --auto" runs "git-repack -A -d -l" when there are too
many packs in the repository;
- These changes are documented ;-)
^ permalink raw reply
* [PATCH 3/8] repack -A -d: use --keep-unreachable when repacking
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
This is a safer variant of "repack -a -d" that does not drop
unreachable objects that are in packs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-repack.sh | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 156c5e8..204084e 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,17 +3,19 @@
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
+USAGE='[-a|-A] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
-no_update_info= all_into_one= remove_redundant=
+no_update_info= all_into_one= remove_redundant= keep_unreachable=
local= quiet= no_reuse= extra=
while case "$#" in 0) break ;; esac
do
case "$1" in
-n) no_update_info=t ;;
-a) all_into_one=t ;;
+ -A) all_into_one=t
+ keep_unreachable=t ;;
-d) remove_redundant=t ;;
-q) quiet=-q ;;
-f) no_reuse=--no-reuse-object ;;
@@ -59,7 +61,13 @@ case ",$all_into_one," in
fi
done
fi
- [ -z "$args" ] && args='--unpacked --incremental'
+ if test -z "$args"
+ then
+ args='--unpacked --incremental'
+ elif test -n "$keep_unreachable"
+ then
+ args="$args --keep-unreachable"
+ fi
;;
esac
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 7/8] git-gc --auto: restructure the way "repack" command line is built.
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
We used to build the command line to run repack outside of
need_to_gc() but with the next patch we would want to tweak the
command line depending on the nature of need.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-gc.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index bf29f5e..34ce35b 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -29,8 +29,6 @@ static const char *argv_repack[MAX_ADD] = {"repack", "-a", "-d", "-l", NULL};
static const char *argv_prune[] = {"prune", NULL};
static const char *argv_rerere[] = {"rerere", "gc", NULL};
-static const char *argv_repack_auto[] = {"repack", "-d", "-l", NULL};
-
static int gc_config(const char *var, const char *value)
{
if (!strcmp(var, "gc.packrefs")) {
@@ -104,6 +102,8 @@ static int too_many_loose_objects(void)
static int need_to_gc(void)
{
+ int ac = 0;
+
/*
* Setting gc.auto to 0 or negative can disable the
* automatic gc
@@ -111,7 +111,14 @@ static int need_to_gc(void)
if (gc_auto_threshold <= 0)
return 0;
- return too_many_loose_objects();
+ if (!too_many_loose_objects())
+ return 0;
+
+ argv_repack[ac++] = "repack";
+ argv_repack[ac++] = "-d";
+ argv_repack[ac++] = "-l";
+ argv_repack[ac++] = NULL;
+ return 1;
}
int cmd_gc(int argc, const char **argv, const char *prefix)
@@ -154,8 +161,6 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
* Auto-gc should be least intrusive as possible.
*/
prune = 0;
- for (i = 0; i < ARRAY_SIZE(argv_repack_auto); i++)
- argv_repack[i] = argv_repack_auto[i];
if (!need_to_gc())
return 0;
}
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 8/8] git-gc --auto: run "repack -A -d -l" as necessary.
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
This teaches "git-gc --auto" to consolidate many packs into one
without losing unreachable objects in them by using "repack -A"
when there are too many packfiles that are not marked with *.keep
in the repository. gc.autopacklimit configuration can be used
to set the maximum number of packs a repository is allowed to
have before this mechanism kicks in.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 9 +++++-
Documentation/git-gc.txt | 7 +++++-
builtin-gc.c | 57 +++++++++++++++++++++++++++++++++++++++++-----
3 files changed, 64 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3643c0b..f5136c3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -443,8 +443,13 @@ gc.auto::
When there are approximately more than this many loose
objects in the repository, `git gc --auto` that is
invoked by some Porcelain commands will create a new
- pack and prune them. Setting this to 0 disables the
- auto garbage collection.
+ pack and prune them. Setting this to 0 disables this.
+
+gc.autopacklimit::
+ When there are more than this many packs that are not
+ marked with `*.keep` file in the repository, `git gc
+ --auto` consolidates them into one larger pack. Setting
+ this to 0 disables this.
gc.packrefs::
`git gc` does not run `git pack-refs` in a bare repository by
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 40c1ce4..b9d5660 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -47,10 +47,15 @@ OPTIONS
With this option, `git gc` checks if there are too many
loose objects in the repository and runs
gitlink:git-repack[1] with `-d -l` option to pack them.
- The threshold is set with `gc.auto` configuration
+ The threshold for loose objects is set with `gc.auto` configuration
variable, and can be disabled by setting it to 0. Some
Porcelain commands use this after they perform operation
that could create many loose objects automatically.
+ Additionally, when there are too many packs are present,
+ they are consolidated into one larger pack by running
+ the `git-repack` command with `-A` option. The
+ threshold for number of packs is set with
+ `gc.autopacklimit` configuration variable.
Configuration
-------------
diff --git a/builtin-gc.c b/builtin-gc.c
index 34ce35b..a82f6be 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -21,6 +21,7 @@ static const char builtin_gc_usage[] = "git-gc [--prune] [--aggressive]";
static int pack_refs = 1;
static int aggressive_window = -1;
static int gc_auto_threshold = 6700;
+static int gc_auto_pack_limit = 20;
#define MAX_ADD 10
static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
@@ -46,6 +47,10 @@ static int gc_config(const char *var, const char *value)
gc_auto_threshold = git_config_int(var, value);
return 0;
}
+ if (!strcmp(var, "gc.autopacklimit")) {
+ gc_auto_pack_limit = git_config_int(var, value);
+ return 0;
+ }
return git_default_config(var, value);
}
@@ -78,6 +83,9 @@ static int too_many_loose_objects(void)
int num_loose = 0;
int needed = 0;
+ if (gc_auto_threshold <= 0)
+ return 0;
+
if (sizeof(path) <= snprintf(path, sizeof(path), "%s/17", objdir)) {
warning("insanely long object directory %.*s", 50, objdir);
return 0;
@@ -100,21 +108,58 @@ static int too_many_loose_objects(void)
return needed;
}
+static int too_many_packs(void)
+{
+ struct packed_git *p;
+ int cnt;
+
+ if (gc_auto_pack_limit <= 0)
+ return 0;
+
+ for (cnt = 0, p = packed_git; p; p = p->next) {
+ char *suffix;
+ int keep;
+ if (!p->pack_local)
+ continue;
+ suffix = p->pack_name + strlen(p->pack_name) - 5;
+ if (memcmp(suffix, ".pack", 6))
+ continue;
+ memcpy(suffix, ".keep", 6);
+ keep = access(p->pack_name, F_OK) && (errno == ENOENT);
+ memcpy(suffix, ".pack", 6);
+ if (keep)
+ continue;
+ /*
+ * Perhaps check the size of the pack and count only
+ * very small ones here?
+ */
+ cnt++;
+ }
+ return gc_auto_pack_limit <= cnt;
+}
+
static int need_to_gc(void)
{
int ac = 0;
/*
- * Setting gc.auto to 0 or negative can disable the
- * automatic gc
+ * Setting gc.auto and gc.autopacklimit to 0 or negative can
+ * disable the automatic gc.
*/
- if (gc_auto_threshold <= 0)
- return 0;
-
- if (!too_many_loose_objects())
+ if (gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0)
return 0;
+ /*
+ * If there are too many loose objects, but not too many
+ * packs, we run "repack -d -l". If there are too many packs,
+ * we run "repack -A -d -l". Otherwise we tell the caller
+ * there is no need.
+ */
argv_repack[ac++] = "repack";
+ if (too_many_packs())
+ argv_repack[ac++] = "-A";
+ if (!too_many_loose_objects() && ac == 1)
+ return 0;
argv_repack[ac++] = "-d";
argv_repack[ac++] = "-l";
argv_repack[ac++] = NULL;
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 1/8] Export matches_pack_name() and fix its return value
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
The function sounds boolean; make it behave as one, not "0 for
success, non-zero for failure".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 1 +
sha1_file.c | 14 +++++++-------
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index 70abbd5..3fa5b8e 100644
--- a/cache.h
+++ b/cache.h
@@ -529,6 +529,7 @@ extern void *unpack_entry(struct packed_git *, off_t, enum object_type *, unsign
extern unsigned long unpack_object_header_gently(const unsigned char *buf, unsigned long len, enum object_type *type, unsigned long *sizep);
extern unsigned long get_size_from_delta(struct packed_git *, struct pack_window **, off_t);
extern const char *packed_object_info_detail(struct packed_git *, off_t, unsigned long *, unsigned long *, unsigned int *, unsigned char *);
+extern int matches_pack_name(struct packed_git *p, const char *name);
/* Dumb servers support */
extern int update_server_info(int);
diff --git a/sha1_file.c b/sha1_file.c
index 9978a58..5801c3e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1684,22 +1684,22 @@ off_t find_pack_entry_one(const unsigned char *sha1,
return 0;
}
-static int matches_pack_name(struct packed_git *p, const char *ig)
+int matches_pack_name(struct packed_git *p, const char *name)
{
const char *last_c, *c;
- if (!strcmp(p->pack_name, ig))
- return 0;
+ if (!strcmp(p->pack_name, name))
+ return 1;
for (c = p->pack_name, last_c = c; *c;)
if (*c == '/')
last_c = ++c;
else
++c;
- if (!strcmp(last_c, ig))
- return 0;
+ if (!strcmp(last_c, name))
+ return 1;
- return 1;
+ return 0;
}
static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e, const char **ignore_packed)
@@ -1717,7 +1717,7 @@ static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e, cons
if (ignore_packed) {
const char **ig;
for (ig = ignore_packed; *ig; ig++)
- if (!matches_pack_name(p, *ig))
+ if (matches_pack_name(p, *ig))
break;
if (*ig)
goto next;
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 2/8] pack-objects --keep-unreachable
From: Junio C Hamano @ 2007-09-17 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1190017633436-git-send-email-gitster@pobox.com>
This new option is meant to be used in conjunction with the
options "git repack -a -d" usually invokes the underlying
pack-objects. When this option is given, objects unreachable
from the refs in packs named with --unpacked= option are added
to the resulting pack, in addition to the reachable objects that
are not in packs marked with *.keep files.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-pack-objects.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 12509fa..ba7c8da 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -21,7 +21,7 @@ git-pack-objects [{ -q | --progress | --all-progress }] \n\
[--window=N] [--window-memory=N] [--depth=N] \n\
[--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n\
[--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
- [--stdout | base-name] [<ref-list | <object-list]";
+ [--stdout | base-name] [--keep-unreachable] [<ref-list | <object-list]";
struct object_entry {
struct pack_idx_entry idx;
@@ -57,7 +57,7 @@ static struct object_entry **written_list;
static uint32_t nr_objects, nr_alloc, nr_result, nr_written;
static int non_empty;
-static int no_reuse_delta, no_reuse_object;
+static int no_reuse_delta, no_reuse_object, keep_unreachable;
static int local;
static int incremental;
static int allow_ofs_delta;
@@ -1625,15 +1625,19 @@ static void read_object_list_from_stdin(void)
}
}
+#define OBJECT_ADDED (1u<<20)
+
static void show_commit(struct commit *commit)
{
add_object_entry(commit->object.sha1, OBJ_COMMIT, NULL, 0);
+ commit->object.flags |= OBJECT_ADDED;
}
static void show_object(struct object_array_entry *p)
{
add_preferred_base_object(p->name);
add_object_entry(p->item->sha1, p->item->type, p->name, 0);
+ p->item->flags |= OBJECT_ADDED;
}
static void show_edge(struct commit *commit)
@@ -1641,6 +1645,86 @@ static void show_edge(struct commit *commit)
add_preferred_base(commit->object.sha1);
}
+struct in_pack_object {
+ off_t offset;
+ struct object *object;
+};
+
+struct in_pack {
+ int alloc;
+ int nr;
+ struct in_pack_object *array;
+};
+
+static void mark_in_pack_object(struct object *object, struct packed_git *p, struct in_pack *in_pack)
+{
+ in_pack->array[in_pack->nr].offset = find_pack_entry_one(object->sha1, p);
+ in_pack->array[in_pack->nr].object = object;
+ in_pack->nr++;
+}
+
+/*
+ * Compare the objects in the offset order, in order to emulate the
+ * "git-rev-list --objects" output that produced the pack originally.
+ */
+static int ofscmp(const void *a_, const void *b_)
+{
+ struct in_pack_object *a = (struct in_pack_object *)a_;
+ struct in_pack_object *b = (struct in_pack_object *)b_;
+
+ if (a->offset < b->offset)
+ return -1;
+ else if (a->offset > b->offset)
+ return 1;
+ else
+ return hashcmp(a->object->sha1, b->object->sha1);
+}
+
+static void add_objects_in_unpacked_packs(struct rev_info *revs)
+{
+ struct packed_git *p;
+ struct in_pack in_pack;
+ uint32_t i;
+
+ memset(&in_pack, 0, sizeof(in_pack));
+
+ for (p = packed_git; p; p = p->next) {
+ const unsigned char *sha1;
+ struct object *o;
+
+ for (i = 0; i < revs->num_ignore_packed; i++) {
+ if (matches_pack_name(p, revs->ignore_packed[i]))
+ break;
+ }
+ if (revs->num_ignore_packed <= i)
+ continue;
+ if (open_pack_index(p))
+ die("cannot open pack index");
+
+ ALLOC_GROW(in_pack.array,
+ in_pack.nr + p->num_objects,
+ in_pack.alloc);
+
+ for (i = 0; i < p->num_objects; i++) {
+ sha1 = nth_packed_object_sha1(p, i);
+ o = lookup_unknown_object(sha1);
+ if (!(o->flags & OBJECT_ADDED))
+ mark_in_pack_object(o, p, &in_pack);
+ o->flags |= OBJECT_ADDED;
+ }
+ }
+
+ if (in_pack.nr) {
+ qsort(in_pack.array, in_pack.nr, sizeof(in_pack.array[0]),
+ ofscmp);
+ for (i = 0; i < in_pack.nr; i++) {
+ struct object *o = in_pack.array[i].object;
+ add_object_entry(o->sha1, o->type, "", 0);
+ }
+ }
+ free(in_pack.array);
+}
+
static void get_object_list(int ac, const char **av)
{
struct rev_info revs;
@@ -1672,6 +1756,9 @@ static void get_object_list(int ac, const char **av)
prepare_revision_walk(&revs);
mark_edges_uninteresting(revs.commits, &revs, show_edge);
traverse_commit_list(&revs, show_commit, show_object);
+
+ if (keep_unreachable)
+ add_objects_in_unpacked_packs(&revs);
}
static int adjust_perm(const char *path, mode_t mode)
@@ -1789,6 +1876,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
use_internal_rev_list = 1;
continue;
}
+ if (!strcmp("--keep-unreachable", arg)) {
+ keep_unreachable = 1;
+ continue;
+ }
if (!strcmp("--unpacked", arg) ||
!prefixcmp(arg, "--unpacked=") ||
!strcmp("--reflog", arg) ||
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* Re: [PATCH 7/8] git-gc --auto: restructure the way "repack" command line is built.
From: Johannes Schindelin @ 2007-09-17 9:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190018713416-git-send-email-gitster@pobox.com>
Hi,
On Mon, 17 Sep 2007, Junio C Hamano wrote:
> @@ -154,8 +161,6 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
> * Auto-gc should be least intrusive as possible.
> */
> prune = 0;
> - for (i = 0; i < ARRAY_SIZE(argv_repack_auto); i++)
> - argv_repack[i] = argv_repack_auto[i];
> if (!need_to_gc())
> return 0;
> }
This subtly changes behaviour: --auto ran also garbage collection for
reflogs and rerere.
This might be intended, but is not documented.
Ciao,
Dscho
^ permalink raw reply
* Re: Git pull fails on a repository > 1.5G.
From: pradeep singh @ 2007-09-17 9:39 UTC (permalink / raw)
To: git; +Cc: Dhirendra Singh Kholia
In-Reply-To: <a901b49a0709170159g477525bcr5383a1a051ae5e3d@mail.gmail.com>
PS:- please CC me , as i am not subscribed to git list.
On 9/17/07, pradeep singh <pradeep.rautela@gmail.com> wrote:
> Hi All,
>
> I am using git at work for a rather big repository. Size is around
> 1.5-1.8Gigs now.
> My git version is 1.5.2.4.
>
> The remote repo has some changes to a file with some simple printk's
> some some code changes.
>
> I have my git repo in /mnt/reiser/project .
>
> I changed to the my repo.
>
> i did a git-pull ssh://user1@10.100.205.34/opt/test/project test .[to
> pull from another test machine].
>
> I got some conflicts in a file but in some important files it did not update it.
>
> Any hints whats wrong with my technique or is there something wrong with git?
Just to add.
If i pull tags with
$git-pull ssh://user1@10.100.205.34/opt/test/project test
i get them.
doing a git-merge v-1.0b does not reflect any changes but a git-branch
new_test v-1.0b makes new_test branch which has the changes.
Again git-merge new_test fails miserably, it says no conflicts though
there are conflicts.
What is happening here? :-/
I am puzzled.
Can anybody please help me???
thanks
--
Pradeep
^ permalink raw reply
* Re: [PATCH 5/8] git-gc --auto: add documentation.
From: Johannes Schindelin @ 2007-09-17 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11900187073420-git-send-email-gitster@pobox.com>
Hi,
On Mon, 17 Sep 2007, Junio C Hamano wrote:
> + When there are approximately more than this many loose
> + objects in the repository, `git gc --auto` that is
> + invoked by some Porcelain commands will create a new
> + pack and prune them.
It might strike a newbie as dangerous to read "prune them" here. Maybe
... `git gc --auto` will pack the loose objects. Some Porcelain
commands use this command, to do a light weight garbage collection
from time to time.
+
*Note*: you should still run "git gc" from time to time, since the
"--auto" option is designed to be fast, whereas "git gc" _without_
auto is designed to create small packs.
Hmm? (I think that this is the most visible part of the --auto business,
so I would document the "git gc" note here...)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/8] repack -A -d: use --keep-unreachable when repacking
From: Johannes Schindelin @ 2007-09-17 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11900187002882-git-send-email-gitster@pobox.com>
Hi,
On Mon, 17 Sep 2007, Junio C Hamano wrote:
> -USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
> +USAGE='[-a|-A] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
Would "[-a] [-A]" not be better? In other usage lines, we have the "|"
for alternative forms of the _same_ option, like "[-m|--merge]".
> + -A) all_into_one=t
> + keep_unreachable=t ;;
Why not "keep_unreachable=--keep-unreachable" and use "$args
$keep_unreachable" later?
Ciao,
Dscho
^ 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