From 5dee29ac0fc95999a42c5cbac767724a9ff73cfa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Thu, 25 Jan 2007 05:45:39 +0100 Subject: [PATCH 01/12] make --upload-pack option to git-fetch configurable MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This introduces the config item remote..uploadpack to override the default value (which is "git-upload-pack"). Signed-off-by: Uwe Kleine-König Signed-off-by: Junio C Hamano --- Documentation/config.txt | 6 +++++- git-fetch.sh | 6 ++++++ git-parse-remote.sh | 13 +++++++++++++ 3 files changed, 24 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 8086d75368..3f2fa09a87 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -429,9 +429,13 @@ remote..push:: gitlink:git-push[1]. remote..receivepack:: - The default program to execute on the remote side when pulling. See + The default program to execute on the remote side when pushing. See option \--exec of gitlink:git-push[1]. +remote..uploadpack:: + The default program to execute on the remote side when fetching. See + option \--exec of gitlink:git-fetch-pack[1]. + repack.usedeltabaseoffset:: Allow gitlink:git-repack[1] to create packs that uses delta-base offset. Defaults to false. diff --git a/git-fetch.sh b/git-fetch.sh index 07a1d05ac7..61c8cf4773 100755 --- a/git-fetch.sh +++ b/git-fetch.sh @@ -85,6 +85,12 @@ case "$#" in set x $origin ; shift ;; esac +if test -z "$exec" +then + # No command line override and we have configuration for the remote. + exec="--upload-pack=$(get_uploadpack $1)" +fi + remote_nick="$1" remote=$(get_remote_url "$@") refs= diff --git a/git-parse-remote.sh b/git-parse-remote.sh index 4fc602082b..1122c8389d 100755 --- a/git-parse-remote.sh +++ b/git-parse-remote.sh @@ -279,3 +279,16 @@ resolve_alternates () { esac done } + +get_uploadpack () { + data_source=$(get_data_source "$1") + case "$data_source" in + config) + uplp=$(git-repo-config --get "remote.$1.uploadpack") + echo ${uplp:-git-upload-pack} + ;; + *) + echo "git-upload-pack" + ;; + esac +} From 535514f1f3cd32dfe2cb4c70e97b41ea868d1134 Mon Sep 17 00:00:00 2001 From: Andy Parkins Date: Mon, 22 Jan 2007 10:56:27 +0000 Subject: [PATCH 02/12] New files in git weren't being downloaded during CVS update If a repository was checked out via git-cvsserver and then later a new file is added to the git repository via some other method; a CVS update wasn't fetching the new file. It would be reported as a new file as A some/dir/newfile.c but would never appear in the directory. The problem seems to be that git-cvsserver was treating these two cases identically, as "A" type results. 1. New file in repository 2. New file locally In fact, traditionally, case 1 is treated as a "U" result, and case 2 only is treated as an "A" result. "A", should just report that the file is added locally and then skip that file during an update as there is (of course) nothing to send. In both these cases there is no working revision, so the checking for "is there no working revision" will return true. The test for case 2 needs refining to say "if there is no working revision and no upstream revision". This patch does just that, leaving case 1 to be handled by the normal "U" handler. I've also updated the log message to more accurately describe the operation. i.e. that "A" means that content is scheduled for addition; not that it actually has been added. Signed-off-by: Andy Parkins Signed-off-by: Junio C Hamano --- git-cvsserver.perl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/git-cvsserver.perl b/git-cvsserver.perl index a33a876ff6..e18e901731 100755 --- a/git-cvsserver.perl +++ b/git-cvsserver.perl @@ -876,9 +876,9 @@ sub req_update print "MT newline\n"; next; } - elsif ( !defined($wrev) || $wrev == 0 ) + elsif ( (!defined($wrev) || $wrev == 0) && (!defined($meta->{revision}) || $meta->{revision} == 0) ) { - $log->info("Tell the client the file will be added"); + $log->info("Tell the client the file is scheduled for addition"); print "MT text A \n"; print "MT fname $filename\n"; print "MT newline\n"; @@ -886,7 +886,7 @@ sub req_update } else { - $log->info("Updating '$filename' $wrev"); + $log->info("Updating '$filename' to ".$meta->{revision}); print "MT +updated\n"; print "MT text U \n"; print "MT fname $filename\n"; From 1b555932cdb7f75239623573cd2ff25fa98ab4e4 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Thu, 25 Jan 2007 16:51:21 -0800 Subject: [PATCH 03/12] Fix seriously broken "git pack-refs" Do *NOT* try this on a repository you care about: git pack-refs --all --prune git pack-refs because while the first "pack-refs" does the right thing, the second pack-refs will totally screw you over. This is because the second one tries to pack only tags; we should also pack what are already packed -- otherwise we would lose them. [jc: with an additional test] Signed-off-by: Junio C Hamano --- builtin-pack-refs.c | 4 +++- t/t3210-pack-refs.sh | 9 +++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c index 6de7128b9d..3de9b3eefd 100644 --- a/builtin-pack-refs.c +++ b/builtin-pack-refs.c @@ -37,7 +37,9 @@ static int handle_one_ref(const char *path, const unsigned char *sha1, if ((flags & REF_ISSYMREF)) return 0; is_tag_ref = !strncmp(path, "refs/tags/", 10); - if (!cb->all && !is_tag_ref) + + /* ALWAYS pack refs that were already packed or are tags */ + if (!cb->all && !is_tag_ref && !(flags & REF_ISPACKED)) return 0; fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path); diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh index 16bdae4f23..f0c7e22b36 100755 --- a/t/t3210-pack-refs.sh +++ b/t/t3210-pack-refs.sh @@ -96,4 +96,13 @@ test_expect_success \ git-branch -d n/o/p && git-branch n' +test_expect_success 'pack, prune and repack' ' + git-tag foo && + git-pack-refs --all --prune && + git-show-ref >all-of-them && + git-pack-refs && + git-show-ref >again && + diff all-of-them again +' + test_done From fd73423f01361f112dbb9972ebce8eabae7dd8b1 Mon Sep 17 00:00:00 2001 From: Sam Vilain Date: Fri, 26 Jan 2007 12:41:23 +1300 Subject: [PATCH 04/12] contrib/emacs/vc-git.el: support vc-version-other-window Currently, the vc-git-checkout function uses `git checkout' to fetch a file from the git repository to the working copy. However, it is completely ignoring the input argument that specifies the destination file. `git-checkout' does not support specifying this, so we have to use `git-cat-file', capture the output in a buffer and then save it. Signed-off-by: Junio C Hamano --- contrib/emacs/vc-git.el | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el index 3eb4bd19e9..65c4550069 100644 --- a/contrib/emacs/vc-git.el +++ b/contrib/emacs/vc-git.el @@ -53,6 +53,10 @@ (let ((name (file-relative-name file))) (eq 0 (apply #'call-process "git" nil (get-buffer "*Messages") nil (append args (list name)))))) +(defun vc-git--run-command-out (output &rest args) + "Run a git command, output to output." + (eq 0 (apply #'call-process "git" nil output nil (append args)))) + (defun vc-git-registered (file) "Check whether FILE is registered with git." (with-temp-buffer @@ -120,7 +124,28 @@ (vc-git--run-command file "commit" "-m" comment "--only" "--"))) (defun vc-git-checkout (file &optional editable rev destfile) - (vc-git--run-command file "checkout" (or rev "HEAD"))) + (if destfile + (let ((mybuff (get-buffer-create "vc-git-checkout-tmp"))) + (let ((rv + (vc-git--run-command-out + mybuff "cat-file" "blob" + (concat (or rev "HEAD") + ":" + (let ((output (vc-git--run-command-string + (file-relative-name file) + "ls-files" "--full-name"))) + (string-match "\\(.*\\)" output) + (match-string 1 output)) + ))) + ) + (if rv + (save-current-buffer + (set-buffer mybuff) + (set-visited-file-name destfile t) + (save-buffer) + ) + rv))) + (vc-git--run-command file "checkout" (or rev "HEAD")))) (defun vc-git-annotate-command (file buf &optional rev) ; FIXME: rev is ignored From cb280e107523e5263f390db715234700355a63b9 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 25 Jan 2007 19:05:01 -0800 Subject: [PATCH 05/12] Allow non-developer to clone, checkout and fetch more easily. The code that uses committer_info() in reflog can barf and die whenever it is asked to update a ref. And I do not think calling ignore_missing_committer_name() upfront like recent receive-pack did in the aplication is a reasonable workaround. What the patch does. - git_committer_info() takes one parameter. It used to be "if this is true, then die() if the name is not available due to bad GECOS, otherwise issue a warning once but leave the name empty". The reason was because we wanted to prevent bad commits from being made by git-commit-tree (and its callers). The value 0 is only used by "git var -l". Now it takes -1, 0 or 1. When set to -1, it does not complain but uses the pw->pw_name when name is not available. Existing 0 and 1 values mean the same thing as they used to mean before. 0 means issue warnings and leave it empty, 1 means barf and die. - ignore_missing_committer_name() and its existing caller (receive-pack, to set the reflog) have been removed. - git-format-patch, to come up with the phoney message ID when asked to thread, now passes -1 to git_committer_info(). This codepath uses only the e-mail part, ignoring the name. It used to barf and die. The other call in the same program when asked to add signed-off-by line based on committer identity still passes 1 to make sure it barfs instead of adding a bogus s-o-b line. - log_ref_write in refs.c, to come up with the name to record who initiated the ref update in the reflog, passes -1. It used to barf and die. The last change means that git-update-ref, git-branch, and commit walker backends can now be used in a repository with reflog by somebody who does not have the user identity required to make a commit. They all used to barf and die. I've run tests and all of them seem to pass, and also tried "git clone" as a user whose GECOS is empty -- git clone works again now (it was broken when reflog was enabled by default). But this definitely needs extra sets of eyeballs. Signed-off-by: Junio C Hamano --- builtin-log.c | 2 +- cache.h | 1 - ident.c | 28 +++++++++++----------------- receive-pack.c | 2 -- refs.c | 2 +- 5 files changed, 13 insertions(+), 22 deletions(-) diff --git a/builtin-log.c b/builtin-log.c index 503cd1e2be..56acc137f0 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -352,7 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co static void gen_message_id(char *dest, unsigned int length, char *base) { - const char *committer = git_committer_info(1); + const char *committer = git_committer_info(-1); const char *email_start = strrchr(committer, '<'); const char *email_end = strrchr(committer, '>'); if(!email_start || !email_end || email_start > email_end - 1) diff --git a/cache.h b/cache.h index 473197ded8..9486132ac5 100644 --- a/cache.h +++ b/cache.h @@ -320,7 +320,6 @@ void datestamp(char *buf, int bufsize); unsigned long approxidate(const char *); extern int setup_ident(void); -extern void ignore_missing_committer_name(void); extern const char *git_author_info(int); extern const char *git_committer_info(int); diff --git a/ident.c b/ident.c index 6ad8fedd60..f9677905e5 100644 --- a/ident.c +++ b/ident.c @@ -180,12 +180,21 @@ static const char *get_ident(const char *name, const char *email, email = git_default_email; if (!*name) { - if (name == git_default_name && env_hint) { + struct passwd *pw; + + if (0 <= error_on_no_name && + name == git_default_name && env_hint) { fprintf(stderr, env_hint, au_env, co_env); env_hint = NULL; /* warn only once, for "git-var -l" */ } - if (error_on_no_name) + if (0 < error_on_no_name) die("empty ident %s <%s> not allowed", name, email); + pw = getpwuid(getuid()); + if (!pw) + die("You don't exist. Go away!"); + strlcpy(git_default_name, pw->pw_name, + sizeof(git_default_name)); + name = git_default_name; } strcpy(date, git_default_date); @@ -218,18 +227,3 @@ const char *git_committer_info(int error_on_no_name) getenv("GIT_COMMITTER_DATE"), error_on_no_name); } - -void ignore_missing_committer_name() -{ - /* If we did not get a name from the user's gecos entry then - * git_default_name is empty; so instead load the username - * into it as a 'good enough for now' approximation of who - * this user is. - */ - if (!*git_default_name) { - struct passwd *pw = getpwuid(getuid()); - if (!pw) - die("You don't exist. Go away!"); - strlcpy(git_default_name, pw->pw_name, sizeof(git_default_name)); - } -} diff --git a/receive-pack.c b/receive-pack.c index 8b59b3227e..7d263262d3 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -430,8 +430,6 @@ int main(int argc, char **argv) die("attempt to push into a shallow repository"); setup_ident(); - /* don't die if gecos is empty */ - ignore_missing_committer_name(); git_config(receive_pack_config); if (0 <= transfer_unpack_limit) diff --git a/refs.c b/refs.c index 81173282fc..4323e9a41a 100644 --- a/refs.c +++ b/refs.c @@ -958,7 +958,7 @@ static int log_ref_write(struct ref_lock *lock, lock->log_file, strerror(errno)); } - committer = git_committer_info(1); + committer = git_committer_info(-1); if (msg) { maxlen = strlen(committer) + strlen(msg) + 2*40 + 5; logrec = xmalloc(maxlen); From e1b161161d253a9e7e4cf21cd2ab5b82a4b85273 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 25 Jan 2007 23:48:58 -0500 Subject: [PATCH 06/12] diffcore-pickaxe: fix infinite loop on zero-length needle The "contains" algorithm runs into an infinite loop if the needle string has zero length. The loop could be modified to handle this, but it makes more sense to simply have an empty needle return no matches. Thus, a command like git log -S produces no output. We place the check at the top of the function so that we get the same results with or without --pickaxe-regex. Note that until now, git log -S --pickaxe-regex would match everything, not nothing. Arguably, an empty pickaxe string should simply produce an error message; however, this is still a useful assertion to add to the algorithm at this layer of the code. Noticed by Bill Lear. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- diffcore-pickaxe.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c index de44adabf0..286919e714 100644 --- a/diffcore-pickaxe.c +++ b/diffcore-pickaxe.c @@ -14,6 +14,8 @@ static unsigned int contains(struct diff_filespec *one, const char *data; if (diff_populate_filespec(one, 0)) return 0; + if (!len) + return 0; sz = one->size; data = one->data; From ae9c6ffe3039fc4d0a89eb253800b3ca58830bb2 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 25 Jan 2007 21:50:49 -0800 Subject: [PATCH 07/12] parse-remote: do not barf on a remote shorthand without any refs to fetch. Signed-off-by: Junio C Hamano --- git-parse-remote.sh | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/git-parse-remote.sh b/git-parse-remote.sh index 1122c8389d..7e87f2e06e 100755 --- a/git-parse-remote.sh +++ b/git-parse-remote.sh @@ -81,7 +81,14 @@ get_remote_default_refs_for_push () { # is to help prevent randomly "globbed" ref from being chosen as # a merge candidate expand_refs_wildcard () { + remote="$1" + shift first_one=yes + if test "$#" = 0 + then + echo empty + echo >&2 "Nothing specified for fetching with remote.$remote.fetch" + fi for ref do lref=${ref#'+'} @@ -132,7 +139,7 @@ canon_refs_list_for_fetch () { if test "$1" = "-d" then shift ; remote="$1" ; shift - set $(expand_refs_wildcard "$@") + set $(expand_refs_wildcard "$remote" "$@") is_explicit="$1" shift if test "$remote" = "$(get_default_remote)" From a9eefb3bfc66b7f5dba86ebf57b05e32c33eb9e5 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Thu, 25 Jan 2007 21:55:34 -0800 Subject: [PATCH 08/12] Add dangling objects tips. Signed-off-by: Junio C Hamano --- Documentation/howto/dangling-objects.txt | 109 +++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 Documentation/howto/dangling-objects.txt diff --git a/Documentation/howto/dangling-objects.txt b/Documentation/howto/dangling-objects.txt new file mode 100644 index 0000000000..e82ddae3cf --- /dev/null +++ b/Documentation/howto/dangling-objects.txt @@ -0,0 +1,109 @@ +From: Linus Torvalds +Subject: Re: Question about fsck-objects output +Date: Thu, 25 Jan 2007 12:01:06 -0800 (PST) +Message-ID: +Archived-At: +Abstract: Linus describes what dangling objects are, when they + are left behind, and how to view their relationship with branch + heads in gitk + +On Thu, 25 Jan 2007, Larry Streepy wrote: + +> Sorry to ask such a basic question, but I can't quite decipher the output of +> fsck-objects. When I run it, I get this: +> +> git fsck-objects +> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b +> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f +> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761 +> +> +> Even after a "repack -a -d" they still exist. The man page has a short +> explanation, but, at least for me, it wasn't fully enlightening. :-) +> +> The man page says that dangling commits could be "root" commits, but since my +> repo started as a clone of another repo, I don't see how I could have any root +> commits. Also, the page doesn't really describe what a dangling blob is. +> +> So, can someone explain what these artifacts are and if they are a problem +> that I should be worried about? + +The most common situation is that you've rebased a branch (or you have +pulled from somebody else who rebased a branch, like the "pu" branch in +the git.git archive itself). + +What happens is that the old head of the original branch still exists, as +does obviously everything it pointed to. The branch pointer itself just +doesn't, since you replaced it with another one. + +However, there are certainly other situations too that cause dangling +objects. For example, the "dangling blob" situation you have tends to be +because you did a "git add" of a file, but then, before you actually +committed it and made it part of the bigger picture, you changed something +else in that file and committed that *updated* thing - the old state that +you added originally ends up not being pointed to by any commit/tree, so +it's now a dangling blob object. + +Similarly, when the "recursive" merge strategy runs, and finds that there +are criss-cross merges and thus more than one merge base (which is fairly +unusual, but it does happen), it will generate one temporary midway tree +(or possibly even more, if you had lots of criss-crossing merges and +more than two merge bases) as a temporary internal merge base, and again, +those are real objects, but the end result will not end up pointing to +them, so they end up "dangling" in your repository. + +Generally, dangling objects aren't anything to worry about. They can even +be very useful: if you screw something up, the dangling objects can be how +you recover your old tree (say, you did a rebase, and realized that you +really didn't want to - you can look at what dangling objects you have, +and decide to reset your head to some old dangling state). + +For commits, the most useful thing to do with dangling objects tends to be +to do a simple + + gitk --not --all + +which means exactly what it sounds like: it says that you want to see the +commit history that is described by the dangling commit(s), but you do NOT +want to see the history that is described by all your branches and tags +(which are the things you normally reach). That basically shows you in a +nice way what the danglign commit was (and notice that it might not be +just one commit: we only report the "tip of the line" as being dangling, +but there might be a whole deep and complex commit history that has gotten +dropped - rebasing will do that). + +For blobs and trees, you can't do the same, but you can examine them. You +can just do + + git show + +to show what the contents of the blob were (or, for a tree, basically what +the "ls" for that directory was), and that may give you some idea of what +the operation was that left that dangling object. + +Usually, dangling blobs and trees aren't very interesting. They're almost +always the result of either being a half-way mergebase (the blob will +often even have the conflict markers from a merge in it, if you have had +conflicting merges that you fixed up by hand), or simply because you +interrupted a "git fetch" with ^C or something like that, leaving _some_ +of the new objects in the object database, but just dangling and useless. + +Anyway, once you are sure that you're not interested in any dangling +state, you can just prune all unreachable objects: + + git prune + +and they'll be gone. But you should only run "git prune" on a quiescent +repository - it's kind of like doing a filesystem fsck recovery: you don't +want to do that while the filesystem is mounted. + +(The same is true of "git-fsck-objects" itself, btw - but since +git-fsck-objects never actually *changes* the repository, it just reports +on what it found, git-fsck-objects itself is never "dangerous" to run. +Running it while somebody is actually changing the repository can cause +confusing and scary messages, but it won't actually do anything bad. In +contrast, running "git prune" while somebody is actively changing the +repository is a *BAD* idea). + + Linus + From df373ea99a1cf3056a72bad1d66f0e62f3b41c20 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 25 Jan 2007 22:14:45 -0800 Subject: [PATCH 09/12] show-branch -g: default to HEAD Signed-off-by: Junio C Hamano --- builtin-show-branch.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/builtin-show-branch.c b/builtin-show-branch.c index 536245e7d3..fa62e487b1 100644 --- a/builtin-show-branch.c +++ b/builtin-show-branch.c @@ -662,13 +662,13 @@ int cmd_show_branch(int ac, const char **av, const char *prefix) } ac--; av++; - if (!!extra || !!reflog) { + if (extra || reflog) { /* "listing" mode is incompatible with * independent nor merge-base modes. */ if (independent || merge_base) usage(show_branch_usage); - if (!!reflog && ((0 < extra) || all_heads || all_remotes)) + if (reflog && ((0 < extra) || all_heads || all_remotes)) /* * Asking for --more in reflog mode does not * make sense. --list is Ok. @@ -682,15 +682,22 @@ int cmd_show_branch(int ac, const char **av, const char *prefix) if (ac + all_heads + all_remotes == 0) all_heads = 1; - if (all_heads + all_remotes) - snarf_refs(all_heads, all_remotes); if (reflog) { unsigned char sha1[20]; char nth_desc[256]; char *ref; int base = 0; + + if (ac == 0) { + static const char *fake_av[2]; + fake_av[0] = "HEAD"; + fake_av[1] = NULL; + av = fake_av; + ac = 1; + } if (ac != 1) die("--reflog option needs one branch name"); + if (MAX_REVS < reflog) die("Only %d entries can be shown at one time.", MAX_REVS); @@ -735,6 +742,8 @@ int cmd_show_branch(int ac, const char **av, const char *prefix) append_ref(nth_desc, sha1, 1); } } + else if (all_heads + all_remotes) + snarf_refs(all_heads, all_remotes); else { while (0 < ac) { append_one_rev(*av); From af67e91c39aff2d955e9c325c6c4e843d5faef60 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 25 Jan 2007 22:51:49 -0800 Subject: [PATCH 10/12] Documentation: pack-refs --all vs default behaviour Document the recommended way to prime a repository with tons of references with 'pack-refs --all -prune'. Signed-off-by: Junio C Hamano --- Documentation/git-pack-refs.txt | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index 464269fbb9..a20fc7de40 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -29,12 +29,23 @@ file and used if found. Subsequent updates to branches always creates new file under `$GIT_DIR/refs` hierarchy. +A recommended practice to deal with a repository with too many +refs is to pack its refs with `--all --prune` once, and +occasionally run `git-pack-refs \--prune`. Tags are by +definition stationary and are not expected to change. Branch +heads will be packed with the initial `pack-refs --all`, but +only the currently active branch heads will become unpacked, +and next `pack-refs` (without `--all`) will leave them +unpacked. + + OPTIONS ------- \--all:: -The command by default packs all tags and leaves branch tips +The command by default packs all tags and refs that are already +packed, and leaves other refs alone. This is because branches are expected to be actively developed and packing their tips does not help performance. This option causes branch tips to be packed as well. Useful for From 007e2ba65902b484fc65a313e54594a009841740 Mon Sep 17 00:00:00 2001 From: Jason Riedy Date: Thu, 25 Jan 2007 13:11:40 -0800 Subject: [PATCH 11/12] Use inttypes.h rather than stdint.h. Older Solaris machines lack stdint.h but have inttypes.h. The standard has inttypes.h including stdint.h, so at worst this pollutes the namespace a bit. Signed-off-by: Jason Riedy Signed-off-by: Junio C Hamano --- git-compat-util.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-compat-util.h b/git-compat-util.h index bf3ceb8027..c1bcb001a5 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -46,7 +46,7 @@ #include #include #include -#include +#include #undef _ALL_SOURCE /* AIX 5.3L defines a struct list with _ALL_SOURCE. */ #include #define _ALL_SOURCE 1 From 8a8169c0398ff9996216381d7688c2ba2d007050 Mon Sep 17 00:00:00 2001 From: "Shawn O. Pearce" Date: Thu, 25 Jan 2007 12:40:03 -0500 Subject: [PATCH 12/12] Remove unnecessary found variable from describe. Junio added the found variable to enforce commit date order when two tags have the same distance from the requested commit. Except it is unnecessary as match_cnt is already used to record how many possible tags have been identified thus far. Signed-off-by: Shawn O. Pearce Signed-off-by: Junio C Hamano --- builtin-describe.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin-describe.c b/builtin-describe.c index e7b8f95c81..4921eee9e2 100644 --- a/builtin-describe.c +++ b/builtin-describe.c @@ -101,7 +101,6 @@ static void describe(const char *arg, int last_one) struct possible_tag all_matches[MAX_TAGS]; unsigned int match_cnt = 0, annotated_cnt = 0, cur_match; unsigned long seen_commits = 0; - int found = 0; if (get_sha1(arg, sha1)) die("Not a valid object name %s", arg); @@ -137,7 +136,7 @@ static void describe(const char *arg, int last_one) t->name = n; t->depth = seen_commits - 1; t->flag_within = 1u << match_cnt; - t->found_order = found++; + t->found_order = match_cnt; c->object.flags |= t->flag_within; if (n->prio == 2) annotated_cnt++;