* Re: [JGIT PATCH 2/2] Add getPatchText functions to obtain the plain-text version of a patch
From: Robin Rosenberg @ 2008-12-13 21:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <200812131202.07717.robin.rosenberg.lists@dewire.com>
lördag 13 december 2008 12:02:07 skrev Robin Rosenberg:
> lördag 13 december 2008 03:42:26 skrev Shawn O. Pearce:
> > The conversion from byte[] to String is performed one line at a time,
> > in case the patch is a character encoding conversion patch for the
> > file. For simplicity we currently assume UTF-8 still as the default
> > encoding for any content, but eventually we should support using the
> > .gitattributes encoding property when performing this conversion.
>
> For usefulness we must be able to pass the encoding from outside,
> e.g. the encoding Eclipse uses, which often is not UTF-8-
It's even worse. You should probably do the encoding guess on the whole
patch, or per file and not per line so make success possible at all. Reading
and writing as ISO-8859-1 will always work as that is just padding every
byte with NUL on reading and dropping it on writing. I.e. if your convert
to char at all...
-- robin
^ permalink raw reply
* [PATCH 1/2] gitweb: allow access to forks with strict_export
From: Matt McCutchen @ 2008-12-13 21:16 UTC (permalink / raw)
To: git
git_get_projects_list excludes forks in order to unclutter the main
project list, but this caused the strict_export check, which also relies
on git_get_project_list, to incorrectly fail for forks. This patch adds
an argument so git_get_projects_list knows when it is being called for a
strict_export check (as opposed to a user-visible project list) and
doesn't exclude the forks.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
gitweb/gitweb.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 86511cf..5357bcc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1144,7 +1144,8 @@ sub untabify {
sub project_in_list {
my $project = shift;
- my @list = git_get_projects_list();
+ # Tell git_get_projects_list to include forks.
+ my @list = git_get_projects_list(undef, 1);
return @list && scalar(grep { $_->{'path'} eq $project } @list);
}
@@ -2128,13 +2129,13 @@ sub git_get_project_url_list {
}
sub git_get_projects_list {
- my ($filter) = @_;
+ my ($filter, $for_strict_export) = @_;
my @list;
$filter ||= '';
$filter =~ s/\.git$//;
- my $check_forks = gitweb_check_feature('forks');
+ my $check_forks = !$for_strict_export && gitweb_check_feature('forks');
if (-d $projects_list) {
# search in directory
--
1.6.1.rc2.27.gc7114
^ permalink raw reply related
* [PATCH 2/2] gitweb: support hiding projects from user-visible lists
From: Matt McCutchen @ 2008-12-13 21:16 UTC (permalink / raw)
To: git
In-Reply-To: <4ba6b6c3fc183002407f322663d7ab53c1c28a91.1229202740.git.matt@mattmccutchen.net>
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
My Web site has a single gitweb installation in which some of the
repositories are protected by a basic authentication login. By virtue
of my aforementioned setup with gitweb and pulling at the same URL, the
login applies uniformly to both. I had to include these repositories in
the projects_list because I use strict_export, but I want to hide them
when the user views the project list. This patch implements that
feature, and the previous one fixes a bug I noticed along the way.
Matt
gitweb/gitweb.perl | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5357bcc..085cc60 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1144,7 +1144,7 @@ sub untabify {
sub project_in_list {
my $project = shift;
- # Tell git_get_projects_list to include forks.
+ # Tell git_get_projects_list to include forks and hidden repositories.
my @list = git_get_projects_list(undef, 1);
return @list && scalar(grep { $_->{'path'} eq $project } @list);
}
@@ -2174,15 +2174,18 @@ sub git_get_projects_list {
# 'git%2Fgit.git Linus+Torvalds'
# 'libs%2Fklibc%2Fklibc.git H.+Peter+Anvin'
# 'linux%2Fhotplug%2Fudev.git Greg+Kroah-Hartman'
+ #
+ # 1 in the third field hides the project from user-visible lists, e.g.:
+ # 'linux%2Fembargoed-security-fixes.git John+Doe 1'
my %paths;
open my ($fd), $projects_list or return;
PROJECT:
while (my $line = <$fd>) {
chomp $line;
- my ($path, $owner) = split ' ', $line;
+ my ($path, $owner, $hidden) = split ' ', $line;
$path = unescape($path);
$owner = unescape($owner);
- if (!defined $path) {
+ if (!defined $path || ($hidden && !$for_strict_export)) {
next;
}
if ($filter ne '') {
@@ -2227,6 +2230,8 @@ sub git_get_projects_list {
return @list;
}
+# This is used to look up the owner of a project the user is already allowed to
+# see, so we shouldn't omit hidden repositories.
our $gitweb_project_owner = undef;
sub git_get_project_list_from_file {
@@ -2241,7 +2246,7 @@ sub git_get_project_list_from_file {
open (my $fd , $projects_list);
while (my $line = <$fd>) {
chomp $line;
- my ($pr, $ow) = split ' ', $line;
+ my ($pr, $ow, $hidden) = split ' ', $line;
$pr = unescape($pr);
$ow = unescape($ow);
$gitweb_project_owner->{$pr} = to_utf8($ow);
--
1.6.1.rc2.27.gc7114
^ permalink raw reply related
* [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Matt McCutchen @ 2008-12-13 21:11 UTC (permalink / raw)
To: git
In-Reply-To: <1229195421.3943.8.camel@mattlaptop2.local>
My Web site uses pathinfo mode and some rewrite magic to show the gitweb
interface at the URL of the real repository directory (which users also
pull from). In this case, it's desirable to end generated links to the
project in a trailing slash so the Web server doesn't have to redirect
the client to add the slash. This patch adds a second element to the
"pathinfo" feature configuration to control the trailing slash.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Resending with a sign-off.
gitweb/gitweb.perl | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..86511cf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -270,6 +270,11 @@ our %feature = (
# $feature{'pathinfo'}{'default'} = [1];
# Project specific override is not supported.
+ # If you want a trailing slash on the project path (because, for
+ # example, you have a real directory at that URL and are using
+ # some rewrite magic to invoke gitweb), then set:
+ # $feature{'pathinfo'}{'default'} = [1, 1];
+
# Note that you will need to change the default location of CSS,
# favicon, logo and possibly other files to an absolute URL. Also,
# if gitweb.cgi serves as your indexfile, you will need to force
@@ -829,8 +834,8 @@ sub href (%) {
}
}
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
@@ -845,7 +850,12 @@ sub href (%) {
$href =~ s,/$,,;
# Then add the project name, if present
- $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
+ my $proj_href = undef;
+ if (defined $params{'project'}) {
+ $href .= "/".esc_url($params{'project'});
+ # Save for trailing-slash check below.
+ $proj_href = $href;
+ }
delete $params{'project'};
# since we destructively absorb parameters, we keep this
@@ -903,6 +913,10 @@ sub href (%) {
$href .= $known_snapshot_formats{$fmt}{'suffix'};
delete $params{'snapshot_format'};
}
+
+ # If requested in the configuration, add a trailing slash to a URL that
+ # has nothing appended after the project path.
+ $href .= '/' if ($use_pathinfo[1] && defined $proj_href && $href eq $proj_href);
}
# now encode the parameters explicitly
@@ -2987,13 +3001,15 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
$action .= "/".esc_url($project);
+ # Add a trailing slash if requested in the configuration.
+ $action .= '/' if ($use_pathinfo[1]);
}
print $cgi->startform(-method => "get", -action => $action) .
"<div class=\"search\">\n" .
- (!$use_pathinfo &&
+ (!$use_pathinfo[0] &&
$cgi->input({-name=>"p", -value=>$project, -type=>"hidden"}) . "\n") .
$cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . "\n" .
$cgi->input({-name=>"h", -value=>$search_hash, -type=>"hidden"}) . "\n" .
--
1.6.1.rc2.27.gc7114
^ permalink raw reply related
* [PATCH v3] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-12-13 20:47 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <7viqprzsvs.fsf@gitster.siamese.dyndns.org>
I want directories of my working tree to be linked to from various
paths on my filesystem where third-party components expect them, both
in development and production environments. A build system's install
step could solve this, but we develop scripts and web pages that don't
need to be built. Git's submodule system could solve this, but we
tend to develop, branch, and test those directories all in unison, so
one big repository feels more natural. We prefer to edit and commit
on the symlinked paths, not the canonical ones, and in that setting,
"git pull" fails to find the top-level directory of the working tree
and the .git directory in it.
"git pull" fails because POSIX shells have a notion of current working
directory that is different from getcwd(). The shell stores this path
in PWD. As a result, "cd ../" in a shell script can be interpretted
differently in a shell than chdir("../") in a C program. The shell
interprets "../" by essentially stripping the last textual path
component from PWD, whereas C chdir() follows the ".." link in the
current directory on the filesystem. When PWD is a symlink, these are
different destinations. As a result, Git's C commands find the
correct top-level working tree, and shell scripts do not.
Changes:
* When interpretting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus contrasting scenarios
that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
Hopefully the new commit message adequately describes the problem and
motivation for solving it without getting too long-winded or bogged down
in personal details.
I also removed the "pwd -P" from the unit test. I originally worried
that it was little like testing an algorithm by running it twice and
checking the results against eachother. But I guess having the unit
tests run on unusual platforms is more important.
The pull-symlink test cases should now fail independently. I also
moved the setup out of the test_expect_success block for symetry and
since I see that other tests don't check for setup failure. There's
no "set -e" or anything to catch a setup failure other than the
eventual test cases push/pull not working. So is it good form in this
situation to not check the setup steps for success? Or would it make
sense to put them in their own 'setup' test case? Or would it be better
to just "exit 1" if they fail?
> > +ln -s repo symrepo
> > +test_cd_to_toplevel symrepo 'at symbolic root'
> > +
> > +ln -s repo/sub/dir subdir-link
> > +test_cd_to_toplevel subdir-link 'at symbolic subdir'
> > +
> > +cd repo
> > +ln -s sub/dir internal-link
> > +test_cd_to_toplevel internal-link 'at internal symbolic subdir'
>
> To be very honest, although it is good that you made them work, I am still
> not getting why the latter two scenarios are worth supporting. The first
> one I am Ok with, though.
The middle scenario is the one I want most. I hope the first
paragraph of the commit message sheds more light on the reason.
The third is really just there for completeness (although there are
other cases I didn't include...). Since Git supports operation below
the top-level, and it supports symlinks, it seems useful to test the
cooperation of those features. I wouldn't miss it much if you thought
it was not interesting enough.
> > +
> > +# Prove that the remote end really is a repo, and other commands
> > +# work fine in this context.
> > +#
> > +test_debug "
> > + test_expect_success 'pushing from symlinked subdir' '
> > +
> > + git push
> > + '
> > +"
>
> Why should this be hidden inside test_debug?
I'm not particularly trying to test "git push" or "git pull" in
general here. That's also why the other "git pull" was in a
test_debug. I thought it was really only useful to someone trying to
understand the contents of the test file. There are other files that
cover push and pull. Do you think these test cases should run all the
time here?
git-sh-setup.sh | 23 +++++++++++++-
t/t2300-cd-to-toplevel.sh | 37 +++++++++++++++++++++++
t/t5521-pull-symlink.sh | 73 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 131 insertions(+), 2 deletions(-)
create mode 100755 t/t2300-cd-to-toplevel.sh
create mode 100755 t/t5521-pull-symlink.sh
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..f07d96b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,8 +85,27 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
- cd "$cdup" || {
- echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
+ case "$cdup" in
+ /*)
+ # Not quite the same as if we did "cd -P '$cdup'" when
+ # $cdup contains ".." after symlink path components.
+ # Don't fix that case at least until Git switches to
+ # "cd -P" across the board.
+ phys="$cdup"
+ ;;
+ ..|../*|*/..|*/../*)
+ # Interpret $cdup relative to the physical, not logical, cwd.
+ # Probably /bin/pwd is more portable than passing -P to cd or pwd.
+ phys="$(/bin/pwd)/$cdup"
+ ;;
+ *)
+ # There's no "..", so no need to make things absolute.
+ phys="$cdup"
+ ;;
+ esac
+
+ cd "$phys" || {
+ echo >&2 "Cannot chdir to $phys, the toplevel of the working tree"
exit 1
}
fi
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
new file mode 100755
index 0000000..05854b4
--- /dev/null
+++ b/t/t2300-cd-to-toplevel.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='cd_to_toplevel'
+
+. ./test-lib.sh
+
+test_cd_to_toplevel () {
+ test_expect_success "$2" '
+ (
+ cd '"'$1'"' &&
+ . git-sh-setup &&
+ cd_to_toplevel &&
+ [ "$(pwd -P)" = "$TOPLEVEL" ]
+ )
+ '
+}
+
+TOPLEVEL="$(/bin/pwd)/repo"
+mkdir -p repo/sub/dir
+mv .git repo/
+SUBDIRECTORY_OK=1
+
+test_cd_to_toplevel repo 'at physical root'
+
+test_cd_to_toplevel repo/sub/dir 'at physical subdir'
+
+ln -s repo symrepo
+test_cd_to_toplevel symrepo 'at symbolic root'
+
+ln -s repo/sub/dir subdir-link
+test_cd_to_toplevel subdir-link 'at symbolic subdir'
+
+cd repo
+ln -s sub/dir internal-link
+test_cd_to_toplevel internal-link 'at internal symbolic subdir'
+
+test_done
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100755
index 0000000..8869262
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+
+mkdir subdir
+touch subdir/bar
+git add subdir/bar
+git commit -m empty
+git clone . clone-repo
+ln -s clone-repo/subdir/ subdir-link
+
+
+# Demonstrate that things work if we just avoid the symlink
+#
+test_debug "
+ test_expect_success 'pulling from real subdir' '
+ (
+ cd clone-repo/subdir/ &&
+ git pull
+ )
+ '
+"
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# because git would find the .git/config for the "trash directory"
+# repo, not for the clone-repo repo. The "trash directory" repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. A POSIX shell's "cd" works a little differently
+# than chdir() in C; "cd -P" is much closer to chdir().
+#
+test_expect_success 'pulling from symlinked subdir' '
+ (
+ cd subdir-link/ &&
+ git pull
+ )
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context. It's just that "git pull" breaks.
+#
+test_debug "
+ test_expect_success 'pushing from symlinked subdir' '
+ (
+ cd subdir-link/ &&
+ git push
+ )
+ '
+"
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* [PATCH] pack-objects: don't use too many threads with few objects
From: Nicolas Pitre @ 2008-12-13 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <20081213133238.GA6718@sigill.intra.peff.net>
If there are few objects to deltify, they might be split amongst threads
so that there is simply no other objects left to delta against within
the same thread. Let's use the same 2*window treshold as used for the
final load balancing to allow extra threads to be created.
This fixes the benign t5300 test failure.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Sat, 13 Dec 2008, Jeff King wrote:
> On Thu, Dec 11, 2008 at 03:36:47PM -0500, Nicolas Pitre wrote:
>
> > ... and display the actual number of threads used when locally
> > repacking. A remote server still won't tell you how many threads it
> > uses during a fetch though.
>
> Hrm. I have no idea how, but this patch reliably causes t5300 to fail on
> my FreeBSD test box ("next" is broken, bisection pointed to 43cc2b42).
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 619e597..e851534 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1620,6 +1620,10 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
for (i = 0; i < delta_search_threads; i++) {
unsigned sub_size = list_size / (delta_search_threads - i);
+ /* don't use too small segments or no deltas will be found */
+ if (sub_size < 2*window && i+1 < delta_search_threads)
+ sub_size = 0;
+
p[i].window = window;
p[i].depth = depth;
p[i].processed = processed;
^ permalink raw reply related
* Re: Adding Exit status documentation to all git commands starting with git status
From: Junio C Hamano @ 2008-12-13 20:04 UTC (permalink / raw)
To: nadim khemir; +Cc: git list
In-Reply-To: <200812132036.39318.nadim@khemir.net>
nadim khemir <nadim@khemir.net> writes:
> There are different styles to add exit status, give me your input on why and
> why not using one or the other. I list 3 solutions and what I think about
> them.
No matter what you do, I think EXIT STATUS section should consistently
come near the end of the document, immediately before SEE ALSO, which is
where people who know how manual pages are written expect to find it.
> EXIT STATUS
> -----------
> The command exits with non-zero status if there is no path that is
> different between the index file and the current HEAD commit (i.e.,
> there is nothing to commit by running `git commit`).
Prose is much easier to read as long as it is brief enough, than two-item
enumeration:
> EXIT STATUS
> -----------
> Zero status: There is a different between the index file and HEAD.
> Non-zero status: There is nothing to commit by running `git commit`.
whose use of "Zero status" makes it look doubly funny (traditionally
manual pages do not seem to spell out exit status 0 as "zero", but
"non-zero" is Ok).
Avoid talking about only one side of the condition if you can without
being too verbose.
The command exits with status 0 if there is something to commit by
running `git commit` with corresponding arguments, and non-zero
otherwise.
^ permalink raw reply
* Adding Exit status documentation to all git commands starting with git status
From: nadim khemir @ 2008-12-13 19:36 UTC (permalink / raw)
To: git list
I was asking on the irc channel about how to know if I need to commit. I
promptely got answered but during the discussion, the few of us still awake
in the middle of the night (for me at least), agreed that it would be good to
have a EXIT STATUS in all the commands documentation starting with
the 'status' command.
The current documentation of 'git status' does cover exit status and looks
like:
<original>
...
shows what would be committed if the same options are given to
'git-commit'.
If there is no path that is different between the index file and
the current HEAD commit (i.e., there is nothing to commit by running
`git commit`), the command exits with non-zero status.
OUTPUT
------
</original>
There are different styles to add exit status, give me your input on why and
why not using one or the other. I list 3 solutions and what I think about
them.
<solution 1, least change, easier to recognize although all the negations and
the explaination being about when the command ~fails~ makes newbies head spin
for a few seconds>
...
shows what would be committed if the same options are given to
'git-commit'.
EXIT STATUS
-----------
The command exits with non-zero status if there is no path that is
different between the index file and the current HEAD commit (i.e.,
there is nothing to commit by running `git commit`).
OUTPUT
------
</solution 1>
<solution 2, both zero and non zero status>
...
shows what would be committed if the same options are given to
'git-commit'.
EXIT STATUS
-----------
Zero status: There is a different between the index file and HEAD.
Non-zero status: There is nothing to commit by running `git commit`.
OUTPUT
------
</solution 2>
<solution 3, Only zero status, non zero is easilly deducted. Clearest IMO>
...
shows what would be committed if the same options are given to
'git-commit'.
EXIT STATUS
-----------
Zero status: There is a different between the index and HEAD; running
`git commit` would create a new commit.
OUTPUT
------
</solution 3>
A few things could be better explained:
- The command is to be run with '-a' as option.
- The fact that non add'ed files are not taken into account is not
completely obvious. The first paragraph of the DESCRIPTION explains it but it
is not the clearest explaination ever (maybe because it's not easy to explain
and man pages are references not user manuals)
Cheers, Nadim.
^ permalink raw reply
* Re: [patch] Fix a corner case in git update-index --index-info
From: Junio C Hamano @ 2008-12-13 19:29 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git
In-Reply-To: <200812131403.08740.thomas.jarosch@intra2net.com>
Thomas Jarosch <thomas.jarosch@intra2net.com> writes:
> Fix a corner case in git update-index --index-info:
> If there are no input lines, it won't create an empty index.
>
> Here's a short test for this:
> echo -n "" |GIT_INDEX_FILE=index.new git update-index --index-info
> -> The index "index.new" won't get created
>
> It failed for me while I was using
> git filter-branch as described in the man page:
>
> git filter-branch --index-filter \
> ´git ls-files -s | sed "s-\t-&newsubdir/-" |
> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
> git update-index --index-info &&
> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE´ HEAD
>
> The conversion aborted because the first commit was empty.
> (created by cvs2svn)
If you are doing a filter-branch and the commits near the beginning of the
history did not have any path you are interested in, I do not think you
would want to even create corresponding commits for them that record an
empty tree to begin with, so I do not necessarily agree with the above
command line. The mv would fail due to absense of index.new file, and you
can take it as a sign that you can skip that commit.
Outside the context of your command line above, I am slightly more
sympathetic than neutral to the argument that "update-index --index-info"
(and "update-index --stdin", which I suspect would have the same issue,
but I did not check) should create an output file if one did not exist.
You should note however that such a change would rob from you a way to
detect that you did not feed anything to the command by checking the lack
of the output. Such a change would break people's existing scripts that
relied on the existing behaviour; one example is that the above "The mv
would fail...and you can" would be made impossible.
> @@ -308,6 +309,8 @@ static void read_index_info(int line_termination)
> unsigned long ul;
> int stage;
>
> + found_something = 1;
> +
> /* This reads lines formatted in one of three formats:
> *
> * (1) mode SP sha1 TAB path
> @@ -383,6 +386,11 @@ static void read_index_info(int line_termination)
> bad_line:
> die("malformed index info %s", buf.buf);
> }
> +
> + /* Force creation of empty index - needed by git filter-branch */
As I already mentioned, I do not agree with this "needed by" at all.
> + if (!found_something)
> + active_cache_changed = 1;
> +
> strbuf_release(&buf);
> strbuf_release(&uq);
> }
I think this implementation is conceptually wrong, even if we assume it is
the right thing to always create a new file. The --index-info mode may
well be fed with the same information as it already records, in which case
active_cache_changed shouldn't be toggled, and if it is fed something
different from what is recorded, active_cache_changed should be marked as
changed, and that decision should be left to the add_cache_entry() that is
called from add_cacheinfo(). What you did is to make it _always_ write
the new index out, even if we started with an existing index, and there
was no change, or even if we started with missing index, and there was no
input. You only wanted the latter but you did both.
If that is what you want to do, you can get rid of found_something logic
altogether and flip active_cache_changed unconditionally to do the same
thing, but it feels wrong to write the index out when nothing changed.
Since I said I am slightly more sympathetic than neutral, here is a patch
that forces creation of an empty index file without making it write out
the same thing if the index already existed.
But again, this would break people who have been relying on the existing
behaviour that no resulting file, when GIT_INDEX_FILE points at a
nonexistent file, signals no operation.
I think it is a bad idea to do this in -rc period, even if we were to
change the semantics.
builtin-update-index.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git c/builtin-update-index.c w/builtin-update-index.c
index 65d5775..9abc0b2 100644
--- c/builtin-update-index.c
+++ w/builtin-update-index.c
@@ -566,6 +566,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
char set_executable_bit = 0;
unsigned int refresh_flags = 0;
int lock_error = 0;
+ int was_unborn;
struct lock_file *lock_file;
git_config(git_default_config, NULL);
@@ -580,6 +581,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
entries = read_cache();
if (entries < 0)
die("cache corrupted");
+ was_unborn = is_cache_unborn();
for (i = 1 ; i < argc; i++) {
const char *path = argv[i];
@@ -677,7 +679,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
die("--index-info must be at the end");
allow_add = allow_replace = allow_remove = 1;
read_index_info(line_termination);
- break;
+ goto finish;
}
if (!strcmp(path, "--unresolve")) {
has_errors = do_unresolve(argc - i, argv + i,
@@ -738,7 +740,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
}
finish:
- if (active_cache_changed) {
+ if (active_cache_changed || was_unborn) {
if (newfd < 0) {
if (refresh_flags & REFRESH_QUIET)
exit(128);
^ permalink raw reply related
* Re: [PATCH] autodetect number of CPUs by default when using threads
From: Nicolas Pitre @ 2008-12-13 19:27 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20081213133238.GA6718@sigill.intra.peff.net>
On Sat, 13 Dec 2008, Jeff King wrote:
> On Thu, Dec 11, 2008 at 03:36:47PM -0500, Nicolas Pitre wrote:
>
> > ... and display the actual number of threads used when locally
> > repacking. A remote server still won't tell you how many threads it
> > uses during a fetch though.
>
> Hrm. I have no idea how, but this patch reliably causes t5300 to fail on
> my FreeBSD test box ("next" is broken, bisection pointed to 43cc2b42).
> Sample verbose output is below.
Hmmm... Interesting.
Nicolas
^ permalink raw reply
* [PATCH] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Matt McCutchen @ 2008-12-13 19:10 UTC (permalink / raw)
To: git
My Web site uses pathinfo mode and some rewrite magic to show the gitweb
interface at the URL of the real repository directory (which users also
pull from). In this case, it's desirable to end generated links to the
project in a trailing slash so the Web server doesn't have to redirect
the client to add the slash. This patch adds a second element to the
"pathinfo" feature configuration to control the trailing slash.
---
What do you think of this? I've been using it on my Web site for a
while now.
Matt
gitweb/gitweb.perl | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..86511cf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -270,6 +270,11 @@ our %feature = (
# $feature{'pathinfo'}{'default'} = [1];
# Project specific override is not supported.
+ # If you want a trailing slash on the project path (because, for
+ # example, you have a real directory at that URL and are using
+ # some rewrite magic to invoke gitweb), then set:
+ # $feature{'pathinfo'}{'default'} = [1, 1];
+
# Note that you will need to change the default location of CSS,
# favicon, logo and possibly other files to an absolute URL. Also,
# if gitweb.cgi serves as your indexfile, you will need to force
@@ -829,8 +834,8 @@ sub href (%) {
}
}
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
@@ -845,7 +850,12 @@ sub href (%) {
$href =~ s,/$,,;
# Then add the project name, if present
- $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
+ my $proj_href = undef;
+ if (defined $params{'project'}) {
+ $href .= "/".esc_url($params{'project'});
+ # Save for trailing-slash check below.
+ $proj_href = $href;
+ }
delete $params{'project'};
# since we destructively absorb parameters, we keep this
@@ -903,6 +913,10 @@ sub href (%) {
$href .= $known_snapshot_formats{$fmt}{'suffix'};
delete $params{'snapshot_format'};
}
+
+ # If requested in the configuration, add a trailing slash to a URL that
+ # has nothing appended after the project path.
+ $href .= '/' if ($use_pathinfo[1] && defined $proj_href && $href eq $proj_href);
}
# now encode the parameters explicitly
@@ -2987,13 +3001,15 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
$action .= "/".esc_url($project);
+ # Add a trailing slash if requested in the configuration.
+ $action .= '/' if ($use_pathinfo[1]);
}
print $cgi->startform(-method => "get", -action => $action) .
"<div class=\"search\">\n" .
- (!$use_pathinfo &&
+ (!$use_pathinfo[0] &&
$cgi->input({-name=>"p", -value=>$project, -type=>"hidden"}) . "\n") .
$cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . "\n" .
$cgi->input({-name=>"h", -value=>$search_hash, -type=>"hidden"}) . "\n" .
--
1.6.1.rc2.24.gf17b3c.dirty
^ permalink raw reply related
* [PATCH] bash completion: remove deprecated --prune from git-gc
From: Markus Heidelberg @ 2008-12-13 19:08 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c79c98f..9e0c48b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -835,7 +835,7 @@ _git_gc ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
- __gitcomp "--prune --aggressive"
+ __gitcomp "--aggressive"
return
;;
esac
--
1.6.1.rc1.54.gd1643
^ permalink raw reply related
* Re: Optimizing cloning of a high object count repository
From: Nicolas Pitre @ 2008-12-13 18:56 UTC (permalink / raw)
To: Resul Cetin; +Cc: git, Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <200812131714.05472.Resul-Cetin@gmx.net>
On Sat, 13 Dec 2008, Resul Cetin wrote:
> On Saturday 13 December 2008 16:46:50 you wrote:
> [...]
> > > The size of the linux repository seems to be smaller but in the same
> > > range object count and repository size but clones are much much faster.
> > > Is there any way to optimize the server operations like counting and
> > > compressing of objects to get the same speed as we get from
> > > git.kernel.org (which does it in nearly no time and the only limiting
> > > factor seems to be my bandwith)?
> > > The only other information I have is that Robin H. Johnson made a single
> > > ~910MiB pack for the whole repository.
> >
> > Make yearly packed repository snapshots and publish them via http.
> > People can wget the latest snapshot, then pull updates later.
> That would be a workaround but it doesn't explain why git.kernel.org deliveres
> torvalds repository without any notable counting and compressing time. Maybe
> it has something todo with the config I found inside the repository:
> http://git.overlays.gentoo.org/gitroot/exp/gentoo-x86.git/config
> It says that it isnt a bare repository.
That's not relevant.
The counting time is a bit unfortunate (although I have plans to speed
that up, if only I can find the time).
You should be able to skip the compression time entirely though, if you
do repack the repository first. And you want it to be as tightly packed
as possible for public access. I'm currently cloning it and the
counting phase is not _that_ bad compared to the compression phase. Try
something like 'git repack -a -f -d --window=200' and let it run
overnight if necessary. You need to do this only once, and preferably
on a machine with lots of RAM, and preferably on a 64-bit machine. Once
this is done then things should go much more smoothly afterwards.
Nicolas
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Resul Cetin @ 2008-12-13 18:20 UTC (permalink / raw)
To: git; +Cc: Jean-Luc Herren, Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <4943E657.9040204@gmx.ch>
On Saturday 13 December 2008 17:44:07 you wrote:
> Resul Cetin wrote:
> > That would be a workaround but it doesn't explain why git.kernel.org
> > deliveres torvalds repository without any notable counting and
> > compressing time.
>
> If I remember right, git.kernel.org is a quite beefy machine. But
> then again it has a lot more traffic too. It might be interesting
> to know what machine you're on, compared to git.kernel.org.
I dont know what type of machine git.overlay.g.o is but my athlon64 3500+ with
4GB ram has exactly the same problem without any other load. I made a clone
over http and did no other changes to the repository until now.
http://git.overlays.gentoo.org/gitroot/exp/gentoo-x86.git/ is the http clone
url.
I will try some stuff to reduce the time spend before sending anything..... If
anyone has some ideas how to do that....
Regards,
Resul
^ permalink raw reply
* [PATCH] Let git remote accept up as alias to update
From: Alexey Zaytsev @ 2008-12-13 18:18 UTC (permalink / raw)
To: git
Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
---
Don't know why, but I keep typing remote up instead of
remote update. As update is probably by far the most
used remote action, can we please have this alias?
builtin-remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index abc8dd8..8f5cd6d 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -893,7 +893,7 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show(argc, argv);
else if (!strcmp(argv[0], "prune"))
result = prune(argc, argv);
- else if (!strcmp(argv[0], "update"))
+ else if (!strcmp(argv[0], "update") || !strcmp(argv[0], "up"))
result = update(argc, argv);
else {
error("Unknown subcommand: %s", argv[0]);
^ permalink raw reply related
* Re: is gitosis secure?
From: Sverre Rabbelier @ 2008-12-13 18:07 UTC (permalink / raw)
To: Nix; +Cc: Thomas Koch, Git Mailing List, dabe
In-Reply-To: <87hc58hwmi.fsf@hades.wkstn.nix>
On Sat, Dec 13, 2008 at 17:23, Nix <nix@esperi.org.uk> wrote:
> telnet. I do not jest, this is our sysadmins' stated reasons for not
> opening the git port and for tweaking their (mandatory) HTTP proxy to
> block HTTP traffic from git.
I don't know what to say to this :P.
> (Telnet over some horrible impossibly slow buggy proprietary VPN.
> It takes >5min to bring up a single connection.)
I feel for you man, try and get that guy fired and have them hire some
_real_ sysadmins!
> Do not underestimate the stupidity and hideboundedness of undertrained
> system administrators, for it is vast.
This is beyond doubt.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: is gitosis secure?
From: Nix @ 2008-12-13 16:23 UTC (permalink / raw)
To: sverre; +Cc: Thomas Koch, Git Mailing List, dabe
In-Reply-To: <bd6139dc0812090138l5dbaf20bsd1cde00f52bb94e5@mail.gmail.com>
On 9 Dec 2008, Sverre Rabbelier spake thusly:
> On Tue, Dec 9, 2008 at 09:56, Thomas Koch <thomas@koch.ro> wrote:
>> Our admin would prefer to not open SSH at all outside our LAN, but
>> developers would need to have write access also outside the office.
>
> What safer to connect to the LAN than with SSH? What _would_ your
> system admin be happy with using?
telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.
(Telnet over some horrible impossibly slow buggy proprietary VPN.
It takes >5min to bring up a single connection.)
Do not underestimate the stupidity and hideboundedness of undertrained
system administrators, for it is vast.
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Jean-Luc Herren @ 2008-12-13 16:44 UTC (permalink / raw)
To: git; +Cc: Resul Cetin, Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <200812131714.05472.Resul-Cetin@gmx.net>
Resul Cetin wrote:
> That would be a workaround but it doesn't explain why git.kernel.org deliveres
> torvalds repository without any notable counting and compressing time.
If I remember right, git.kernel.org is a quite beefy machine. But
then again it has a lot more traffic too. It might be interesting
to know what machine you're on, compared to git.kernel.org.
jlh
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Resul Cetin @ 2008-12-13 16:14 UTC (permalink / raw)
To: git; +Cc: Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <fcaeb9bf0812130746l38a12f37wde26f31d5fa0d2a2@mail.gmail.com>
On Saturday 13 December 2008 16:46:50 you wrote:
[...]
> > The size of the linux repository seems to be smaller but in the same
> > range object count and repository size but clones are much much faster.
> > Is there any way to optimize the server operations like counting and
> > compressing of objects to get the same speed as we get from
> > git.kernel.org (which does it in nearly no time and the only limiting
> > factor seems to be my bandwith)?
> > The only other information I have is that Robin H. Johnson made a single
> > ~910MiB pack for the whole repository.
>
> Make yearly packed repository snapshots and publish them via http.
> People can wget the latest snapshot, then pull updates later.
That would be a workaround but it doesn't explain why git.kernel.org deliveres
torvalds repository without any notable counting and compressing time. Maybe
it has something todo with the config I found inside the repository:
http://git.overlays.gentoo.org/gitroot/exp/gentoo-x86.git/config
It says that it isnt a bare repository.
Before I forget. I was wrong that it is a single 910mb file. Somebody seems to
have repacked it into 7 single packs.
Regards,
Resul
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Nguyen Thai Ngoc Duy @ 2008-12-13 15:46 UTC (permalink / raw)
To: Resul Cetin; +Cc: git, gentoo-scm
In-Reply-To: <200812131624.57618.Resul-Cetin@gmx.net>
On 12/13/08, Resul Cetin <Resul-Cetin@gmx.net> wrote:
> Hi,
> there are currently different ideas to move gentoo's cvs repository to an
> other scm. Current tests showed that svn will not make anything better (it
> gets in most perfomance and size based benchmarks even worse). Another idea is
> to move to git. It looks really promising in size based benchmarks but cloning
> seems nearly impossible. The current test repository is available at
> git://git.overlays.gentoo.org/exp/gentoo-x86.git and is around 900MB in size
> and has 4696137 objects. It really takes ages to do the counting of the
> objects on the server and compressing takes much longer.
> The size of the linux repository seems to be smaller but in the same range
> object count and repository size but clones are much much faster. Is there any
> way to optimize the server operations like counting and compressing of objects
> to get the same speed as we get from git.kernel.org (which does it in nearly
> no time and the only limiting factor seems to be my bandwith)?
> The only other information I have is that Robin H. Johnson made a single
> ~910MiB pack for the whole repository.
Make yearly packed repository snapshots and publish them via http.
People can wget the latest snapshot, then pull updates later.
--
Duy
^ permalink raw reply
* Optimizing cloning of a high object count repository
From: Resul Cetin @ 2008-12-13 15:24 UTC (permalink / raw)
To: git; +Cc: gentoo-scm
Hi,
there are currently different ideas to move gentoo's cvs repository to an
other scm. Current tests showed that svn will not make anything better (it
gets in most perfomance and size based benchmarks even worse). Another idea is
to move to git. It looks really promising in size based benchmarks but cloning
seems nearly impossible. The current test repository is available at
git://git.overlays.gentoo.org/exp/gentoo-x86.git and is around 900MB in size
and has 4696137 objects. It really takes ages to do the counting of the
objects on the server and compressing takes much longer.
The size of the linux repository seems to be smaller but in the same range
object count and repository size but clones are much much faster. Is there any
way to optimize the server operations like counting and compressing of objects
to get the same speed as we get from git.kernel.org (which does it in nearly
no time and the only limiting factor seems to be my bandwith)?
The only other information I have is that Robin H. Johnson made a single
~910MiB pack for the whole repository.
Thx in advance,
Resul
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Tim Visher @ 2008-12-13 14:21 UTC (permalink / raw)
To: 李智; +Cc: git
In-Reply-To: <1976ea660812130033m2d54cc57tfe134fab0d687d71@mail.gmail.com>
On Sat, Dec 13, 2008 at 3:33 AM, 李智 <lznuaa@gmail.com> wrote:
> TortoiseGit is porting from TortoiseSVN.
Thanks so much for this!
My team and I were just talking about how the biggest barrier to entry
at this point for _some_ of us has been the lack of a great tool like
Tortoise for Git. My opinion was that someone would soon write it.
And lo-and-behold, here it is!
I'll look forward to watching this progress, and continue happily
using my cli version the same.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] autodetect number of CPUs by default when using threads
From: Jeff King @ 2008-12-13 13:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0812111524370.14328@xanadu.home>
On Thu, Dec 11, 2008 at 03:36:47PM -0500, Nicolas Pitre wrote:
> ... and display the actual number of threads used when locally
> repacking. A remote server still won't tell you how many threads it
> uses during a fetch though.
Hrm. I have no idea how, but this patch reliably causes t5300 to fail on
my FreeBSD test box ("next" is broken, bisection pointed to 43cc2b42).
Sample verbose output is below.
-- >8 --
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* expecting success: rm -f .git/index*
for i in a b c
do
dd if=/dev/zero bs=4k count=1 | perl -pe "y/\\000/$i/" >$i &&
git update-index --add $i || return 1
done &&
cat c >d && echo foo >>d && git update-index --add d &&
tree=`git write-tree` &&
commit=`git commit-tree $tree </dev/null` && {
echo $tree &&
echo $commit &&
git ls-tree $tree | sed -e "s/.* \\([0-9a-f]*\\) .*/\\1/"
} >obj-list && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >expect
1+0 records in
1+0 records out
4096 bytes transferred in 0.000059 secs (69273666 bytes/sec)
1+0 records in
1+0 records out
4096 bytes transferred in 0.000053 secs (77386798 bytes/sec)
1+0 records in
1+0 records out
4096 bytes transferred in 0.000055 secs (74695083 bytes/sec)
* ok 1: setup
* expecting success: packname_1=$(git pack-objects --window=0 test-1 <obj-list)
* ok 2: pack without delta
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
git unpack-objects -n <test-1-20f53d0edce6980dfa341c034ae365aef2616e8d.pack &&
git unpack-objects <test-1-20f53d0edce6980dfa341c034ae365aef2616e8d.pack
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 3: unpack without delta
* expecting success: (cd ../.git && find objects -type f -print) |
while read path
do
cmp $path ../.git/$path || {
echo $path differs.
return 1
}
done
* ok 4: check unpack without delta
* expecting success: pwd &&
packname_2=$(git pack-objects test-2 <obj-list)
/home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object
* ok 5: pack with REF_DELTA
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
git unpack-objects -n <test-2-${packname_2}.pack &&
git unpack-objects <test-2-${packname_2}.pack
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 6: unpack with REF_DELTA
* expecting success: (cd ../.git && find objects -type f -print) |
while read path
do
cmp $path ../.git/$path || {
echo $path differs.
return 1
}
done
* ok 7: check unpack with REF_DELTA
* expecting success: pwd &&
packname_3=$(git pack-objects --delta-base-offset test-3 <obj-list)
/home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object
* ok 8: pack with OFS_DELTA
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
git unpack-objects -n <test-3-${packname_3}.pack &&
git unpack-objects <test-3-${packname_3}.pack
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 9: unpack with OFS_DELTA
* expecting success: (cd ../.git && find objects -type f -print) |
while read path
do
cmp $path ../.git/$path || {
echo $path differs.
return 1
}
done
* ok 10: check unpack with OFS_DELTA
* expecting success:
perl -e '
defined($_ = -s $_) or die for @ARGV;
exit 1 if $ARGV[0] <= $ARGV[1];
' test-2-$packname_2.pack test-3-$packname_3.pack
* FAIL 11: compare delta flavors
perl -e '
defined($_ = -s $_) or die for @ARGV;
exit 1 if $ARGV[0] <= $ARGV[1];
' test-2-$packname_2.pack test-3-$packname_3.pack
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
cp test-1-${packname_1}.pack test-1-${packname_1}.idx .git2/objects/pack && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >current &&
diff expect current
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 12: use packed objects
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
rm -f .git2/objects/pack/test-* &&
cp test-2-${packname_2}.pack test-2-${packname_2}.idx .git2/objects/pack && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >current &&
diff expect current
* ok 13: use packed deltified (REF_DELTA) objects
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
rm -f .git2/objects/pack/test-* &&
cp test-3-${packname_3}.pack test-3-${packname_3}.idx .git2/objects/pack && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >current &&
diff expect current
* ok 14: use packed deltified (OFS_DELTA) objects
* expecting success: git verify-pack test-1-${packname_1}.idx \
test-2-${packname_2}.idx \
test-3-${packname_3}.idx
* ok 15: verify pack
* expecting success: git verify-pack -v test-1-${packname_1}.idx \
test-2-${packname_2}.idx \
test-3-${packname_3}.idx
0be779221aca65277fd447c8207e1b3c2706ae20 blob 4096 31 311
2f22df7b2a002e7e84bd7c124483f0df7f7bc1ef commit 163 121 128
890b180ae96f7abd6a1917dee506bceb188003b6 tree 116 116 12
9d235ed07cd19811a6ceb342de82f190e49c9f68 blob 4096 31 249
b010fe5253f7dc59c6605dacb92fcea00d199d4e blob 4100 36 342
c82de19312b6c3695c0c18f70709a6c535682a67 blob 4096 31 280
test-1-20f53d0edce6980dfa341c034ae365aef2616e8d.pack: ok
0be779221aca65277fd447c8207e1b3c2706ae20 blob 4096 31 311
2f22df7b2a002e7e84bd7c124483f0df7f7bc1ef commit 163 121 128
890b180ae96f7abd6a1917dee506bceb188003b6 tree 116 116 12
9d235ed07cd19811a6ceb342de82f190e49c9f68 blob 4096 31 249
b010fe5253f7dc59c6605dacb92fcea00d199d4e blob 4100 36 342
c82de19312b6c3695c0c18f70709a6c535682a67 blob 4096 31 280
test-2-20f53d0edce6980dfa341c034ae365aef2616e8d.pack: ok
0be779221aca65277fd447c8207e1b3c2706ae20 blob 4096 31 311
2f22df7b2a002e7e84bd7c124483f0df7f7bc1ef commit 163 121 128
890b180ae96f7abd6a1917dee506bceb188003b6 tree 116 116 12
9d235ed07cd19811a6ceb342de82f190e49c9f68 blob 4096 31 249
b010fe5253f7dc59c6605dacb92fcea00d199d4e blob 4100 36 342
c82de19312b6c3695c0c18f70709a6c535682a67 blob 4096 31 280
test-3-20f53d0edce6980dfa341c034ae365aef2616e8d.pack: ok
* ok 16: verify pack -v
* expecting success: cat test-1-${packname_1}.idx >test-3.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
if git verify-pack test-3.idx
then false
else :;
fi
* FAIL 17: verify-pack catches mismatched .idx and .pack files
cat test-1-${packname_1}.idx >test-3.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
if git verify-pack test-3.idx
then false
else :;
fi
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=2 &&
if git verify-pack test-3.idx
then false
else :;
fi
1+0 records in
1+0 records out
1 bytes transferred in 0.000042 secs (23831 bytes/sec)
error: file test-3.pack is not a GIT packfile
fatal: packfile test-3.pack cannot be accessed
* ok 18: verify-pack catches a corrupted pack signature
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=7 &&
if git verify-pack test-3.idx
then false
else :;
fi
1+0 records in
1+0 records out
1 bytes transferred in 0.000042 secs (23831 bytes/sec)
error: packfile test-3.pack is version 0 and not supported (try upgrading GIT to a newer version)
fatal: packfile test-3.pack cannot be accessed
* ok 19: verify-pack catches a corrupted pack version
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=12 &&
if git verify-pack test-3.idx
then false
else :;
fi
1+0 records in
1+0 records out
1 bytes transferred in 0.000046 secs (21732 bytes/sec)
error: test-3.pack SHA1 checksum mismatch
error: index CRC mismatch for object 890b180ae96f7abd6a1917dee506bceb188003b6 from test-3.pack at offset 12
error: unknown object type 0 at offset 12 in test-3.pack
error: cannot unpack 890b180ae96f7abd6a1917dee506bceb188003b6 from test-3.pack at offset 12
* ok 20: verify-pack catches a corrupted type/size of the 1st packed object data
* expecting success: l=`wc -c <test-3.idx` &&
l=`expr $l - 20` &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.idx count=20 bs=1 conv=notrunc seek=$l &&
if git verify-pack test-3.pack
then false
else :;
fi
20+0 records in
20+0 records out
20 bytes transferred in 0.000123 secs (162570 bytes/sec)
error: Packfile index for test-3.pack SHA1 mismatch
* ok 21: verify-pack catches a corrupted sum of the index file itself
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
git index-pack -o tmp.idx test-3.pack &&
cmp tmp.idx test-1-${packname_1}.idx &&
git index-pack test-3.pack &&
cmp test-3.idx test-1-${packname_1}.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
git index-pack -o tmp.idx test-2-${packname_2}.pack &&
cmp tmp.idx test-2-${packname_2}.idx &&
git index-pack test-3.pack &&
cmp test-3.idx test-2-${packname_2}.idx &&
cat test-3-${packname_3}.pack >test-3.pack &&
git index-pack -o tmp.idx test-3-${packname_3}.pack &&
cmp tmp.idx test-3-${packname_3}.idx &&
git index-pack test-3.pack &&
cmp test-3.idx test-3-${packname_3}.idx &&
:
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
* ok 22: build pack index for an existing pack
* expecting success: test -f .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67 &&
cp -f .git/objects/9d/235ed07cd19811a6ceb342de82f190e49c9f68 \
.git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67
* ok 23: fake a SHA1 hash collision
* expecting success: test_must_fail git index-pack -o bad.idx test-3.pack 2>msg &&
grep "SHA1 COLLISION FOUND" msg
fatal: SHA1 COLLISION FOUND WITH c82de19312b6c3695c0c18f70709a6c535682a67 !
* ok 24: make sure index-pack detects the SHA1 collision
* expecting success: git config pack.packSizeLimit 200 &&
packname_4=$(git pack-objects test-4 <obj-list) &&
test 3 = $(ls test-4-*.pack | wc -l)
* ok 25: honor pack.packSizeLimit
* expecting success:
git config --unset pack.packsizelimit &&
for j in a b c d e f g
do
for i in 0 1 2 3 4 5 6 7 8 9
do
o=$(echo $j$i | git hash-object -w --stdin) &&
echo "100644 $o 0 $j$i"
done
done >LIST &&
rm -f .git/index &&
git update-index --index-info <LIST &&
LIST=$(git write-tree) &&
rm -f .git/index &&
head -n 10 LIST | git update-index --index-info &&
LI=$(git write-tree) &&
rm -f .git/index &&
tail -n 10 LIST | git update-index --index-info &&
ST=$(git write-tree) &&
PACK5=$( git rev-list --objects "$LIST" "$LI" "$ST" | \
git pack-objects test-5 ) &&
PACK6=$( (
echo "$LIST"
echo "$LI"
echo "$ST"
) | git pack-objects test-6 ) &&
test_create_repo test-5 &&
(
cd test-5 &&
git unpack-objects --strict <../test-5-$PACK5.pack &&
git ls-tree -r $LIST &&
git ls-tree -r $LI &&
git ls-tree -r $ST
) &&
test_create_repo test-6 &&
(
# tree-only into empty repo -- many unreachables
cd test-6 &&
test_must_fail git unpack-objects --strict <../test-6-$PACK6.pack
) &&
(
# already populated -- no unreachables
cd test-5 &&
git unpack-objects --strict <../test-6-$PACK6.pack
)
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-5/.git/
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2270a80fbb71d7109b85e7489f3f307d0141a559 0 b0
100644 blob c9c6af7f78bc47490dbf3e822cf2f3c24d4b9061 0 b1
100644 blob e6bfff5c1d0f0ecd501552b43a1e13d8008abc31 0 b2
100644 blob 6d0875c82a99774922eab07fbc08510fc85d9e0a 0 b3
100644 blob 8e953e84d803f13fd06416a1bd8161dcd93cfd00 0 b4
100644 blob 90a5159bf020296276ea5ca1bcd292a9b1de9947 0 b5
100644 blob 07eb61d36f49569a2b0649af299f9f00013d0969 0 b6
100644 blob 6e6d33cfc7b1581413a88ae0759202b25ac4cad1 0 b7
100644 blob 5d453c66b522d8de5d99c03bd2bf8b65ca0bcf33 0 b8
100644 blob 9a16e0d1a643983973291127012d2694a0b17fe8 0 b9
100644 blob caecf05cdbb03e144f113ecab2b99e5ee74df706 0 c0
100644 blob ae9304576a6ec3419b231b2b9c8e33a06f97f9fb 0 c1
100644 blob 16f9ec009e5568c435f473ba3a1df732d49ce8c3 0 c2
100644 blob 0771aea884dd394a7b12783d049f05b5599f41a4 0 c3
100644 blob a103f673dd1b7c5727aa0ae0100419adc50e1b76 0 c4
100644 blob c36357109ce20af8f90df3c0dd0784e89408d707 0 c5
100644 blob 86a716504cbdc40a135faa5ab199d15e364c416d 0 c6
100644 blob 20be68787e59f4cb8983b641d170c4baf8ea25dd 0 c7
100644 blob bb420bc8fb9e91530fdc25e363f6b822d5195309 0 c8
100644 blob f899bd1761a5ca5978799bc3189a04d3c52d8435 0 c9
100644 blob 79a5e858be4a3a969e3b71406fef0d3d36e1d387 0 d0
100644 blob 6f1852975b9306ae5d8dfdf0d4cb1f5cb36ac229 0 d1
100644 blob fd3671590780b645e1bef030d550191f6cdf1c95 0 d2
100644 blob 69c77a9ea746edd27b46107142fc2c5288c1daf5 0 d3
100644 blob d7b30ee07d4b9819a77a3b122282b4c04528ec21 0 d4
100644 blob fa590f3f8bfbef6095cf6525e8497b2b2b46445c 0 d5
100644 blob fef4390d19cb98fa97efd44c09d4e2eb7b084b40 0 d6
100644 blob a5adf29249757619b8890c86f2cfcfeee611b5d8 0 d7
100644 blob 1859919d049c078ba63fcecbce60e697c6da8e01 0 d8
100644 blob b6148c82443a60d1d5ce07872a85e3c544b5f4b0 0 d9
100644 blob 4fe4106b50b257f3d6ffd23b750d2d1945c2608b 0 e0
100644 blob 5ff91639494693b1f238b5dc9baf8be95142c3ab 0 e1
100644 blob 3811af3ca744c2fb44077a8025c23b4d4166a449 0 e2
100644 blob 9338c3fa1f74d202651154257572d32aed57cc16 0 e3
100644 blob c5195815f83aa9ef1ebac9e11f14d62b26406c99 0 e4
100644 blob 0c44c89ef9c29077cceebc6dd9ca0b3a950c95ee 0 e5
100644 blob f17172bc54cfa55a9e531cc845dff39855cd8df0 0 e6
100644 blob 29870e9ccff84f86938ee588a47b39cf3a802e6b 0 e7
100644 blob e8d01d007452cede5c6eafc3343fc80675b1e2f9 0 e8
100644 blob 0c1945ad576ffc445ad69a3fafd1d3c04cc0bd40 0 e9
100644 blob 844dc808a1d3d769ddcf5430eac933d4d87ff606 0 f0
100644 blob 8e1e71d5ce34c01b6fe83bc5051545f2918c8c2b 0 f1
100644 blob 9de77c18733ab8009a956c25e28c85fe203a17d7 0 f2
100644 blob 45d9e0e9fc8859787c33081dffdf12f41b54fcf3 0 f3
100644 blob c48ac4847d3abae8e5899dcc5cf490a98df55755 0 f4
100644 blob 14c61ecf25961ce674048103c5fa5ea3c535a5cd 0 f5
100644 blob 59ce90029dfd9e224701a040a26153e9f2feb74c 0 f6
100644 blob 0a7bd52ffb819609cf65f40eb91be62000db47e5 0 f7
100644 blob c7e617f6b429a1f3b462df6add2b4ea2cf702faf 0 f8
100644 blob a720d8c8d277ad31ee5b180bef57379b5f62517c 0 f9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-6/.git/
error: unable to find 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02
fatal: object of unexpected type
* ok 26: unpacking with --strict
* expecting success:
for j in a b c d e f g
do
for i in 0 1 2 3 4 5 6 7 8 9
do
o=$(echo $j$i | git hash-object -w --stdin) &&
echo "100644 $o 0 $j$i"
done
done >LIST &&
rm -f .git/index &&
git update-index --index-info <LIST &&
LIST=$(git write-tree) &&
rm -f .git/index &&
head -n 10 LIST | git update-index --index-info &&
LI=$(git write-tree) &&
rm -f .git/index &&
tail -n 10 LIST | git update-index --index-info &&
ST=$(git write-tree) &&
PACK5=$( git rev-list --objects "$LIST" "$LI" "$ST" | \
git pack-objects test-5 ) &&
PACK6=$( (
echo "$LIST"
echo "$LI"
echo "$ST"
) | git pack-objects test-6 ) &&
test_create_repo test-7 &&
(
cd test-7 &&
git index-pack --strict --stdin <../test-5-$PACK5.pack &&
git ls-tree -r $LIST &&
git ls-tree -r $LI &&
git ls-tree -r $ST
) &&
test_create_repo test-8 &&
(
# tree-only into empty repo -- many unreachables
cd test-8 &&
test_must_fail git index-pack --strict --stdin <../test-6-$PACK6.pack
) &&
(
# already populated -- no unreachables
cd test-7 &&
git index-pack --strict --stdin <../test-6-$PACK6.pack
)
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-7/.git/
pack df7e2e394127cb487b2a6904a9a3fa45be4d4199
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2270a80fbb71d7109b85e7489f3f307d0141a559 0 b0
100644 blob c9c6af7f78bc47490dbf3e822cf2f3c24d4b9061 0 b1
100644 blob e6bfff5c1d0f0ecd501552b43a1e13d8008abc31 0 b2
100644 blob 6d0875c82a99774922eab07fbc08510fc85d9e0a 0 b3
100644 blob 8e953e84d803f13fd06416a1bd8161dcd93cfd00 0 b4
100644 blob 90a5159bf020296276ea5ca1bcd292a9b1de9947 0 b5
100644 blob 07eb61d36f49569a2b0649af299f9f00013d0969 0 b6
100644 blob 6e6d33cfc7b1581413a88ae0759202b25ac4cad1 0 b7
100644 blob 5d453c66b522d8de5d99c03bd2bf8b65ca0bcf33 0 b8
100644 blob 9a16e0d1a643983973291127012d2694a0b17fe8 0 b9
100644 blob caecf05cdbb03e144f113ecab2b99e5ee74df706 0 c0
100644 blob ae9304576a6ec3419b231b2b9c8e33a06f97f9fb 0 c1
100644 blob 16f9ec009e5568c435f473ba3a1df732d49ce8c3 0 c2
100644 blob 0771aea884dd394a7b12783d049f05b5599f41a4 0 c3
100644 blob a103f673dd1b7c5727aa0ae0100419adc50e1b76 0 c4
100644 blob c36357109ce20af8f90df3c0dd0784e89408d707 0 c5
100644 blob 86a716504cbdc40a135faa5ab199d15e364c416d 0 c6
100644 blob 20be68787e59f4cb8983b641d170c4baf8ea25dd 0 c7
100644 blob bb420bc8fb9e91530fdc25e363f6b822d5195309 0 c8
100644 blob f899bd1761a5ca5978799bc3189a04d3c52d8435 0 c9
100644 blob 79a5e858be4a3a969e3b71406fef0d3d36e1d387 0 d0
100644 blob 6f1852975b9306ae5d8dfdf0d4cb1f5cb36ac229 0 d1
100644 blob fd3671590780b645e1bef030d550191f6cdf1c95 0 d2
100644 blob 69c77a9ea746edd27b46107142fc2c5288c1daf5 0 d3
100644 blob d7b30ee07d4b9819a77a3b122282b4c04528ec21 0 d4
100644 blob fa590f3f8bfbef6095cf6525e8497b2b2b46445c 0 d5
100644 blob fef4390d19cb98fa97efd44c09d4e2eb7b084b40 0 d6
100644 blob a5adf29249757619b8890c86f2cfcfeee611b5d8 0 d7
100644 blob 1859919d049c078ba63fcecbce60e697c6da8e01 0 d8
100644 blob b6148c82443a60d1d5ce07872a85e3c544b5f4b0 0 d9
100644 blob 4fe4106b50b257f3d6ffd23b750d2d1945c2608b 0 e0
100644 blob 5ff91639494693b1f238b5dc9baf8be95142c3ab 0 e1
100644 blob 3811af3ca744c2fb44077a8025c23b4d4166a449 0 e2
100644 blob 9338c3fa1f74d202651154257572d32aed57cc16 0 e3
100644 blob c5195815f83aa9ef1ebac9e11f14d62b26406c99 0 e4
100644 blob 0c44c89ef9c29077cceebc6dd9ca0b3a950c95ee 0 e5
100644 blob f17172bc54cfa55a9e531cc845dff39855cd8df0 0 e6
100644 blob 29870e9ccff84f86938ee588a47b39cf3a802e6b 0 e7
100644 blob e8d01d007452cede5c6eafc3343fc80675b1e2f9 0 e8
100644 blob 0c1945ad576ffc445ad69a3fafd1d3c04cc0bd40 0 e9
100644 blob 844dc808a1d3d769ddcf5430eac933d4d87ff606 0 f0
100644 blob 8e1e71d5ce34c01b6fe83bc5051545f2918c8c2b 0 f1
100644 blob 9de77c18733ab8009a956c25e28c85fe203a17d7 0 f2
100644 blob 45d9e0e9fc8859787c33081dffdf12f41b54fcf3 0 f3
100644 blob c48ac4847d3abae8e5899dcc5cf490a98df55755 0 f4
100644 blob 14c61ecf25961ce674048103c5fa5ea3c535a5cd 0 f5
100644 blob 59ce90029dfd9e224701a040a26153e9f2feb74c 0 f6
100644 blob 0a7bd52ffb819609cf65f40eb91be62000db47e5 0 f7
100644 blob c7e617f6b429a1f3b462df6add2b4ea2cf702faf 0 f8
100644 blob a720d8c8d277ad31ee5b180bef57379b5f62517c 0 f9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-8/.git/
error: unable to find 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02
fatal: object of unexpected type
pack f67e682280757d6079b87511ea590015d0e26770
* ok 27: index-pack with --strict
* expecting success:
git config pack.packSizeLimit 2 &&
packname_9=$(git pack-objects test-9 <obj-list) &&
test $(wc -l <obj-list) = $(ls test-9-*.pack | wc -l)
* ok 28: tolerate absurdly small packsizelimit
* failed 2 among 28 test(s)
^ permalink raw reply
* Re: Saving patches from this list
From: Stefan Näwe @ 2008-12-13 13:28 UTC (permalink / raw)
To: git
In-Reply-To: <20081212151419.GL32487@spearce.org>
Shawn O. Pearce <spearce <at> spearce.org> writes:
> > > > > What's the best way to get patches sent to this list in a form suitable
> > > > > for 'git am' without subscribing to this list ?
>
> If you find the article on the web with gmane, add '/raw' onto the
> end of direct link URL. E.g. to get:
>
> http://article.gmane.org/gmane.comp.version-control.git/102874
>
> use:
>
> curl http://article.gmane.org/gmane.comp.version-control.git/102874/raw |
git am
Now that was helpful!
Exactly what I was looking for!
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-13 13:17 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org, Boyd Stephen Smith Jr.
In-Reply-To: <20081213044357.GD15407@josefsipek.net>
Hi Jeff,
On Sat, Dec 13, 2008 at 06:43:57AM +0200, Josef Jeff Sipek wrote:
> On Sat, Dec 13, 2008 at 10:14:22AM +0800, Wu Fengguang wrote:
> > Introduce option guilt.diffstat so that we don't have to type
> > "guilt refresh --diffstat" in its full form every time.
>
> Good idea.
Thanks.
> Could you throw a quick note into the manpages?
Sure. Here is the updated patch. This time I used "git-config --bool"
to ensure diffstat will be either "true" or "false":
The type specifier can be either --int or --bool, which will
make git-config ensure that the variable(s) are of the given
type and convert the value to the canonical form (simple
decimal number for int, a "true" or "false" string for bool).
If no type specifier is passed, no checks or transformations
are performed on the value.
Thanks,
Fengguang
---
guilt: add option guilt.diffstat
Introduce option guilt.diffstat so that we don't have to type
"guilt refresh --diffstat" in its full form every time.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
diff --git a/Documentation/guilt-refresh.txt b/Documentation/guilt-refresh.txt
index 9a0b4e8..7757bdc 100644
--- a/Documentation/guilt-refresh.txt
+++ b/Documentation/guilt-refresh.txt
@@ -20,8 +20,14 @@ OPTIONS
format (e.g., rename and copy detection).
--diffstat::
- Include a diffstat output in the patch file. Useful for cases where
- patches will be submitted with other tools.
+Include a diffstat output in the patch file. Useful for cases where
+patches will be submitted with other tools.
++
+If the command line option is omitted, the corresponding git-config
+option "guilt.diffstat" will be queried. So this would enable diffstat
+output by default:
+
+ git config --global guilt.diffstat true
Author
------
diff --git a/guilt b/guilt
index fabee17..12361da 100755
--- a/guilt
+++ b/guilt
@@ -544,7 +544,7 @@ __refresh_patch()
[ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
- if [ ! -z "$5" ]; then
+ if [ -n "$5" -o $diffstat = "true" ]; then
(
echo "---"
git diff --stat $diffopts "$2"
@@ -633,6 +633,9 @@ guilt_push_diff_context=1
# default autotag value
AUTOTAG_DEFAULT=1
+# default diffstat value: true or false
+DIFFSTAT_DEFAULT="false"
+
#
# Parse any part of .git/config that belongs to us
#
@@ -641,6 +644,10 @@ AUTOTAG_DEFAULT=1
autotag=`git config guilt.autotag`
[ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
+# generate diffstat?
+diffstat=`git config --bool guilt.diffstat`
+[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
+
#
# The following gets run every time this file is source'd
#
^ permalink raw reply related
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