* [PATCH] gitweb: Fix @git_base_url_list usage
From: Petr Baudis @ 2006-09-22 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060920004935.GJ8259@pasky.or.cz>
As it is now, that array was never used because the customurl accessor was
broken and ''unless @url_list'' never happenned.
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f7e7d10..a357604 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -752,7 +752,7 @@ sub git_get_project_description {
sub git_get_project_url_list {
my $path = shift;
- open my $fd, "$projectroot/$path/cloneurl" or return undef;
+ open my $fd, "$projectroot/$path/cloneurl" or return;
my @git_project_url_list = map { chomp; $_ } <$fd>;
close $fd;
^ permalink raw reply related
* Re: [PATCH 4/6] gitweb: Link to associated tree from a particular log item in full log view
From: Petr Baudis @ 2006-09-22 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz8s7cvy.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Sep 22, 2006 at 06:18:09AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I presume you are running this version at repo.or.cz, but
>
> (1) go to http://repo.or.cz/?p=stgit.git;a=log
> (2) pick "tree" of one of the commits
> (3) go browser-back, then pick "tree" from the top navbar
>
> The resulting tree view of (2) lacks navbar while (3) looks much
> saner.
Oops. It's trivial typo:
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d2366c7..c5f3810 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2880,7 +2880,7 @@ sub git_log {
" | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") .
" | " .
- $cgi->a({-href => href(action=>"tree", hash=>$commit), hash_base=>$commit}, "tree") .
+ $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") .
"<br/>\n" .
"</div>\n" .
"<i>" . esc_html($co{'author_name'}) . " [$ad{'rfc2822'}]</i><br/>\n" .
> You do not have the tree object name available in git_log to
> generate an URL with both h and hb, and getting to it is an
> extra work.
Well using commit hash as a tree id works just fine...
> This would fix this particular breakage.
My knowledge of gitweb.perl innards isn't good enough for me to safely
ack/nak a change such deep down the chain.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply related
* Re: [PATCH 5/6] gitweb: Rename "plain" labels to "raw"
From: Petr Baudis @ 2006-09-22 23:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ef08v5$mk9$1@sea.gmane.org>
Dear diary, on Fri, Sep 22, 2006 at 11:04:49AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > I don't have much preference either way and as far as I'm concerned, it may
> > go the other way as well. Consistency is what is important.
>
> "raw" link was introduced in 25b7c18ecd9779158cb1c02572396bab22c6e0cf
> by Luben Tuikov. I'd rather use "plain"...
I kind of like "raw" more because it's IMHO more obvious what it exactly
is (it could also mean some stripped-down HTML or whatever otherwise)
and is more appropriate for things that actually are not plaintext, like
pictures.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* [PATCH] Fix buggy ref recording
From: Petr Baudis @ 2006-09-22 23:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20060919205554.GA8259@pasky.or.cz>
Dear diary, on Tue, Sep 19, 2006 at 10:55:54PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> Dear diary, on Thu, Sep 14, 2006 at 07:14:47PM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
> > + ref_file = git_path(ref);
>
> You slip...
> You fall...
> *BLAMMMM!!!*
>
> Cloning a repository with '%s' tag over HTTP now dumps core nicely, and
> I guess this kind of bugs tends to be exploitable.
And since just reporting it did not magically result in a fix... ;-)
-8<-
There is a format string vulnerability introduced with the packed refs
file format.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
refs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 40f16af..5fdf9c4 100644
--- a/refs.c
+++ b/refs.c
@@ -472,7 +472,7 @@ static struct ref_lock *lock_ref_sha1_ba
lock->ref_name = xstrdup(ref);
lock->log_file = xstrdup(git_path("logs/%s", ref));
- ref_file = git_path(ref);
+ ref_file = git_path("%s", ref);
lock->force_write = lstat(ref_file, &st) && errno == ENOENT;
if (safe_create_leading_directories(ref_file))
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply related
* [PATCH] Make path in tree view look nicer
From: Petr Baudis @ 2006-09-22 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Based on talk on the IRC with Junio some evenings ago, I've updated the
path showing in tree view to look better and sent updated patches
privately, but it seems the old version ended up being used, so here's
the new one again.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a357604..d2366c7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1527,14 +1527,14 @@ sub git_print_page_path {
print "<div class=\"page_path\">";
print $cgi->a({-href => href(action=>"tree", hash_base=>$hb),
- -title => '/'}, '/');
- print " ";
+ -title => 'tree root'}, "[$project]");
+ print " / ";
foreach my $dir (@dirname) {
$fullname .= ($fullname ? '/' : '') . $dir;
print $cgi->a({-href => href(action=>"tree", file_name=>$fullname,
hash_base=>$hb),
- -title => $fullname}, esc_html($dir . '/'));
- print " ";
+ -title => $fullname}, esc_html($dir));
+ print " / ";
}
if (defined $type && $type eq 'blob') {
print $cgi->a({-href => href(action=>"blob_plain", file_name=>$file_name,
@@ -1543,7 +1543,7 @@ sub git_print_page_path {
} elsif (defined $type && $type eq 'tree') {
print $cgi->a({-href => href(action=>"tree", file_name=>$file_name,
hash_base=>$hb),
- -title => $name}, esc_html($basename . '/'));
+ -title => $name}, esc_html($basename));
} else {
print esc_html($basename);
}
^ permalink raw reply related
* [PATCH] Make cvsexportcommit work with filenames containing spaces.
From: Robin Rosenberg @ 2006-09-22 22:35 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Binary files are except to this so far.
---
git-cvsexportcommit.perl | 24 +++++++++++++++--
t/t9200-git-cvsexportcommit.sh | 55 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 99b3dc3..d78100c 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -121,7 +121,14 @@ #print @files;
$? && die "Error in git-diff-tree";
foreach my $f (@files) {
chomp $f;
- my @fields = split(m!\s+!, $f);
+ $f =~ m/^(\S+) (\S+) (\S+) (\S+) (\S+) (.*)/;
+ my @fields = ();
+ $fields[++$#fields] = $1;
+ $fields[++$#fields] = $2;
+ $fields[++$#fields] = $3;
+ $fields[++$#fields] = $4;
+ $fields[++$#fields] = $5;
+ $fields[++$#fields] = $6;
if ($fields[4] eq 'A') {
my $path = $fields[5];
push @afiles, $path;
@@ -217,7 +224,7 @@ foreach my $f (@bfiles) {
}
# replace with the new file
- `git-cat-file blob $blob > $f`;
+ `git-cat-file blob $blob > "$f"`;
# TODO: something smart with file modes
@@ -231,7 +238,18 @@ ## apply non-binary changes
my $fuzz = $opt_p ? 0 : 2;
print "Patching non-binary files\n";
-print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
+
+my $saveslash = $/;
+undef $/;
+
+open DIFF, "git-diff-tree -p $parent -p $commit|" || die "Cannot diff";
+open PATCH, "|patch -p1 -F $fuzz" || die "Cannot patch";
+my $delta = <DIFF>;
+close DIFF || die "Could not diff";
+$delta =~ s/\n(index [^\n]*)\n(--- [^\n]*)\n(\+\+\+ [^\n]*)\n(@@[^\n]*@@)\n/$1\n$2\t\n$3\t\n$4\n/sg;
+print PATCH $delta;
+close PATCH || die "Could not patch";
+$/ = $saveslash;
my $dirtypatch = 0;
if (($? >> 8) == 2) {
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
new file mode 100755
index 0000000..1041bb6
--- /dev/null
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -0,0 +1,55 @@
+#!/bin/bash
+
+test_description='CVS export comit.
+
+These tests are ad-hoc ones made to test
+some changes, not a complete test.'
+
+. ./test-lib.sh
+
+export CVSROOT=$(dirname $(pwd))/cvsroot
+export CVSWORK=$(dirname $(pwd))/cvswork
+rm -rf $CVSROOT $CVSWORK
+mkdir $CVSROOT
+cvs init
+cvs -Q co -d $CVSWORK .
+export GIT_DIR=$(pwd)/.git
+
+echo >empty &&
+git add empty &&
+git commit -a -m "Initial"
+
+test_expect_success \
+ 'New file' \
+ 'echo hello >newfile.txt &&
+ git add newfile.txt &&
+ git commit -a -m "Hello" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd $CVSWORK &&
+ git cvsexportcommit -c $id &&
+ test $(cat CVS/Entries|wc -l) = 2
+ )'
+
+test_expect_success \
+ 'New file with spaces in file name' \
+ 'echo ok then >"with spaces.txt" &&
+ git add "with spaces.txt" && \
+ git commit -a -m "With spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd $CVSWORK &&
+ git-cvsexportcommit.perl -c $id &&
+ test $(cat CVS/Entries|wc -l) = 3
+ )'
+
+test_expect_success \
+ 'Update file with spaces in file name' \
+ 'echo Ok then >>"with spaces.txt" &&
+ git add "with spaces.txt" &&
+ git commit -a -m "Update with spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd $CVSWORK &&
+ git-cvsexportcommit.perl -c $id &&
+ test $(cat CVS/Entries|wc -l) = 3
+ )'
+
+test_done
^ permalink raw reply related
* [PATCH] Make cvsexportcommit remove files too.
From: Robin Rosenberg @ 2006-09-22 22:35 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
---
git-cvsexportcommit.perl | 2 +-
t/t9200-git-cvsexportcommit.sh | 12 ++++++++++++
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d78100c..0b0d186 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -142,7 +142,7 @@ foreach my $f (@files) {
if ($fields[4] eq 'M') {
push @mfiles, $fields[5];
}
- if ($fields[4] eq 'R') {
+ if ($fields[4] eq 'D') {
push @dfiles, $fields[5];
}
}
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 1041bb6..524fa2b 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -52,4 +52,16 @@ test_expect_success \
test $(cat CVS/Entries|wc -l) = 3
)'
+test_expect_success \
+ 'Remove file with spaces in file name' \
+ 'echo Ok then >"with spaces.txt" &&
+ rm -v "with spaces.txt" && \
+ git rm "with spaces.txt" && \
+ git commit -a -m "Remove file" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd $CVSWORK &&
+ git-cvsexportcommit.perl -v -c $id &&
+ test $(cat CVS/Entries|wc -l) = 2
+ )'
+
test_done
^ permalink raw reply related
* [PATCH] Quote arguments to tr in test-lib
From: Robin Rosenberg @ 2006-09-22 22:35 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
When there are single-character filenames in the test directory,
the shell tries to expand regexps meant for tr.
---
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index e262933..e75ad5f 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -34,7 +34,7 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR VISUAL
-case $(echo $GIT_TRACE |tr [A-Z] [a-z]) in
+case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
1|2|true)
echo "* warning: Some tests will not work if GIT_TRACE" \
"is set as to trace on STDERR ! *"
^ permalink raw reply related
* Re: [PATCH] Remove branch by putting a null sha1 into the ref file.
From: Junio C Hamano @ 2006-09-22 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Christian Couder
In-Reply-To: <Pine.LNX.4.64.0609180926590.4388@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> It's entirely possible that the proper way to do branch deletion with
> packed branches is to simply re-pack without the old branch, rather than
> the negative branch model. I couldn't really decide.
After playing with branch deletion issues for some time, I
started to think it would be a lot simpler if we do not mark
a deleted branch with 0{40}.
I started rewriting git-branch in C, mostly reusing Kristian
Høgsberg's patch but taking care of the reflog issue still left
in the original thread:
Subject: [PATCH] branch as a builtin (again)
Date: Sun, 20 Aug 2006 17:22:18 -0400
Message-ID: <59ad55d30608201422h4a6d40f7y7782212637380438@mail.gmail.com>
We need to take care of two funny cases around packed-ref in
lock_ref_sha1_basic() where a creation of a new ref takes
place. It needs to deal with two issues.
* We should not allow frotz branch to be created when
frotz/nitfol branch already exists (packed and pruned).
Being able to create .git/refs/heads/frotz.lock file and
being able to rename it to .git/refs/heads/frotz is not
enough. The other way around has the same problem. So we
would need to have a for_each_ref() to check if the ref being
created is a prefix of an existing one or there is an
existing one that is a prefix of the one being created.
* When creating frotz branch, there may be a leftover
.git/refs/heads/frotz/ directory on the filesystem. If the
directory is empty (or contains only empty subdirectories),
we can rmdir recursively and make refs/heads/frotz file
there. Otherwise it means that a branch frotz/something
still exists there, but the above prefix check should have
taken care of it. So in practice we should always be able to
just do an equivalent of "rm -fr .git/refs/heads/frotz" when
creating a frotz branch.
But the latter falls apart if we use 0{40} convention to mark a
deleted branch. Removing .git/refs/heads/frotz/nitfol file which
has 0{40} and creating .git/refs/heads/frotz file resurrects
frotz/nitfol branch that is still packed. Not allowing frotz
branch to be created only because we had deleted frotz/nitfol
previously is not what we want either, so at that point we need
to repack without frotz/nitfol anyway.
Which makes me think that we would better repack when removing
any existing ref.
BTW, the second issue exists without packed ref; currently we
cannot do
git branch foo/bar
git branch -d foo/bar
git branch foo
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Junio C Hamano @ 2006-09-22 19:08 UTC (permalink / raw)
To: Santi; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <8aa486160609220334w39a7d455s66f815f00ef6b6f6@mail.gmail.com>
Santi <sbejar@gmail.com> writes:
> Something like
> http://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2
> ?
I do not have access to marc at the moment but I have saved a
patch from you back from July in one of my freezer mbox. IIRC
your message was not for inclusion but more as a firestarter for
discussions, and the discussion never came to conclusion with
appliable set of patches.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Add committags support
From: Jakub Narebski @ 2006-09-22 17:55 UTC (permalink / raw)
To: git
In-Reply-To: <200609212356.31806.jnareb@gmail.com>
Jakub Narebski wrote:
> Below there is preliminary (hence RFC) committag support for gitweb,
> based on the idea introduced by Sham Chukoury to gitweb-xmms2.
>
> The code has all the possible committags I could think of enabled;
> not all are tested, though. This includes existing commitsha tag
> support (full sha links to commit view, is sha is sha of commit),
> mantis bug and feature tags from gitweb-xmms2 (there is no release
> committag of gitweb-xmms2, but it should be fairly easy to add it),
> bugzilla committag for the Linux kernel, plain text URL committag
> (probably doesn't work that well, marking as links examples, and
> sometimes protocol specification), and Message-Id committag via
> GMane git mailing list (and not only) archive -- not tested.
>
> Comments? Discussion?
For example: is the committags code overengineered, too complex?
Or is it not generic enough? Should all committags code be put into
format_log_line_html, or should we add another subroutine,
format_committags (or similar)?
What other committags would you like to have?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* RE: [PATCH] Build on Debian GNU/Hurd
From: Ramsay Jones @ 2006-09-22 17:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Gerrit Pape, git
In-Reply-To: <Pine.LNX.4.64.0609211050390.4388@g5.osdl.org>
On Thurs Sept 21 at 18:54, Linus Torvalds wrote:
> On Thu, 21 Sep 2006, Ramsay Jones wrote:
> >
> > IMHO, setting the value in the Makefile, for systems that don't define
> > PATH_MAX, is a much better solution. In fact, that is what I thought was
> > already being done.
>
> Well, considering that we _can_ test defines, why not just do it
> automatically.
>
> In other words, instead of this patch:
>
> > > -
> > > -#ifndef PATH_MAX
> > > -# define PATH_MAX 4096
> > > -#endif
> > > +#include <limits.h>
>
> Just make the code read
>
> #include <limits.h>
>
> /*
> * Insane systems don't have a fixed PATH_MAX, it's POSIX
> * compliant but not worth worrying about, so if we didn't
> * get PATH_MAX from <limits.h>, just make up our own
> */
> #ifndef PATH_MAX
> # define PATH_MAX 4096
> #endif
>
> and after that we can just ignore the issue forever more.
Yes, that would certainly be a solution. (Of course, setting the value in
the Makefile would still be a better solution ;-)
However, ...
>
> The thing is, it's not like we even really _care_ what PATH_MAX is all
> that deeply. We just want to get some random value that is reasonable.
>
> Linus
>
... given the above, a better solution is: don't use PATH_MAX.
Simply #define a new symbol in a suitable git header file and globally
replace uses of PATH_MAX with the new symbol. Job done.
All the best,
Ramsay
^ permalink raw reply
* Re: git commands that only work correctly at top directory
From: Thomas Kolejka @ 2006-09-22 17:08 UTC (permalink / raw)
To: git; +Cc: Nguyen Thai Ngoc Duy
In-Reply-To: <fcaeb9bf0609220221w3a65af24u9db1da4e1be0d1eb@mail.gmail.com>
-------- Original-Nachricht --------
Datum: Fri, 22 Sep 2006 16:21:09 +0700
Von: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
An: git@vger.kernel.org
Betreff: git commands that only work correctly at top directory
Did you set $GIT_DIR? ... to an absolute path or "./.git" ?
> Here is the list (checks are done in with 1.4.2.rc4):
> count-objects (always 0 objects, 0 kilobytes)
Works for me in every directory with GIT_DIR abolute or ./.git
> bisect (fatal: Not a git repository: '.git'. Bad HEAD - I need a symbolic
> ref)
with an absolute GIT_DIR works from every directory - at least bisect start
> describe (fatal: Not a valid object name HEAD)
with an absolute GIT_DIR works from every directory.
v1.4.1-gcddb939
> repack (line 42: cd: .git/objects/pack: No such file or directory. And
> it creates a new .git directory in current directory)
> git format-patch in subdir generates files in topdir instead of
> current dir as documented in its man page
>
> BTW, either git blame or git annotate should be available in git help's
> listing.
> git format-patch with no argument shows nothing. It should show help
> usage instead.
> I might miss some commands because I only tested commands I'm familiar
> with.
> --
> Duy
Thomas
--
NEU: GMX DSL Sofort-Start-Set - blitzschnell ins Internet!
Echte DSL-Flatrate ab 0,- Euro* http://www.gmx.net/de/go/dsl
^ permalink raw reply
* [PATCH] git-repack: allow git-repack to run in subdirectory
From: Jeff King @ 2006-09-22 15:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <fcaeb9bf0609220221w3a65af24u9db1da4e1be0d1eb@mail.gmail.com>
Now that we explicitly create all tmpfiles below $GIT_DIR, there's no reason
to care about which directory we're in.
Signed-off-by: Jeff King <peff@peff.net>
---
git-repack.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 9ae5092..f2c9071 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -4,6 +4,7 @@ # Copyright (c) 2005 Linus Torvalds
#
USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
+SUBDIRECTORY_OK='Yes'
. git-sh-setup
no_update_info= all_into_one= remove_redundant=
--
1.4.2.1.gb6052-dirty
^ permalink raw reply related
* Re: git commands that only work correctly at top directory
From: Nguyen Thai Ngoc Duy @ 2006-09-22 12:57 UTC (permalink / raw)
To: git
In-Reply-To: <20060922112615.GB10124@moooo.ath.cx>
On 9/22/06, Matthias Lederhofer <matled@gmx.net> wrote:
> count-objects and describe work in the current master.
Yes. Somehow my master is not updated to origin :(
> repack/bisect/reset and some other commands make only sense from the
> toplevel directory but anyway I would allow them to be run in a
> subdirectory and change up to the topdirectory (like git checkout for
> branch switching). Is there any good reason not to do this? I found
> it often annoying to go down to the toplevel directory/get a new shell
> just to reset to HEAD~1.
In case there is good reason not to do it, I'd like those commands to
tell users run them in top directory. (Although I prefer to run it
everywhere, I hate to cd around just for one command)
--
Duy
^ permalink raw reply
* Re: git commands that only work correctly at top directory
From: Matthias Lederhofer @ 2006-09-22 11:26 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0609220221w3a65af24u9db1da4e1be0d1eb@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Here is the list (checks are done in with 1.4.2.rc4):
> count-objects (always 0 objects, 0 kilobytes)
> bisect (fatal: Not a git repository: '.git'. Bad HEAD - I need a symbolic
> ref)
> describe (fatal: Not a valid object name HEAD)
> repack (line 42: cd: .git/objects/pack: No such file or directory. And
> it creates a new .git directory in current directory)
count-objects and describe work in the current master.
repack/bisect/reset and some other commands make only sense from the
toplevel directory but anyway I would allow them to be run in a
subdirectory and change up to the topdirectory (like git checkout for
branch switching). Is there any good reason not to do this? I found
it often annoying to go down to the toplevel directory/get a new shell
just to reset to HEAD~1.
^ permalink raw reply
* [PATCH] format-patch: use cwd as default output directory
From: Matthias Lederhofer @ 2006-09-22 11:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0609220221w3a65af24u9db1da4e1be0d1eb@mail.gmail.com>
---
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> git format-patch in subdir generates files in topdir instead of
> current dir as documented in its man page
Here is a patch for this.
---
builtin-log.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index fbc58bb..130b53a 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -270,6 +270,8 @@ int cmd_format_patch(int argc, const cha
rev.extra_headers = extra_headers;
+ output_directory = prefix;
+
/*
* Parse the arguments before setup_revisions(), or something
* like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
--
1.4.2.1.ge767
^ permalink raw reply related
* Re: Git user survey and `git pull`
From: Santi @ 2006-09-22 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vu0305wh8.fsf@assigned-by-dhcp.cox.net>
2006/9/22, Junio C Hamano <junkio@cox.net>:
> I am actually in favor of adding config mechanism that lets you
> say things like:
>
> When on branch 'foo':
>
> - pull without any argument shall use .git/remotes/$that,
> instead of the usual .git/remotes/origin;
>
> - pull without pathspec arguments shall use the named
> .git/remotes/ file to learn from which URL to fetch from,
> which remote branches to fetch and which local branches to
> store them, but merge $this_and_that remote heads regardless
> of what .git/remotes/ file says;
>
Something like
http://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2
?
Santi
^ permalink raw reply
* git commands that only work correctly at top directory
From: Nguyen Thai Ngoc Duy @ 2006-09-22 9:21 UTC (permalink / raw)
To: git
Here is the list (checks are done in with 1.4.2.rc4):
count-objects (always 0 objects, 0 kilobytes)
bisect (fatal: Not a git repository: '.git'. Bad HEAD - I need a symbolic ref)
describe (fatal: Not a valid object name HEAD)
repack (line 42: cd: .git/objects/pack: No such file or directory. And
it creates a new .git directory in current directory)
git format-patch in subdir generates files in topdir instead of
current dir as documented in its man page
BTW, either git blame or git annotate should be available in git help's listing.
git format-patch with no argument shows nothing. It should show help
usage instead.
I might miss some commands because I only tested commands I'm familiar with.
--
Duy
^ permalink raw reply
* Re: [PATCH 5/6] gitweb: Rename "plain" labels to "raw"
From: Jakub Narebski @ 2006-09-22 9:04 UTC (permalink / raw)
To: git
In-Reply-To: <20060922011950.15909.78402.stgit@rover>
Petr Baudis wrote:
> I don't have much preference either way and as far as I'm concerned, it may
> go the other way as well. Consistency is what is important.
"raw" link was introduced in 25b7c18ecd9779158cb1c02572396bab22c6e0cf
by Luben Tuikov. I'd rather use "plain"...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-push of new, tiny branch doing more work than necessary?
From: Andy Whitcroft @ 2006-09-22 7:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, git
In-Reply-To: <Pine.LNX.4.63.0609220031570.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 21 Sep 2006, Carl Worth wrote:
>
>> I've run through something quite like the following scenario a few
>> times lately:
>>
>> git pull origin
>> git checkout -b experiment
>> # hack a file or two
>> git commit -a -m "new experiment"
>> git push origin experiment
>>
>> What I expect at this point is for git to push the few newly created
>> objects out to the repository. Instead it talks about generating,
>> deltifying, transferring, and unpacking thousands of objects (see
>> below).
>
> I experienced something like this, too, but did not have the time to debug
> it. But alas, some time (I think last week) it started working as expected
> again.
I hope this started working again because we fixed it this time. Two
bugs were fixed in this area. First any branch names over about 40
characters in length were being ignored completely due to a validation
bug. Second in an attempt to ensure we didn't bust the 900 entry
command line limit for rev-list we were restricting ourselves to 16
remote refs as possible bases. master now has these changes in it and I
am no longer seeing this behavior.
>
>> git version 1.4.2.rc2.gef1d9
>
> Please try a more recent version (yours is from Jul 27).
-apw
^ permalink raw reply
* Re: [PATCH 0/6] packed deltas with offset to base instead of sha1
From: Junio C Hamano @ 2006-09-22 4:57 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, git
In-Reply-To: <20060921160227.GC3934@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> Nice, although I suspect this would make it a bit more involved
>> to merge a few outstanding stuff.
>
> If you are talking about my mmap window code merge in Nico's
> work first...
> However I have looked at the merge and I more or less need to
> rewrite a good chunk of it just to get it onto 106d7; rewriting it
> onto Nico's work here is probably going to be about the same amount
> of effort.
I had the same impression, although without seeing your code.
Will see to it to have delta-offset code in "next" soonish.
Thanks.
^ permalink raw reply
* Re: Git user survey and `git pull`
From: Junio C Hamano @ 2006-09-22 4:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609211027440.4388@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I agree that the clarifications from Shawn are probably improvements, but
> I'd actually like to solve the problem a bit differently. Namely, I was
> hoping that the per-branch configuration would solve the confusion.
>
> Right now, a plain "git pull" means "fetch all branches and merge the
> first one", and the thing is, that's generally the right thing _only_ if
> you pull into "master".
>
> It's usually exactly the _wrong_ thing to do for any other branch. In
> particular, if you work with a project that has lots of branches, and
> you're working in another branch (that is directly tracking a remote, for
> example), doing a "git pull" definitely should _not_ merge the first head.
> It should fetch everything, and possibly merge the _matching_ head.
>
> Which it doesn't do right now.
I am actually in favor of adding config mechanism that lets you
say things like:
When on branch 'foo':
- pull without any argument shall use .git/remotes/$that,
instead of the usual .git/remotes/origin;
- pull without pathspec arguments shall use the named
.git/remotes/ file to learn from which URL to fetch from,
which remote branches to fetch and which local branches to
store them, but merge $this_and_that remote heads regardless
of what .git/remotes/ file says;
- you shall not use "reset" other than resetting to the HEAD;
- you shall not use "rebase";
- you shall not merge from $this_and_that branches;
- your commit identity shall be $whoami, not the usual
core.user;
I am not motivated enough to do that myself, though.
^ permalink raw reply
* Re: [PATCH] cvsimport move over to using git for each ref to read refs
From: Junio C Hamano @ 2006-09-22 4:57 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <4512804C.8060807@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> ... I've taken the liberty of updating and clarifying the language
> to make it very obvious from the outset that the language specific
> output formats are for generating eval'able snippets and added a simple
> example of it to complement your complex one.
>
> Patch to follow.
Thanks.
^ permalink raw reply
* Re: [RFC] git-pack-refs --prune
From: Junio C Hamano @ 2006-09-22 4:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609210815100.4388@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 21 Sep 2006, Junio C Hamano wrote:
>>
>> Ok, so I did these and the result is a 4-patch series.
>
> Looks good to me. I would have combined 2/3, since the bulk of them is the
> calling conversion change, and they both add a new argument to the same
> function, so combining them would make just one patch that isn't even
> noticeably larger than either of the two originals, but that's just a
> small nitpick.
Actually I did these two as a single change and then later split
them. Unfortunately cherry-picking only 3 without 2 would not
have worked anyway in this particular case with git, but an
ideal SCM would have done a better job. It's just taste and
principle and splitting them into two would not have any
practical advantage in the real world.
Side note to interested bystanders.
Patch 2 changes function signature of for_each_ref() and
friends and adds one parameter, void *cbdata, to them and the
called-back functions. Typical changes looked like these:
+typedef int each_ref_fn(const char *refname, const unsigned char *sha1, void *cb_data);
-static int name_ref(const char *path, const unsigned char *sha1)
+static int name_ref(const char *path, const unsigned char *sha1, void *cb_data)
- for_each_ref(name_ref);
+ for_each_ref(name_ref, &tags_only);
Then patch 3 adds another parameter, int flags, to the same functions involved:
-typedef int each_ref_fn(const char *refname, const unsigned char *sha1, void *cb_data);
+#define REF_ISSYMREF 01
+#define REF_ISPACKED 02
+typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags, void *cb_data);
-static int name_ref(const char *path, const unsigned char *sha1, void *cb_data)
+static int name_ref(const char *path, const unsigned char *sha1, int flags, void *cb_data)
An ideal SCM should help the user who wants to cherry pick patch
3 without patch 2, effectively applying a patch like this:
* Type definition of for_each_ref() callback function (with
flags but without callback data):
+#define REF_ISSYMREF 01
+#define REF_ISPACKED 02
+typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags);
* An actual callback function:
-static int name_ref(const char *path, const unsigned char *sha1)
+static int name_ref(const char *path, const unsigned char *sha1, int flags)
* The call-site of for_each_ref (note patch2 and patch2+patch3
have the same effect):
- for_each_ref(name_ref);
+ for_each_ref(name_ref, &tags_only);
^ 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