* Re: Problem with Linus's git repository?
From: walt @ 2007-06-28 13:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706270932040.8675@woody.linux-foundation.org>
On Wed, 27 Jun 2007, Linus Torvalds wrote:
>
>
> On Wed, 27 Jun 2007, walt wrote:
> > >
> > > It's not missing, it's packed. I tend to re-pack after I make a release,
> > > and this time I did it after -rc6...
> >
> > Sometime overnight this problem disappeared. I haven't actually
> > tested this idea, but I have a hunch that your commit yesterday
> > of "Fix zero-object version-2 packs" is the reason.
>
> No, I think the reason is simply that I pushed more updates to kernel.org,
> so now the kernel git repo has an explicit and separate "master" branch
> again.
>
> What is your git version? The _real_ fix probably is to just upgrade. Are
> you using that broken(*) Debian git package by any chance?
No, every morning I pull from you and Junio and Petr Baudis using cg-update,
so I'm very much current. I notice that cg-update specifically does an
http GET on kernel/git/torvalds/linux-2.6.git/HEAD which is actually a
symlink to your refs/heads/master. Your 'master' now exists, but didn't
exist two days ago as far I could see from my end.
The kernel.org server returned a 'you don't have permission to read
kernel/git/torvalds/linux-2.6.git/HEAD on this server', not a 404.
I tried two different ftp clients which also could not see your
'master' file until yesterday.
I notice that Petr hasn't made any changes to cogito for a long
time, so maybe it needs some updating? Dunno.
--- Scanned by M+ Guardian Messaging Firewall ---
^ permalink raw reply
* Re: most commonly used git commands?
From: Johannes Sixt @ 2007-06-28 14:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <4683C5D2.FDF4ED02@eudaptics.com>
Johannes Sixt wrote:
> AFAIAC, it's alright to fall back to update-index for those occasions,
> even though they are not that rare due to a deficiency of
> merge-recursive: When it merges an executable file, it loses the +x bit,
> even if core.filemode=false!
I take that back.
The deficiency is not in merge-recursive, but in 'git add'. The problem
is that after a conflicted merge of an executable file 'git add' loses
the +x bit even if core.filemode=false.
-- Hannes
^ permalink raw reply
* Re: Problem with Linus's git repository?
From: Johannes Schindelin @ 2007-06-28 15:20 UTC (permalink / raw)
To: walt; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0706280632540.5321@x2.ybpnyarg>
Hi,
On Thu, 28 Jun 2007, walt wrote:
> I notice that Petr hasn't made any changes to cogito for a long time, so
> maybe it needs some updating? Dunno.
Pasky announced that he will be discontinuing cogito.
Hth,
Dscho
^ permalink raw reply
* Re: Problem with Linus's git repository?
From: Linus Torvalds @ 2007-06-28 15:41 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706280632540.5321@x2.ybpnyarg>
On Thu, 28 Jun 2007, walt wrote:
>
> No, every morning I pull from you and Junio and Petr Baudis using cg-update,
> so I'm very much current. I notice that cg-update specifically does an
> http GET on kernel/git/torvalds/linux-2.6.git/HEAD which is actually a
> symlink to your refs/heads/master. Your 'master' now exists, but didn't
> exist two days ago as far I could see from my end.
Oh, don't use "cg-update", or just fix it to do "git pull".
That explains it. cogito simply is not maintained any more.
Linus
^ permalink raw reply
* Re: Bug: segfault during git-prune
From: Linus Torvalds @ 2007-06-28 15:59 UTC (permalink / raw)
To: Andy Parkins; +Cc: Git Mailing List
In-Reply-To: <200706281134.58453.andyparkins@gmail.com>
On Thu, 28 Jun 2007, Andy Parkins wrote:
>
> I ran git-prune on a repository and got this:
>
> $ git-prune
> error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit
> Segmentation fault (core dumped)
Do you have subprojects in that git repo?
What happens is that all git object handling *refuses* (correctly) to
touch an object of the wrong type. If it's been marked as a commit at some
point, it had better be looked up as a commit the *next* time we see that
same object too.
And every normal git object traversal will specify in advance what kind of
object it expects (except for the initial refs lookups, that don't know,
and use a totally different interface for "give me any kind of object, and
figure it out").
So the error in this case is that we decided it was a commit once, and a
blob once, and git is very unhappy.
And the only case I know of that does that is using an old git binary, or
a unconverted git code-path program, on a repository with subprojects when
the code-path doesn't understand that a tree can contain pointers to
commits.
So what happens is that something traverses a tree object, looks at each
entry, sees that it's not a tree, and tries to look it up as a blob. But
subprojects are commits, not blobs, and then when you look at the object
more closely, you get the above kind of object type confusion.
And I did that very early on, and wanted to make sure that git objects
were "strongly typed", and you get a big fat error if you try to use the
wrong type.
> $ git-cat-file -t 228f8065b930120e35fc0c154c237487ab02d64a
> commit
>
> git-show of the object shows it looks okay. git-fsck just shows a load
> of dangling objects - which isn't a surprise, that's why I was running
> git-prune.
Yeah, git-fsck knows about subprojects. I bet git-prune just doesn't.
And indeed.. Here's a patch for it, but the fact is, you really should
*not* prune that repository, because you'll prune away all the subproject
data, which you seem to have in the same repo!
(General rule: never *ever* prune a shared object repository!)
Linus
---
reachable.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/reachable.c b/reachable.c
index ff3dd34..17ff929 100644
--- a/reachable.c
+++ b/reachable.c
@@ -21,6 +21,15 @@ static void process_blob(struct blob *blob,
/* Nothing to do, really .. The blob lookup was the important part */
}
+static void process_gitlink(const unsigned char *sha1,
+ struct object_array *p,
+ struct name_path *path,
+ const char *name)
+{
+ /* I don't think we want to recurse into this, really. */
+}
+
+
static void process_tree(struct tree *tree,
struct object_array *p,
struct name_path *path,
@@ -47,6 +56,8 @@ static void process_tree(struct tree *tree,
while (tree_entry(&desc, &entry)) {
if (S_ISDIR(entry.mode))
process_tree(lookup_tree(entry.sha1), p, &me, entry.path);
+ else if (S_ISGITLINK(entry.mode))
+ process_gitlink(entry.sha1, p, &me, entry.path);
else
process_blob(lookup_blob(entry.sha1), p, &me, entry.path);
}
^ permalink raw reply related
* Re: Bug: segfault during git-prune
From: Linus Torvalds @ 2007-06-28 16:09 UTC (permalink / raw)
To: Andy Parkins; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706280844460.8675@woody.linux-foundation.org>
On Thu, 28 Jun 2007, Linus Torvalds wrote:
>
> Yeah, git-fsck knows about subprojects. I bet git-prune just doesn't.
>
> And indeed.. Here's a patch for it, but the fact is, you really should
> *not* prune that repository, because you'll prune away all the subproject
> data, which you seem to have in the same repo!
>
> (General rule: never *ever* prune a shared object repository!)
Btw, we could make the "reachable" code say that *if* you have the commit
of a subproject in your current object directory, it will follow that
commit recursively, and thus sharing an object store at the superproject
level is "ok" as far as "git prune" is concerned.
We don't currently even have that kind of function, though. Calling
"parse_commit()" will complain very loudly if the commit doesn't exist,
but it's actually perfectly fine to not exist if it's in a separate
subproject.
So if you actually want to use subprojects *and* prune them, *and* you
want to keep all the subproject objects in the same big object database,
you'd have to add some commit object "parse-if-you-can-find-it" thing, and
use that.
It shouldn't be fundamentally hard, but it's _not_ what my patch did. My
patch just says: "subprojects are separate projects, and we don't do
reachability from superproject to subproject".
Linus
^ permalink raw reply
* [PATCH] git-tag: Fix the main while loop exit condition.
From: Alexandre Vassalotti @ 2007-06-28 16:56 UTC (permalink / raw)
To: git; +Cc: Alexandre Vassalotti
This stop git-tag from emitting a "shift: can't shift that many"
error, when listing tags.
Signed-off-by: Alexandre Vassalotti <alexandre@peadrop.com>
---
git-tag.sh | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-tag.sh b/git-tag.sh
index c840439..bc0d735 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -14,18 +14,20 @@ username=
list=
verify=
LINES=0
-while case "$#" in 0) break ;; esac
-do
+while [ $# -ne 0 ]; do
case "$1" in
-a)
annotate=1
+ shift
;;
-s)
annotate=1
signed=1
+ shift
;;
-f)
force=1
+ shift
;;
-n)
case $2 in
@@ -36,6 +38,7 @@ do
[ -z "$LINES" ] && LINES=1 # 1 line is default when -n is used
;;
esac
+ shift
;;
-l)
list=1
@@ -122,7 +125,6 @@ do
break
;;
esac
- shift
done
[ -n "$list" ] && exit 0
--
1.5.2.1.144.gabc40
^ permalink raw reply related
* Re: Build git on HP/UX
From: Linus Torvalds @ 2007-06-28 17:04 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: michal.rokos, GIT
In-Reply-To: <20070628105952.GC8925@cip.informatik.uni-erlangen.de>
On Thu, 28 Jun 2007, Thomas Glanzmann wrote:
>
> could someone here describe what he did to build git on HP/UX?
> Some of my questions is:
>
> - What build chain did you use (gcc?)?
The compiler shouldn't be a big issue, although git does expect something
much better than K&R. Ie you need a *modern* compiler.
(To be honest, the git sources do use some gcc extensions, but
(a) I think they are all successfully conditional on gcc already
(b) most modern vendor compilers support a lot of them anyway
The Makefile is very GNU-make, though, so even if you don't have gcc, you
should have GNU make, or you'd need to create your own makefile.
And you'll need perl, and a basic set of development libraries: zlib and
openssl are the minimum set, I think (apart from the basic C library with
networking extensions).
For full functionality, you'll need ssh, rsync, tcl/tk, curl, expat, SVN,
CVS, cvsps, etc - obviously depending on what you're actually going to do.
Linus
^ permalink raw reply
* [PATCH] git add: respect core.filemode even with unmerged entries in the index
From: Johannes Schindelin @ 2007-06-28 17:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4683CA7A.7F8070D7@eudaptics.com>
When a merge left unmerged entries, git add failed to pick up the
file mode from the index, when core.filemode == 0.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Thu, 28 Jun 2007, Johannes Sixt wrote:
> Johannes Sixt wrote:
>
> The deficiency is not in merge-recursive, but in 'git add'. The
> problem is that after a conflicted merge of an executable file
> 'git add' loses the +x bit even if core.filemode=false.
How's that?
read-cache.c | 6 ++++++
t/t3700-add.sh | 14 ++++++++++++++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 4362b11..a74e4a7 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -382,6 +382,12 @@ int add_file_to_index(struct index_state *istate, const char *path, int verbose)
struct cache_entry *ent;
int pos = index_name_pos(istate, path, namelen);
+ /* might be unmerged */
+ if (pos < 0 && 1-pos < istate->cache_nr &&
+ namelen == ce_namelen(istate->cache[1-pos]) &&
+ !memcmp(path, istate->cache[1-pos]->name,
+ namelen))
+ pos = 1-pos;
ent = (0 <= pos) ? istate->cache[pos] : NULL;
ce->ce_mode = ce_mode_from_stat(ent, st.st_mode);
}
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index ad8cc7d..d75970b 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -110,4 +110,18 @@ test_expect_success 'check correct prefix detection' '
git add 1/2/a 1/3/b 1/2/c
'
+test_expect_success 'git add and filemode=0 with unmerged entries' '
+ echo 1 > stage1 &&
+ echo 2 > stage2 &&
+ echo 3 > stage3 &&
+ for s in 1 2 3
+ do
+ echo "100755 $(git hash-object -w stage$s) $s file"
+ done | git update-index --index-info &&
+ git config core.filemode 0 &&
+ echo new > file &&
+ git add file &&
+ git ls-files --stage | grep "^100755 .* 0 file$"
+'
+
test_done
--
1.5.2.2.3228.g16a27
^ permalink raw reply related
* [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Matt McCutchen @ 2007-06-28 18:02 UTC (permalink / raw)
To: git
- Centralize knowledge about snapshot formats (mime types, extensions,
commands) in %known_snapshot_formats and improve how some of that
information is specified. In particular, zip files are no longer a
special case.
- Add support for offering multiple snapshot formats to the user so
that he/she can download a snapshot in the format he/she prefers.
The site-wide or project configuration now gives a list of formats
to offer, and the "_snapshot_" link is replaced with, say,
"snapshot (_tbz2_ _zip_)".
- Fix out-of-date "tarball" -> "archive" in comment.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
---
I implemented this a while ago for my Web site. You can see it in action at:
http://www.kepreon.com/~matt/mgear/mgear.git/
I thought I would submit it to the main project so you can adopt it if you like
it.
Matt
gitweb/gitweb.perl | 89 +++++++++++++++++++++++++++++----------------------
1 files changed, 51 insertions(+), 38 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index dbfb044..f36428e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -101,6 +101,15 @@ our $mimetypes_file = undef;
# could be even 'utf-8' for the old behavior)
our $fallback_encoding = 'latin1';
+# information about snapshot formats that gitweb is capable of serving
+# name => [mime type, filename suffix, --format for git-archive,
+# compressor command suffix]
+our %known_snapshot_formats = (
+ 'tgz' => ['application/x-gzip' , '.tar.gz' , 'tar', '| gzip' ],
+ 'tbz2' => ['application/x-bzip2', '.tar.bz2', 'tar', '| bzip2'],
+ 'zip' => ['application/zip' , '.zip' , 'zip', '' ],
+);
+
# You define site-wide feature defaults here; override them with
# $GITWEB_CONFIG as necessary.
our %feature = (
@@ -131,20 +140,22 @@ our %feature = (
'override' => 0,
'default' => [0]},
- # Enable the 'snapshot' link, providing a compressed tarball of any
+ # Enable the 'snapshot' link, providing a compressed archive of any
# tree. This can potentially generate high traffic if you have large
# project.
+ # Value is a list of formats defined in %known_snapshot_formats that
+ # you wish to offer.
# To disable system wide have in $GITWEB_CONFIG
- # $feature{'snapshot'}{'default'} = [undef];
+ # $feature{'snapshot'}{'default'} = [];
# To have project specific config enable override in $GITWEB_CONFIG
# $feature{'snapshot'}{'override'} = 1;
- # and in project config gitweb.snapshot = none|gzip|bzip2|zip;
+ # and in project config, a comma-separated list of formats or "none"
+ # to disable. Example: gitweb.snapshot = tbz2,zip;
'snapshot' => {
'sub' => \&feature_snapshot,
'override' => 0,
- # => [content-encoding, suffix, program]
- 'default' => ['x-gzip', 'gz', 'gzip']},
+ 'default' => ['tgz']},
# Enable text search, which will list the commits which match author,
# committer or commit text to a given string. Enabled by default.
@@ -243,28 +254,15 @@ sub feature_blame {
}
sub feature_snapshot {
- my ($ctype, $suffix, $command) = @_;
+ my (@fmts) = @_;
my ($val) = git_get_project_config('snapshot');
- if ($val eq 'gzip') {
- return ('x-gzip', 'gz', 'gzip');
- } elsif ($val eq 'bzip2') {
- return ('x-bzip2', 'bz2', 'bzip2');
- } elsif ($val eq 'zip') {
- return ('x-zip', 'zip', '');
- } elsif ($val eq 'none') {
- return ();
+ if ($val) {
+ @fmts = ($val eq 'none' ? () : split /,/, $val);
}
- return ($ctype, $suffix, $command);
-}
-
-sub gitweb_have_snapshot {
- my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
- my $have_snapshot = (defined $ctype && defined $suffix);
-
- return $have_snapshot;
+ return grep exists $known_snapshot_formats{$_}, @fmts;
}
sub feature_grep {
@@ -542,6 +540,7 @@ sub href(%) {
order => "o",
searchtext => "s",
searchtype => "st",
+ snapshot_format => "sf",
);
my %mapping = @mapping;
@@ -1236,6 +1235,21 @@ sub format_diff_line {
return "<div class=\"diff$diff_class\">" . esc_html($line, -nbsp=>1) . "</div>\n";
}
+# Generates undef or something like "snapshot (tbz2 zip)", linked.
+# Pass the hash.
+sub format_snapshot_links {
+ my ($hash) = @_;
+ my @snapshot_fmts = gitweb_check_feature('snapshot');
+ if (@snapshot_fmts) {
+ return "snapshot (" . join(' ', map $cgi->a(
+ {-href => href(action=>"snapshot", hash=>$hash, snapshot_format=>$_)}, "$_"),
+ @snapshot_fmts)
+ . ")";
+ } else {
+ return undef;
+ }
+}
+
## ----------------------------------------------------------------------
## git utility subroutines, invoking git commands
@@ -3280,8 +3294,6 @@ sub git_shortlog_body {
# uses global variable $project
my ($commitlist, $from, $to, $refs, $extra) = @_;
- my $have_snapshot = gitweb_have_snapshot();
-
$from = 0 unless defined $from;
$to = $#{$commitlist} if (!defined $to || $#{$commitlist} < $to);
@@ -3308,8 +3320,9 @@ sub git_shortlog_body {
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
$cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
- if ($have_snapshot) {
- print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
+ my $snapshot_links = format_snapshot_links($commit);
+ if (defined $snapshot_links) {
+ print " | " . $snapshot_links;
}
print "</td>\n" .
"</tr>\n";
@@ -4194,11 +4207,16 @@ sub git_tree {
}
sub git_snapshot {
- my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
- my $have_snapshot = (defined $ctype && defined $suffix);
- if (!$have_snapshot) {
- die_error('403 Permission denied', "Permission denied");
+ my @supported_fmts = gitweb_check_feature('snapshot');
+
+ my $format = $cgi->param('sf');
+ unless ($format =~ m/[a-z0-9]+/
+ && exists($known_snapshot_formats{$format})
+ && grep($_ eq $format, @supported_fmts)) {
+ die_error(undef, "Unsupported snapshot format");
}
+ my ($ctype, $suffix, $ga_format, $pipe_compressor) =
+ @{$known_snapshot_formats{$format}};
if (!defined $hash) {
$hash = git_get_head_hash($project);
@@ -4211,16 +4229,11 @@ sub git_snapshot {
my $filename = to_utf8($name);
$name =~ s/\047/\047\\\047\047/g;
my $cmd;
- if ($suffix eq 'zip') {
- $filename .= "-$hash.$suffix";
- $cmd = "$git archive --format=zip --prefix=\'$name\'/ $hash";
- } else {
- $filename .= "-$hash.tar.$suffix";
- $cmd = "$git archive --format=tar --prefix=\'$name\'/ $hash | $command";
- }
+ $filename .= "-$hash$suffix";
+ $cmd = "$git archive --format=$ga_format --prefix=\'$name\'/ $hash $pipe_compressor";
print $cgi->header(
- -type => "application/$ctype",
+ -type => "$ctype",
-content_disposition => 'inline; filename="' . "$filename" . '"',
-status => '200 OK');
--
1.5.2.2.552.gc32f
^ permalink raw reply related
* Re: [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Steven Grimm @ 2007-06-28 18:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0706281340090.4438@racer.site>
Johannes Schindelin wrote:
> Somehow I think that this should be triggered by "--ignore-space-at-eol",
> _and_ be accompanied by a test case.
>
Should --ignore-space-at-eol be an option to git-merge? Merges are where
this functionality matters; for simple diffs, --ignore-space-at-eol
actually already covers it. If we allow that option, should we also
allow other git-diff options like --ignore-all-space and
--ignore-space-change? What are the semantics of an autoresolved merge
with those options in effect -- are they only used for rename detection,
or do we, e.g., not flag conflicts with only whitespace changes? And if
we don't, which version do we accept automatically?
-Steve
^ permalink raw reply
* git-svn fails different ways depending on svn-remote.svn.url protocol
From: Mark Grimes @ 2007-06-28 18:05 UTC (permalink / raw)
To: git
I'm at a complete loss as to what is happening here. The HTTPS error
that does not allow me to fulfill the commit is:
RA layer request failed: PUT of
'/repository/macports/!svn/wrk/e983e9c6-e86a-4223-b30b-2a7457845272/trunk/dports/perl/p5-params-util/Portfile':
SSL negotiation failed: SSL error: sslv3 alert bad record mac
(https://svn.macports.org) at /opt/local/bin/git-svn line 405
It's pretty consistent but after a few dozen attempts I was able to get
my 10 changes across 10 files committed through a series of commits and
resets until the dcommit was successful.
If I switch the svn url to HTTP, I get something even stranger (I did
create the repository initially from the HTTP URL, but I would hope that
flipping svn-remote.svn.url back and forth between http and https would
be completely transparent) -- however the HTTP version of the error is:
Merge conflict during commit: Your file or directory
'dports/audio/libid3tag/Portfile' is probably out-of-date: The version
resource does not correspond to the resource within the transaction.
Either the requested version resource is out of date (needs to be
updated), or the requested version resource is newer than the
transaction root (restart the commit). at /opt/local/bin/git-svn line 405
Note that libid3tag/Portfile work was by another committer and about 30
or so commits away from head. How does one bring this up from being
out-of-date?
I have full transcriptions of the process if this helps, but didn't want
to spam the list with it.
Does anyone have any ideas what might solve either problem? I think the
former is a Subversion issue because I've heard this complaint from
committers using the svn client... The solution seems to be keep trying
till it takes, which has me shaking my head at the entire process.
I did finally get the commit in through bruteforce via HTTPS, but I lack
confidence in patching any more then a file or two at a time, which is
quite disheartening while trying to follow the philosophy of whole
functional commits and not spread out due to technical deficiencies.
^ permalink raw reply
* [PATCH] gitweb: make search form generate pathinfo-style URLs
From: Matt McCutchen @ 2007-06-28 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The search form generated traditional-style URLs with a "p=" parameter
even when the pathinfo feature was on. This patch makes it generate
pathinfo-style URLs when appropriate.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
---
gitweb/gitweb.perl | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f36428e..7b0e110 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2215,12 +2215,18 @@ EOF
} else {
$search_hash = "HEAD";
}
+ my $action = $my_uri;
+ my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ if ($use_pathinfo) {
+ $action .= "/$project";
+ } else {
+ $cgi->param("p", $project);
+ }
$cgi->param("a", "search");
$cgi->param("h", $search_hash);
- $cgi->param("p", $project);
- print $cgi->startform(-method => "get", -action => $my_uri) .
+ print $cgi->startform(-method => "get", -action => $action) .
"<div class=\"search\">\n" .
- $cgi->hidden(-name => "p") . "\n" .
+ (!$use_pathinfo && $cgi->hidden(-name => "p") . "\n") .
$cgi->hidden(-name => "a") . "\n" .
$cgi->hidden(-name => "h") . "\n" .
$cgi->popup_menu(-name => 'st', -default => 'commit',
--
1.5.2.2.552.gc32f
^ permalink raw reply related
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Theodore Tso @ 2007-06-28 19:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706261024210.8675@woody.linux-foundation.org>
On Tue, Jun 26, 2007 at 10:32:23AM -0700, Linus Torvalds wrote:
> But we actually _do_ want fully buffered from a performance angle.
> Especially for the big stuff, which is usually the *diffs*, not the commit
> messages. Not so much an issue with git-rev-list, but with "git log -p"
> you would normally not want it line-buffered, and it's actually much nicer
> to let it be fully buffered and then do a flush at the end.
>
> Even pipes are often used for "throughput" stuff if you end up doing some
> post-processing (ie "git log -p | gather-statistics"), and yes, I actually
> do things like that - it's nice for things like looking at how many lines
> have been added during the last release cycle
>
> git log -p v2.6.21.. | grep '^+' | wc -l
>
> and I'd really like thigns like that to be close to optimal.
>
> How much the system call overhead is, I don't know, though. So it might be
> worth testing out....
So just for yuks, I devised the following patch, and did some measurements....
For the above pipeline, the result was hardly worth mentioning:
With flushing:
% time git log -p v2.6.21.. | grep '^+' | wc -l
real 0m22.330s
user 0m21.512s
sys 0m0.807s
# of write() system calls according to strace -c: 15167
Without flushing:
% time git log -p v2.6.21.. | grep '^+' | wc -l
real 0m22.367s
user 0m21.355s
sys 0m0.720s
# of write() system calls according to strace -c: 11373
So here's the worst case:
% time git-rev-list HEAD > /dev/null
real 0m1.575s
user 0m1.477s
sys 0m0.053s
# of write() system calls according to strace -c: 582
% (export GIT_NEVER_FLUSH_STDOUT=t; time git-rev-list HEAD > /dev/null)
real 0m1.535s
user 0m1.463s
sys 0m0.027s
# of write() system calls according to strace -c: 58055
> Under Linux, you'll probably have a fairly hard time
> seeing any difference, but under other OS's you have both system call
> latency issues *and* possible scheduling issues (ie the above kind of
> pipeline can act very differently from a scheduling standpoint if you send
> lots of small things rather than buffer things a bit on the generating
> side)
Indeed. So it's not at all clear this patch is worth applying, but
maybe it would make a difference on some other OS; of course, this
patch also obviates the original intent of Jim Meyering's patch, since
it means that we won't print a useful error message if stdout has been
redirected to a file and the write returns ENOSPC, since we won't be
fflush() when stdout is redirected to a file.
The added fflush() calls to the incremental git-blame and the
git-log-*/git-whatchanged might make it worthwhile for tools that
depend on those outputs and want faster user response time. So maybe
adding the fflush() call might be worthwhile for those programs.
- Ted
commit 7f483ec6366f62d52199e3edefa292a110fcb5c8
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Jun 28 14:10:58 2007 -0400
Don't fflush(stdout) when it's not helpful
This patch arose from a discussion started by Jim Meyering's patch
whose intention was to provide better diagnostics for failed writes.
Linus proposed a better way to do things, which also had the added
benefit that adding a fflush() to git-log-* operations and incremental
git-blame operations could improve interactive respose time feel, at
the cost of making things a bit slower when we aren't piping the
output to a downstream program.
This patch skips the fflush() calls when stdout is a regular file, or
if the environment variable GIT_NEVER_FLUSH_STDOUT is set. This
latter can speed up a command such as:
(export GIT_NEVER_FLUSH_STDOUT=t; git-rev-list HEAD | wc -l)
a tiny amount.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
diff --git a/builtin-blame.c b/builtin-blame.c
index f7e2c13..da23a6f 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1459,6 +1459,7 @@ static void found_guilty_entry(struct blame_entry *ent)
printf("boundary\n");
}
write_filename_info(suspect->path);
+ maybe_flush_or_die(stdout, "stdout");
}
}
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 813aadf..86db8b0 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -100,7 +100,7 @@ static void show_commit(struct commit *commit)
printf("%s%c", buf, hdr_termination);
free(buf);
}
- fflush(stdout);
+ maybe_flush_or_die(stdout, "stdout");
if (commit->parents) {
free_commit_list(commit->parents);
commit->parents = NULL;
diff --git a/cache.h b/cache.h
index ed83d92..0525c4e 100644
--- a/cache.h
+++ b/cache.h
@@ -532,6 +532,8 @@ extern char git_default_name[MAX_GITNAME];
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
+/* IO helper functions */
+extern void maybe_flush_or_die(FILE *, const char *);
extern int copy_fd(int ifd, int ofd);
extern int read_in_full(int fd, void *buf, size_t count);
extern int write_in_full(int fd, const void *buf, size_t count);
diff --git a/log-tree.c b/log-tree.c
index 0cf21bc..ced3f33 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -408,5 +408,6 @@ int log_tree_commit(struct rev_info *opt, struct commit *commit)
shown = 1;
}
opt->loginfo = NULL;
+ maybe_flush_or_die(stdout, "stdout");
return shown;
}
diff --git a/write_or_die.c b/write_or_die.c
index 5c4bc85..2cebeb5 100644
--- a/write_or_die.c
+++ b/write_or_die.c
@@ -1,5 +1,43 @@
#include "cache.h"
+/*
+ * Some cases use stdio, but want to flush after the write
+ * to get error handling (and to get better interactive
+ * behaviour - not buffering excessively).
+ *
+ * Of course, if the flush happened within the write itself,
+ * we've already lost the error code, and cannot report it any
+ * more. So we just ignore that case instead (and hope we get
+ * the right error code on the flush).
+ *
+ * If the file handle is stdout, and stdout is a file, then skip the
+ * flush entirely since it's not needed.
+ */
+void maybe_flush_or_die(FILE *f, const char *desc)
+{
+ static int stdout_is_file = -1;
+ struct stat st;
+
+ if (f == stdout) {
+ if (stdout_is_file < 0) {
+ if (getenv("GIT_NEVER_FLUSH_STDOUT") ||
+ ((fstat(fileno(stdout), &st) == 0) &&
+ S_ISREG(st.st_mode)))
+ stdout_is_file = 1;
+ else
+ stdout_is_file = 0;
+ }
+ if (stdout_is_file)
+ return;
+ }
+ if (fflush(f)) {
+ if (errno == EPIPE)
+ exit(0);
+ die("write failure on %s: %s",
+ desc, strerror(errno));
+ }
+}
+
int read_in_full(int fd, void *buf, size_t count)
{
char *p = buf;
^ permalink raw reply related
* [PATCH] Add test-script for git-tag
From: Carlos Rica @ 2007-06-28 20:09 UTC (permalink / raw)
To: git, Johannes.Schindelin, gitster, krh
These tests are useful to develop the C version for git-tag.sh,
ensuring that the future builtin-tag.c will not break previous
behaviour.
The tests are focused on listing, verifying, deleting and creating
tags, checking always that the correct status value is returned
and everything remains as expected.
In order to verify and create signed tags, a PGP key was also
added, being created this way: gpg --homedir t/t7004 --gen-key
Type DSA and Elgamal, size 2048 bits, no expiration date.
Name and email: C O Mitter <committer@example.com>
No password given, to enable non-interactive operation.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
This patch has the changes that Junio suggested in:
http://article.gmane.org/gmane.comp.version-control.git/50286
Since random_seed would be regenerated by gpg when running
these tests, it is included, to prevent the tests from
stalling on entropy-weak machines.
t/t7004-tag.sh | 687 +++++++++++++++++++++++++++++++++++++++++++++++++++
t/t7004/pubring.gpg | Bin
t/t7004/random_seed | Bin
t/t7004/secring.gpg | Bin
4 files changed, 687 insertions(+), 0 deletions(-)
create mode 100755 t/t7004-tag.sh
create mode 100644 t/t7004/pubring.gpg
create mode 100644 t/t7004/random_seed
create mode 100644 t/t7004/secring.gpg
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
new file mode 100755
index 0000000..a09adc6
--- /dev/null
+++ b/t/t7004-tag.sh
@@ -0,0 +1,687 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Carlos Rica
+#
+
+test_description='git-tag
+
+Basic tests for operations with tags.'
+
+. ./test-lib.sh
+
+# creating and listing lightweight tags:
+
+tag_exists () {
+ git show-ref --quiet --verify refs/tags/"$1"
+}
+
+# todo: git tag -l now returns always zero, when fixed, change this test
+test_expect_success 'listing all tags in an empty tree should succeed' \
+ 'git tag -l'
+
+test_expect_success 'listing all tags in an empty tree should output nothing' \
+ 'test `git-tag -l | wc -l` -eq 0'
+
+test_expect_failure 'looking for a tag in an empty tree should fail' \
+ 'tag_exists mytag'
+
+test_expect_success 'creating a tag in an empty tree should fail' '
+ ! git-tag mynotag &&
+ ! tag_exists mynotag
+'
+
+test_expect_success 'creating a tag for HEAD in an empty tree should fail' '
+ ! git-tag mytaghead HEAD &&
+ ! tag_exists mytaghead
+'
+
+test_expect_success 'creating a tag for an unknown revision should fail' '
+ ! git-tag mytagnorev aaaaaaaaaaa &&
+ ! tag_exists mytagnorev
+'
+
+# commit used in the tests, test_tick is also called here to freeze the date:
+test_expect_success 'creating a tag using default HEAD should succeed' '
+ test_tick &&
+ echo foo >foo &&
+ git add foo &&
+ git commit -m Foo &&
+ git tag mytag
+'
+
+test_expect_success 'listing all tags if one exists should succeed' \
+ 'git-tag -l'
+
+test_expect_success 'listing all tags if one exists should output that tag' \
+ 'test `git-tag -l` = mytag'
+
+# pattern matching:
+
+test_expect_success 'listing a tag using a matching pattern should succeed' \
+ 'git-tag -l mytag'
+
+test_expect_success \
+ 'listing a tag using a matching pattern should output that tag' \
+ 'test `git-tag -l mytag` = mytag'
+
+# todo: git tag -l now returns always zero, when fixed, change this test
+test_expect_success \
+ 'listing tags using a non-matching pattern should suceed' \
+ 'git-tag -l xxx'
+
+test_expect_success \
+ 'listing tags using a non-matching pattern should output nothing' \
+ 'test `git-tag -l xxx | wc -l` -eq 0'
+
+# special cases for creating tags:
+
+test_expect_failure \
+ 'trying to create a tag with the name of one existing should fail' \
+ 'git tag mytag'
+
+test_expect_success \
+ 'trying to create a tag with a non-valid name should fail' '
+ test `git-tag -l | wc -l` -eq 1 &&
+ ! git tag "" &&
+ ! git tag .othertag &&
+ ! git tag "other tag" &&
+ ! git tag "othertag^" &&
+ ! git tag "other~tag" &&
+ test `git-tag -l | wc -l` -eq 1
+'
+
+test_expect_success 'creating a tag using HEAD directly should succeed' '
+ git tag myhead HEAD &&
+ tag_exists myhead
+'
+
+# deleting tags:
+
+test_expect_success 'trying to delete an unknown tag should fail' '
+ ! tag_exists unknown-tag &&
+ ! git-tag -d unknown-tag
+'
+
+cat >expect <<EOF
+myhead
+mytag
+EOF
+test_expect_success \
+ 'trying to delete tags without params should succeed and do nothing' '
+ git tag -l > actual && git diff expect actual &&
+ git-tag -d &&
+ git tag -l > actual && git diff expect actual
+'
+
+test_expect_success \
+ 'deleting two existing tags in one command should succeed' '
+ tag_exists mytag &&
+ tag_exists myhead &&
+ git-tag -d mytag myhead &&
+ ! tag_exists mytag &&
+ ! tag_exists myhead
+'
+
+test_expect_success \
+ 'creating a tag with the name of another deleted one should succeed' '
+ ! tag_exists mytag &&
+ git-tag mytag &&
+ tag_exists mytag
+'
+
+test_expect_success \
+ 'trying to delete two tags, existing and not, should fail in the 2nd' '
+ tag_exists mytag &&
+ ! tag_exists myhead &&
+ ! git-tag -d mytag anothertag &&
+ ! tag_exists mytag &&
+ ! tag_exists myhead
+'
+
+test_expect_failure 'trying to delete an already deleted tag should fail' \
+ 'git-tag -d mytag'
+
+# listing various tags with pattern matching:
+
+cat >expect <<EOF
+a1
+aa1
+cba
+t210
+t211
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+EOF
+test_expect_success 'listing all tags should print them ordered' '
+ git tag v1.0.1 &&
+ git tag t211 &&
+ git tag aa1 &&
+ git tag v0.2.1 &&
+ git tag v1.1.3 &&
+ git tag cba &&
+ git tag a1 &&
+ git tag v1.0 &&
+ git tag t210 &&
+ git tag -l > actual
+ git diff expect actual
+'
+
+cat >expect <<EOF
+a1
+aa1
+cba
+EOF
+test_expect_success \
+ 'listing tags with substring as pattern must print those matching' '
+ git-tag -l a > actual &&
+ git-diff expect actual
+'
+
+cat >expect <<EOF
+v0.2.1
+v1.0.1
+v1.1.3
+EOF
+test_expect_success \
+ 'listing tags with substring as pattern must print those matching' '
+ git-tag -l .1 > actual &&
+ git-diff expect actual
+'
+
+cat >expect <<EOF
+t210
+t211
+EOF
+test_expect_success \
+ 'listing tags with substring as pattern must print those matching' '
+ git-tag -l t21 > actual &&
+ git-diff expect actual
+'
+
+cat >expect <<EOF
+a1
+aa1
+EOF
+test_expect_success \
+ 'listing tags using a name as pattern must print those matching' '
+ git-tag -l a1 > actual &&
+ git-diff expect actual
+'
+
+cat >expect <<EOF
+v1.0
+v1.0.1
+EOF
+test_expect_success \
+ 'listing tags using a name as pattern must print those matching' '
+ git-tag -l v1.0 > actual &&
+ git-diff expect actual
+'
+
+cat >expect <<EOF
+v1.1.3
+EOF
+test_expect_success \
+ 'listing tags with ? in the pattern should print those matching' '
+ git-tag -l "1.1?" > actual &&
+ git-diff expect actual
+'
+
+>expect
+test_expect_success \
+ 'listing tags using v.* should print nothing because none have v.' '
+ git-tag -l "v.*" > actual &&
+ git-diff expect actual
+'
+
+cat >expect <<EOF
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+EOF
+test_expect_success \
+ 'listing tags using v* should print only those having v' '
+ git-tag -l "v*" > actual &&
+ git-diff expect actual
+'
+
+# creating and verifying lightweight tags:
+
+test_expect_success \
+ 'a non-annotated tag created without parameters should point to HEAD' '
+ git-tag non-annotated-tag &&
+ test $(git-cat-file -t non-annotated-tag) = commit &&
+ test $(git-rev-parse non-annotated-tag) = $(git-rev-parse HEAD)
+'
+
+test_expect_failure 'trying to verify an unknown tag should fail' \
+ 'git-tag -v unknown-tag'
+
+test_expect_failure \
+ 'trying to verify a non-annotated and non-signed tag should fail' \
+ 'git-tag -v non-annotated-tag'
+
+# creating annotated tags:
+
+get_tag_msg () {
+ git cat-file tag "$1" | sed -e "/BEGIN PGP/q"
+}
+
+# run test_tick before committing always gives the time in that timezone
+get_tag_header () {
+cat <<EOF
+object $2
+type $3
+tag $1
+tagger C O Mitter <committer@example.com> $4 -0700
+
+EOF
+}
+
+commit=$(git rev-parse HEAD)
+time=$test_tick
+
+get_tag_header annotated-tag $commit commit $time >expect
+echo "A message" >>expect
+test_expect_success \
+ 'creating an annotated tag with -m message should succeed' '
+ git-tag -m "A message" annotated-tag &&
+ get_tag_msg annotated-tag >actual &&
+ git diff expect actual
+'
+
+cat >msgfile <<EOF
+Another message
+in a file.
+EOF
+get_tag_header file-annotated-tag $commit commit $time >expect
+cat msgfile >>expect
+test_expect_success \
+ 'creating an annotated tag with -F messagefile should succeed' '
+ git-tag -F msgfile file-annotated-tag &&
+ get_tag_msg file-annotated-tag >actual &&
+ git diff expect actual
+'
+
+# blank and empty messages:
+
+get_tag_header empty-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with an empty -m message should succeed' '
+ git-tag -m "" empty-annotated-tag &&
+ get_tag_msg empty-annotated-tag >actual &&
+ git diff expect actual
+'
+
+>emptyfile
+get_tag_header emptyfile-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with an empty -F messagefile should succeed' '
+ git-tag -F emptyfile emptyfile-annotated-tag &&
+ get_tag_msg emptyfile-annotated-tag >actual &&
+ git diff expect actual
+'
+
+printf '\n\n \n\t\nLeading blank lines\n' >blanksfile
+printf '\n\t \t \nRepeated blank lines\n' >>blanksfile
+printf '\n\n\nTrailing spaces \t \n' >>blanksfile
+printf '\nTrailing blank lines\n\n\t \n\n' >>blanksfile
+get_tag_header blanks-annotated-tag $commit commit $time >expect
+cat >>expect <<EOF
+Leading blank lines
+
+Repeated blank lines
+
+Trailing spaces
+
+Trailing blank lines
+EOF
+test_expect_success \
+ 'extra blanks in the message for an annotated tag should be removed' '
+ git-tag -F blanksfile blanks-annotated-tag &&
+ get_tag_msg blanks-annotated-tag >actual &&
+ git diff expect actual
+'
+
+get_tag_header blank-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with blank -m message with spaces should succeed' '
+ git-tag -m " " blank-annotated-tag &&
+ get_tag_msg blank-annotated-tag >actual &&
+ git diff expect actual
+'
+
+echo ' ' >blankfile
+echo '' >>blankfile
+echo ' ' >>blankfile
+get_tag_header blankfile-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with blank -F messagefile with spaces should succeed' '
+ git-tag -F blankfile blankfile-annotated-tag &&
+ get_tag_msg blankfile-annotated-tag >actual &&
+ git diff expect actual
+'
+
+printf ' ' >blanknonlfile
+get_tag_header blanknonlfile-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with -F file of spaces and no newline should succeed' '
+ git-tag -F blanknonlfile blanknonlfile-annotated-tag &&
+ get_tag_msg blanknonlfile-annotated-tag >actual &&
+ git diff expect actual
+'
+
+# messages with commented lines:
+
+cat >commentsfile <<EOF
+# A comment
+
+############
+The message.
+############
+One line.
+
+
+# commented lines
+# commented lines
+
+Another line.
+# comments
+
+Last line.
+EOF
+get_tag_header comments-annotated-tag $commit commit $time >expect
+cat >>expect <<EOF
+The message.
+One line.
+
+Another line.
+
+Last line.
+EOF
+test_expect_success \
+ 'creating a tag using a -F messagefile with #comments should succeed' '
+ git-tag -F commentsfile comments-annotated-tag &&
+ get_tag_msg comments-annotated-tag >actual &&
+ git diff expect actual
+'
+
+get_tag_header comment-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with a #comment in the -m message should succeed' '
+ git-tag -m "#comment" comment-annotated-tag &&
+ get_tag_msg comment-annotated-tag >actual &&
+ git diff expect actual
+'
+
+echo '#comment' >commentfile
+echo '' >>commentfile
+echo '####' >>commentfile
+get_tag_header commentfile-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with #comments in the -F messagefile should succeed' '
+ git-tag -F commentfile commentfile-annotated-tag &&
+ get_tag_msg commentfile-annotated-tag >actual &&
+ git diff expect actual
+'
+
+printf '#comment' >commentnonlfile
+get_tag_header commentnonlfile-annotated-tag $commit commit $time >expect
+test_expect_success \
+ 'creating a tag with a file of #comment and no newline should succeed' '
+ git-tag -F commentnonlfile commentnonlfile-annotated-tag &&
+ get_tag_msg commentnonlfile-annotated-tag >actual &&
+ git diff expect actual
+'
+
+# trying to verify annotated non-signed tags:
+
+test_expect_success \
+ 'trying to verify an annotated non-signed tag should fail' '
+ tag_exists annotated-tag &&
+ ! git-tag -v annotated-tag
+'
+
+test_expect_success \
+ 'trying to verify a file-annotated non-signed tag should fail' '
+ tag_exists file-annotated-tag &&
+ ! git-tag -v file-annotated-tag
+'
+
+# creating and verifying signed tags:
+
+gpg --version >/dev/null
+if [ $? -eq 127 ]; then
+ echo "Skipping signed tags tests, because gpg was not found"
+ test_done
+ exit
+fi
+
+# key generation info: gpg --homedir t/t7004 --gen-key
+# Type DSA and Elgamal, size 2048 bits, no expiration date.
+# Name and email: C O Mitter <committer@example.com>
+# No password given, to enable non-interactive operation.
+
+cp -R ../t7004 ./gpghome
+chmod 0700 gpghome
+export GNUPGHOME="$(pwd)/gpghome"
+
+get_tag_header signed-tag $commit commit $time >expect
+echo 'A signed tag message' >>expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success 'creating a signed tag with -m message should succeed' '
+ git-tag -s -m "A signed tag message" signed-tag &&
+ get_tag_msg signed-tag >actual &&
+ git-diff expect actual
+'
+
+test_expect_success 'verifying a signed tag should succeed' \
+ 'git-tag -v signed-tag'
+
+test_expect_success 'verifying a forged tag should fail' '
+ forged=$(git cat-file tag signed-tag |
+ sed -e "s/signed-tag/forged-tag/" |
+ git mktag) &&
+ git tag forged-tag $forged &&
+ ! git-tag -v forged-tag
+'
+
+# blank and empty messages for signed tags:
+
+get_tag_header empty-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with an empty -m message should succeed' '
+ git-tag -s -m "" empty-signed-tag &&
+ get_tag_msg empty-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v empty-signed-tag
+'
+
+>sigemptyfile
+get_tag_header emptyfile-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with an empty -F messagefile should succeed' '
+ git-tag -s -F sigemptyfile emptyfile-signed-tag &&
+ get_tag_msg emptyfile-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v emptyfile-signed-tag
+'
+
+printf '\n\n \n\t\nLeading blank lines\n' > sigblanksfile
+printf '\n\t \t \nRepeated blank lines\n' >>sigblanksfile
+printf '\n\n\nTrailing spaces \t \n' >>sigblanksfile
+printf '\nTrailing blank lines\n\n\t \n\n' >>sigblanksfile
+get_tag_header blanks-signed-tag $commit commit $time >expect
+cat >>expect <<EOF
+Leading blank lines
+
+Repeated blank lines
+
+Trailing spaces
+
+Trailing blank lines
+EOF
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'extra blanks in the message for a signed tag should be removed' '
+ git-tag -s -F sigblanksfile blanks-signed-tag &&
+ get_tag_msg blanks-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v blanks-signed-tag
+'
+
+get_tag_header blank-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with a blank -m message should succeed' '
+ git-tag -s -m " " blank-signed-tag &&
+ get_tag_msg blank-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v blank-signed-tag
+'
+
+echo ' ' >sigblankfile
+echo '' >>sigblankfile
+echo ' ' >>sigblankfile
+get_tag_header blankfile-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with blank -F file with spaces should succeed' '
+ git-tag -s -F sigblankfile blankfile-signed-tag &&
+ get_tag_msg blankfile-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v blankfile-signed-tag
+'
+
+printf ' ' >sigblanknonlfile
+get_tag_header blanknonlfile-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with spaces and no newline should succeed' '
+ git-tag -s -F sigblanknonlfile blanknonlfile-signed-tag &&
+ get_tag_msg blanknonlfile-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v signed-tag
+'
+
+# messages with commented lines for signed tags:
+
+cat >sigcommentsfile <<EOF
+# A comment
+
+############
+The message.
+############
+One line.
+
+
+# commented lines
+# commented lines
+
+Another line.
+# comments
+
+Last line.
+EOF
+get_tag_header comments-signed-tag $commit commit $time >expect
+cat >>expect <<EOF
+The message.
+One line.
+
+Another line.
+
+Last line.
+EOF
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with a -F file with #comments should succeed' '
+ git-tag -s -F sigcommentsfile comments-signed-tag &&
+ get_tag_msg comments-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v comments-signed-tag
+'
+
+get_tag_header comment-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with #commented -m message should succeed' '
+ git-tag -s -m "#comment" comment-signed-tag &&
+ get_tag_msg comment-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v comment-signed-tag
+'
+
+echo '#comment' >sigcommentfile
+echo '' >>sigcommentfile
+echo '####' >>sigcommentfile
+get_tag_header commentfile-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with #commented -F messagefile should succeed' '
+ git-tag -s -F sigcommentfile commentfile-signed-tag &&
+ get_tag_msg commentfile-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v commentfile-signed-tag
+'
+
+printf '#comment' >sigcommentnonlfile
+get_tag_header commentnonlfile-signed-tag $commit commit $time >expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag with a #comment and no newline should succeed' '
+ git-tag -s -F sigcommentnonlfile commentnonlfile-signed-tag &&
+ get_tag_msg commentnonlfile-signed-tag >actual &&
+ git diff expect actual &&
+ git-tag -v commentnonlfile-signed-tag
+'
+
+# tags pointing to objects different from commits:
+
+tree=$(git rev-parse HEAD^{tree})
+blob=$(git rev-parse HEAD:foo)
+tag=$(git rev-parse signed-tag)
+
+get_tag_header tree-signed-tag $tree tree $time >expect
+echo "A message for a tree" >>expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag pointing to a tree should succeed' '
+ git-tag -s -m "A message for a tree" tree-signed-tag HEAD^{tree} &&
+ get_tag_msg tree-signed-tag >actual &&
+ git diff expect actual
+'
+
+get_tag_header blob-signed-tag $blob blob $time >expect
+echo "A message for a blob" >>expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag pointing to a blob should succeed' '
+ git-tag -s -m "A message for a blob" blob-signed-tag HEAD:foo &&
+ get_tag_msg blob-signed-tag >actual &&
+ git diff expect actual
+'
+
+get_tag_header tag-signed-tag $tag tag $time >expect
+echo "A message for another tag" >>expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success \
+ 'creating a signed tag pointing to another tag should succeed' '
+ git-tag -s -m "A message for another tag" tag-signed-tag signed-tag &&
+ get_tag_msg tag-signed-tag >actual &&
+ git diff expect actual
+'
+
+# try to verify without gpg:
+
+rm -rf gpghome
+test_expect_failure \
+ 'verify signed tag fails when public key is not present' \
+ 'git-tag -v signed-tag'
+
+test_done
+
diff --git a/t/t7004/pubring.gpg b/t/t7004/pubring.gpg
new file mode 100644
index 0000000000000000000000000000000000000000..83855fa4e1c6c37afe550c17afa1e7971042ded5
GIT binary patch
literal 1164
zc$@)@1ateD0ipy(XUi!O1OT%L_{gO;4KKDfwF;#WWYZ2?*>Ph_j9y>uobJf#jXEbw
zQUOEXs+@;X*)1kyN*7VwW}f-GD3>Vlu2F6j{T^Kt%(kMo(W3C}W^X)NL|0VdGIzc`
z5@TY!;Du~AFGW=#0vYgS@U2j8Q{Qe9F~lQEBVt+(yjM1jQ{YLe0lxsC<HX~BiFSU3
zs3oq~QtxsAzbwuV1N{{&PcudMk6}p><?O}^6vikhMm+>LD}W25r?wdKr$(|R8_;Mn
z&Yh%2Hbu9IX>#(R8S&@jVI!K^K7AI$=A+*-qJ>-J^fdR_m5GZao*%P{nee=O$Eb$s
zes#O%4Z_4OAZW}8Ey8%%w->rA>z!nf)&NPikkr&pkRlB>=W+x68fwevWl9Ys2R3m2
zNPf<ig>x1y^AXyemu>Q}DAp%==Q`5sCrBzLaH^rOm1NLtt-ig*IfY?HMdv66@%u%#
zy0K62;Z+4O3Ol6i*<7GlXeW6FC?0yV!c_#yGozNjrOE#8+Rw@Z8cGAG=eE%uMUW=V
zX(76db;AG@lD)hAv?4<wPasWcbaZ8MAUtDlZEb0EbY*ftWq4t2aBO8RV{dIfh+YH}
z5dr`n1p-EA%P9gI0|pBT2nPcK0~G=T0~P`S0v-VZ7k~f?2@n&u^&ZXMLk)Bt0G~<e
ziCMX)QRqT4mEiivJ-X>{Mxg+pzucC_!d-8(MV+3G?_=VDC^nQ}umS)BxdIIYMrX@T
z5C{Oyxp_ZR>*yfS@@M%BVY6{X4EXUYpbiBs(uw7knRB|b)>)=o+wQ%-v34o&a|fQ;
z&R=xVK8Z-jS8R4m_gj2C$xPq$xv1H553!y9ip8A~vxoyq&fFbw!L$zU@hDh#f$r>>
zAYPcTf%K%xv5<+JivV@Da!&`-v8eIo5ApKIdiK7E`krA1X!I73&)t#yo}GERUSnBN
zlK-+<I<**0!u}jvbPz5b{hhe8_PVcR!i8ObFp-W0bqNWKA+W14zV9Mj$a~(KZ-0uf
z|BVvaf!K}k92MNalP4hQ^Yxqk-*SzY6q{6Cw*+Fr_+LZp=BFzuo3pVX*T?Ic-|hbZ
z1PurPv|=$EKX~Bz_Bz;JW71^>8;AnsY?5ub{hajO)@PHTt`On@Z;}jyeue<@oS$3l
zEu9m5O={<O&85HqUN|R$bZiPXX4YsWsPOn@@M)Lf;hyI_(eM$*#Sf3}T=1jzGvsiy
ziKuCmV^)`UC@8ma=jBiHqr!1L4>w`5P=-vvIiJTGj0-lRpc+EU9(`B#rn1m1WqmXr
z5Z+N|DR*y*k<4fY0I_eP7qVo9Fx58WMwaK^N~I=>1VN29R|Umg^2q$WGlE#9AFC2_
zOYG5M$}OL?FQ)ej0!KGwY-hAFz#wAPr>3&{`s7!HUZ22Y7KY{9ly1wQ8^hqBojPv8
zh)Dz(5dr`S1p-EA%T59t3;+rV5EHib9?jlE4Z-XHpqd%~B34SUmtRi+{;vv2ei?p%
eLjau^#pu5ba=n|GS94<zkje^zT1YFf0ssTLm?$>@
literal 0
Hc$@<O00001
diff --git a/t/t7004/random_seed b/t/t7004/random_seed
new file mode 100644
index 0000000000000000000000000000000000000000..8fed1339ed0a744e5663f4a5e6b6ac9bae3d8524
GIT binary patch
literal 600
zc$@)P0;m1=h9nBV>1C6QsKJEiEJaD@Q3F8s5u<$E+<2(By)JAZSxviTsXg(wKC+O%
zzvV{Z>W3*k?r7~pgmmkbw8-x{Am!eeN)z?cwIHcT2jqgiA(SXo<iO=E?cY80`p#w8
z)O-&?SnwsJ=1VJ-?26&*g88Nr8E=g2onRW^(c+2nJlX)?dmK)tPO0EY-!B!vMCv1)
z-AOW(3WuF+7IdSxMnzrDgnMqVU=|+YFxlY|VeR+Fg<%C@0Xupi0<S7QYJyFTR$}FQ
zzoSAbU>CoCKWKX;!3@L_U=aFUm!M<>ILG}$`bfnadAkLQbI-upV7Qwf^OE&N45Pz<
zk~^KlzNC6)d@QGv=K5-At&A8FS&MQSR`LB}@R1?A3K1p(vM>7CK}EfFhmBJd&cH^-
z(3Ih^`VuoVBB|w~p!Q^#DY%V2A2FhXu<Bp*L)lSCUdqRyI5wxMG&E1sL$)E$Zo&pJ
zgy#;fENqHImgN>LL2!7DhfZ}&;BSAyz=T0#S?2+NET5St@16L?YI?5Io%<uD|2}hl
zx0xsuefz1+bM^-ZIgtKs=)&VAI8(MfytvM>t>%~nsXUb~*EkptHiN?W{=DRu_s;2u
ziHh{2&>;CQO7;>{$DN33_Ef}g+;b<2hIF^p(Y>^riLBb*Y2Xw>F8)jp49&oLKJOic
z+V{Lt!_`eKGhyk5Edie{-^#n!TFlsfux*QBRZEh^4SVePPmb{BvF|>sKd2cYg@vKp
mVI8jcB1(k(tlt^Kr<{EMs>|b*d70nyVMQcc%xEnE(#Uq3d^-35
literal 0
Hc$@<O00001
diff --git a/t/t7004/secring.gpg b/t/t7004/secring.gpg
new file mode 100644
index 0000000000000000000000000000000000000000..d831cd9eb3eee613d3c0e1a71093ae01ea7347e3
GIT binary patch
literal 1237
zc$@*%1S<QL0lNf7XUi!O1OT%L_{gO;4KKDfwF;#WWYZ2?*>Ph_j9y>uobJf#jXEbw
zQUOEXs+@;X*)1kyN*7VwW}f-GD3>Vlu2F6j{T^Kt%(kMo(W3C}W^X)NL|0VdGIzc`
z5@TY!;Du~AFGW=#0vYgS@U2j8Q{Qe9F~lQEBVt+(yjM1jQ{YLe0lxsC<HX~BiFSU3
zs3oq~QtxsAzbwuV1N{{&PcudMk6}p><?O}^6vikhMm+>LD}W25r?wdKr$(|R8_;Mn
z&Yh%2Hbu9IX>#(R8S&@jVI!K^K7AI$=A+*-qJ>-J^fdR_m5GZao*%P{nee=O$Eb$s
zes#O%4Z_4OAZW}8Ey8%%w->rA>z!nf)&NPikkr&pkRlB>=W+x68fwevWl9Ys2R3m2
zNPf<ig>x1y^AXyemu>Q}DAp%==Q`5sCrBzLaH^rOm1NLtt-ig*IfY?HMdv66@%u%#
zy0K62;Z+4O3Ol6i*<7GlXeW6FC?0yV!c_#yGozNjrOE#8+Rw@Z8cGAG=eE%uMUW=V
zX(76db;AG@lD)hA005tK#LT31ryNoF9o-(`X`Xl5w88@mle8j3AWtAoX>@dDav(fo
zZ*6U9baZ8MKxKGgZE$R5E@N+PK8Rif6A=Oc9t8qMXUi!98v_Ol2?z%R0s|ES0|OQU
z0RkQY0vCV)3JDMsw)Gy(-a`#^9RQ%c+5fOQwB&AM#DD9)s1L@!pm9S0pF>@|C2*qL
z%1j5#NZ6^U*PB>^d9VTi0G$Fo1V(4eP7nwH&bfI%Q|ss;(eh{c3}LfzMGW}yE1(Vq
zEz*hQmYH+9vesFqTifovzOi;G@N);A+0I{d(LRYt$5(82OZQuRJjqPo^tq_na}Tkd
z|BA((5wnN`O3vIJaly0>?(ryCcY*Hgm>^!5uz~cX%CV4%oQnW;wsKDg)3K=W<qz@l
z$a?m^i29yk259sakI&ta{GOe8x?W>hQIh|%Svs{CO~U>hTXYaE9sQlSv-Y~LWWt4A
ze=w1b1$7Atj3KbAF~092T*!Ogn{R)Lum6n_*@4)N@EjG~z>_B+>GSoQ{oitpmlT^+
zUAF{c!T4W8?B=H{DVwvgAlJw1n&0jJ00a#P0JLH;8$Wp9`Sv>4USrZ_1sjM0<!q8|
zxc!{;-PUK5pso<&0dJBFgMNkp@|>Sr>@A%Wd`)WSc+I820A4sJf^=*OHfGjnC8+TD
zW$<a2;o+X=JkjtG#>Eeh?p*Mr_A}&gvx%r_lw($xcPJ>gap&bv^P|FXJr6fwvQUOh
zz&W4C8jK4zqM#Z=%N~7K_NKDXEM<K(9uVG9XDN4YijmA{1^}^dq8GAcg)r4N<3^U}
z-b$q=iUdK8Hdh73UGm8MyfcDWr5~#ja!c&dVahF^v@fRj3IazrWNc@&F~A^V)u*Pi
z`ugNogkGP(V-|+x+mvq0pc}*Bpq)By!2khN4M6SOU21NKpXW5P=UU_LoDzvrTdR;4
zU)W&&o9V6>MQOk{A%?1(Ozs{Qqlifa7!d*h2?YX1XUk3k8w>yn2@n&u^&ZXMLk+>~
z0HDxvfGrJTMY@$ys#k#t?D63Zq=W#R3eUeT(L61`VGHe?zP;`rnta#-umS)8nA%Rq
literal 0
Hc$@<O00001
--
1.5.0
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Matthias Lederhofer @ 2007-06-28 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzsurvo1.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> I think the behaviour for receive-pack and the environment the
> hooks run in have been pretty well defined. You start in the
> repository (the directory $GIT_DIR), GIT_DIR is set and points
> at it.
>
> The issue is that the introduction of WORK_TREE enviornment and
> core.worktree mechanism might want to update the semantics. For
> example, some people seem to run checkout (or perhaps "merge")
> to update the associated working tree. Can they find out where
> the root of the working tree is (because they would want to
> chdir to it before saying "git checkout"), given the current
> environment receive-pack sets up for them?
>
> Earlier we said that people who use only GIT_DIR without
> GIT_WORK_TREE nor core.worktree should get exactly the same
> semantics with or without the WORK_TREE topic, so the above may
> not be an issue.
When GIT_WORK_TREE/core.worktree are not set the only difference with
the patch series should be that cwd may be used as working tree in more
cases than before.
I think these are the ways git-receive-pack is executed (in normal
setups):
* local pushes: git_connect() unsets GIT_WORK_TREE.
* ssh: the user might set GIT_WORK_TREE in his shell
configuration, .ssh/environments, .ssh/authorized_keys etc.
git-receive-pack is then executed with GIT_WORK_TREE set.
* git-daemon: git-daemon with --enable=receive-pack allows pushing
and does not unset GIT_WORK_TREE, so a git-daemon started with
GIT_WORK_TREE exported will also have it exported when receive-pack
is executed.
I think it makes sense to unset GIT_WORK_TREE when receive-pack is
started. In the first case GIT_WORK_TREE is unset already and in the
latter two cases I don't think we really need to support that
GIT_WORK_TREE stays exported in the hooks, it could rather happen
accidentally.
When doing more stuff in receive-pack old hooks might stop working
break.
For example receive-pack could set up GIT_WORK_TREE with a sane
default value if a working tree can be found, i.e.
$ export GIT_WORK_TREE=$(dirname $(pwd))
if the working tree is in the parent directory
$ export GIT_WORK_TREE=$(git config core.worktree)
if core.worktree is set and otherwise GIT_WORK_TREE is not exported.
This way hooks can just use GIT_WORK_TREE for the working tree if
they don't need anything special.
^ permalink raw reply
* Problem with "stgit show"
From: Yann Dirson @ 2007-06-28 20:51 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
While investigating bug #8453 (https://gna.org/bugs/?8453) I looked
for the 1st time at how "stg show" is implemented, and it looks like
this and a couple of related parts of the code need some refactoring.
The problem is, "stg show a@b" and "stg show a@b z@b" trigger
different code paths. The problem with the latter is that, having
more than one arg, it gets feed through parse_patches(), which is only
designed to deal with patches in a single stack, and rejects "a@b"
as not a member of the current stack.
The single-arg form, at the opposite, falls into the branch designed
to emulate "git show" by allowing git refs not otherwise meaningful to
stgit. That is, "stg show a@b" seems to only work as a side-effect.
The same difference in handling single-arg from multiple-arg will
similarly cause non-stgit refs to be invalid when not given alone
(ie. "stg show origin/master" works, but "stg show origin/master
patch1" fails with "Unknown patch name: origin/master".
Since the different handling of len(args)==1 results in
inconsistencies, IMHO we should get rid of it. Now adding support for
out-of-this-stack refs to parse_patches() would require a total
rewrite thereof, so I suggest we leave this for another round.
Non-stgit refs should IMHO be dropped. Catalin, you mentionned
consistency with "stg pick" IIRC, but "pick" only ever takes a single
arg, so the commands are clearly too different. We always have
git-show anyway if we want to look at them.
For patches on other branches, we could simply add the common --branch
flag to "stg show". That would not allow to get patches from
different stacks in a single run, and it's a bit more verbose than the
@ syntax for a single patch, but well, that could make sense for 0.13.
I'll send out a couple of patchlets for this.
--
Yann
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jeff King @ 2007-06-28 21:34 UTC (permalink / raw)
To: Theodore Tso; +Cc: Linus Torvalds, Jim Meyering, git
In-Reply-To: <20070628190406.GC29279@thunk.org>
On Thu, Jun 28, 2007 at 03:04:06PM -0400, Theodore Tso wrote:
> This patch skips the fflush() calls when stdout is a regular file, or
> if the environment variable GIT_NEVER_FLUSH_STDOUT is set. This
> latter can speed up a command such as:
>
> (export GIT_NEVER_FLUSH_STDOUT=t; git-rev-list HEAD | wc -l)
I wonder if this would be more natural in the opposite form:
GIT_FLUSH_STDOUT=1 git-rev-list HEAD
In general, you don't want to do the flushing unless:
- it's going to the pager
- some program is reading incrementally
In the first case, we can just turn on GIT_FLUSH_STDOUT when we kick off
the pager. In the second case, that program can just add the variable to
its invocation.
On top of which, in your patch the type of output trumps the environment
variable, which seems backwards. In other words, I can't do this:
GIT_FLUSH_EVEN_THOUGH_ITS_A_FILE=1 git-rev-list HEAD >file
[in another window] tail -f file
I would think an explicit preference from a variable should override any
guesses.
-Peff
^ permalink raw reply
* [StGIT PATCH 1/3] Allow "git show --branch".
From: Yann Dirson @ 2007-06-28 21:44 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070628214242.26983.99859.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/show.py | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/show.py b/stgit/commands/show.py
index ea4c874..c59ac68 100644
--- a/stgit/commands/show.py
+++ b/stgit/commands/show.py
@@ -30,7 +30,9 @@ Show the commit log and the diff corresponding to the given
patches. The output is similar to that generated by the 'git show'
command."""
-options = [make_option('-a', '--applied',
+options = [make_option('-b', '--branch',
+ help = 'use BRANCH instead of the default one'),
+ make_option('-a', '--applied',
help = 'show the applied patches',
action = 'store_true'),
make_option('-u', '--unapplied',
^ permalink raw reply related
* [StGIT PATCH 0/3] cleanup "show" and friends
From: Yann Dirson @ 2007-06-28 21:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The following series implements the suggestion for #8453 outlined in
my previous mail, and adds a minor improvement for hidden patches.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [StGIT PATCH 2/3] Disallow non-patch args to "stg show" (gna #8453).
From: Yann Dirson @ 2007-06-28 21:44 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070628214242.26983.99859.stgit@gandelf.nowhere.earth>
Git-core refs and patch@branch args were not allowed in the
multiple-argument form of "stg show". For consistency we completely
disallow them: git-core refs are available from git-show, and "stg
show patch@branch" as "stg show patch -b branch".
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/show.py | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/stgit/commands/show.py b/stgit/commands/show.py
index c59ac68..3bf4f20 100644
--- a/stgit/commands/show.py
+++ b/stgit/commands/show.py
@@ -55,12 +55,7 @@ def func(parser, options, args):
elif len(args) == 0:
patches = ['HEAD']
else:
- if len(args) == 1 and args[0].find('..') == -1 \
- and not crt_series.patch_exists(args[0]):
- # it might be just a commit id
- patches = args
- else:
- patches = parse_patches(args, applied + unapplied, len(applied))
+ patches = parse_patches(args, applied + unapplied, len(applied))
if options.diff_opts:
diff_flags = options.diff_opts.split()
^ permalink raw reply related
* [StGIT PATCH 3/3] Make hidden patches visible to various commands (notably log, show, pick).
From: Yann Dirson @ 2007-06-28 21:44 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070628214242.26983.99859.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/common.py | 3 ++-
stgit/commands/log.py | 3 ++-
stgit/commands/show.py | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index b05979b..14dbf67 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -89,7 +89,8 @@ def git_id(rev):
patch = series.get_current()
if not patch:
raise CmdException, 'No patches applied'
- if patch in series.get_applied() or patch in series.get_unapplied():
+ if patch in series.get_applied() or patch in series.get_unapplied() or \
+ patch in series.get_hidden():
if patch_id in ['top', '', None]:
return series.get_patch(patch).get_top()
elif patch_id == 'bottom':
diff --git a/stgit/commands/log.py b/stgit/commands/log.py
index e3e17f9..9259290 100644
--- a/stgit/commands/log.py
+++ b/stgit/commands/log.py
@@ -90,7 +90,8 @@ def func(parser, options, args):
raise CmdException, 'No patches applied'
elif len(args) == 1:
name = args[0]
- if not name in crt_series.get_applied() + crt_series.get_unapplied():
+ if not name in crt_series.get_applied() + crt_series.get_unapplied() + \
+ crt_series.get_hidden():
raise CmdException, 'Unknown patch "%s"' % name
else:
parser.error('incorrect number of arguments')
diff --git a/stgit/commands/show.py b/stgit/commands/show.py
index 3bf4f20..2b22744 100644
--- a/stgit/commands/show.py
+++ b/stgit/commands/show.py
@@ -55,7 +55,8 @@ def func(parser, options, args):
elif len(args) == 0:
patches = ['HEAD']
else:
- patches = parse_patches(args, applied + unapplied, len(applied))
+ patches = parse_patches(args, applied + unapplied +\
+ crt_series.get_hidden(), len(applied))
if options.diff_opts:
diff_flags = options.diff_opts.split()
^ permalink raw reply related
* [PATCH] gitweb: make "No commits" in project list gray, not bold green
From: Matt McCutchen @ 2007-06-28 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
A missing return statement in git_get_last_activity made gitweb think
a project with no commits was in age class "age0", so the "No commits"
appeared in bold green, which was ridiculous. I added the return so
those projects get "noage" and added a block to gitweb.css to format
the "No commits" text gray.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
---
When I visited http://repo.or.cz/ , this bug jumped out at me!
gitweb/gitweb.css | 6 ++++++
gitweb/gitweb.perl | 1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 7908fe3..096313b 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -281,6 +281,12 @@ table.diff_tree span.file_status.copied {
color: #70a070;
}
+/* noage: "No commits" */
+table.project_list td.noage {
+ color: #808080;
+ font-style: italic;
+}
+
/* age2: 60*60*24*2 <= age */
table.project_list td.age2, table.blame td.age2 {
font-style: italic;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7b0e110..b251c44 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1528,6 +1528,7 @@ sub git_get_last_activity {
my $age = time - $timestamp;
return ($age, age_string($age));
}
+ return (undef, undef);
}
sub git_get_references {
--
1.5.2.2.552.gc32f
^ permalink raw reply related
* Re: Bug: segfault during git-prune
From: Andy Parkins @ 2007-06-28 22:21 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <alpine.LFD.0.98.0706280844460.8675@woody.linux-foundation.org>
On Thursday 2007, June 28, Linus Torvalds wrote:
> On Thu, 28 Jun 2007, Andy Parkins wrote:
> > I ran git-prune on a repository and got this:
> >
> > $ git-prune
> > error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a
> > commit Segmentation fault (core dumped)
>
> Do you have subprojects in that git repo?
Yes. I'm also doing something that is possibly very naughty; and I'm sure
you're going to say "what on earth do you expect when you've done _that_"
The subproject is the same repository... It's a git conversion of the
ffmpeg history; ffmpeg uses svn:externals for the libswscale directory; so
I set that as an independent branch in the same repository, fetched with
git-svn as well. Then I cloned the repository into a subdirectory of
itself.
$ git clone -n . libswscale
Then I went into libswscale/.git/ and ln -s objects, refs, info, and logs.
In fact the only thing that isn't shared is HEAD.
Then I changed into libswscale and checked out the libswscale branch. Back
in the ffmpeg repository I git-add the libswscale directory and everything
seems to be working wonderfully.
> And the only case I know of that does that is using an old git binary, or
> a unconverted git code-path program, on a repository with subprojects
> when the code-path doesn't understand that a tree can contain pointers to
> commits.
Sounds like the last one to me. I tend to be only a few days behind
upstream git.
> Yeah, git-fsck knows about subprojects. I bet git-prune just doesn't.
>
> And indeed.. Here's a patch for it, but the fact is, you really should
> *not* prune that repository, because you'll prune away all the subproject
> data, which you seem to have in the same repo!
Correct; you did well figuring that out from the meagre information I gave.
I had hoped that git-prune wouldn't be a risk because I have:
* -- * -- * -- * -- * (ffmpeg-svn)
* -- * -- * -- * (libswscale-svn)
Then I forked master from ffmpeg-svn and added the libswscale-svn branch as
a submodule as described above. Now, because the submodule always refers
to commits that are ancestors of libswscale-svn, they'll never be seen as
dangling and pruned?
> (General rule: never *ever* prune a shared object repository!)
Even when I'm sure that every object of interest is behind a head ref?
> ---
> reachable.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
The repository in question is on my work computer, so I won't be able to try
this patch until Monday. I'll report back then.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Bug: segfault during git-prune
From: Linus Torvalds @ 2007-06-28 22:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200706282321.44244.andyparkins@gmail.com>
On Thu, 28 Jun 2007, Andy Parkins wrote:
>
> I had hoped that git-prune wouldn't be a risk because I have:
>
> * -- * -- * -- * -- * (ffmpeg-svn)
>
> * -- * -- * -- * (libswscale-svn)
Ok. If all subproject branches are also visible in the superproject as
refs, then "git prune" should work fine, and you can apply my patch and it
should just work very naturally: the reachability analysis will find the
subprojects not through the superproject link, but simply through the
direct refs to the subproject.
> > (General rule: never *ever* prune a shared object repository!)
>
> Even when I'm sure that every object of interest is behind a head ref?
So yes, in that case, you're ok.
This is not unlike just having two different repositories sharing the same
object directory: as long as the two different repositories both have the
appropriate refs, pruning is fine. In other words, you can see them as
just independent branches in the same repo.
And in fact, subprojects are obviously very much *designed* to work that
way: a subproject is basically a "different repository". So the basic rule
is that if it would work with totally independent repos, it works with
subprojects.
[ That's all aside from the kind of bug that you found, where some code
that parses the tree structures hadn't been updated for subprojects, of
course ]
Anyway, if that patch works for you, I'd suggest you just pass it on to
Junio (and feel free to add my "Signed-off-by:" on it - but conditional on
you having actually tested it).
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox