* [PATCH 2/2] gitweb: Use git-for-each-ref to generate list of heads and/or tags
From: Jakub Narebski @ 2006-11-02 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200611022017.31351.jnareb@gmail.com>
From 4d86b34d49dd1f18da465952be8306348fef5150 Mon Sep 17 00:00:00 2001
From: Jakub Narebski <jnareb@gmail.com>
Date: Thu, 2 Nov 2006 20:14:15 +0100
Subject: [PATCH 2/2] gitweb: Use git-for-each-ref to generate list of heads and/or tags
Add two subroutines: git_get_heads_list and git_get_refs_list, which
fill out needed parts of refs info (heads and tags respectively) info
using single call to git-for-each-ref, instead of using
git-peek-remote to get list of references and using parse_ref for each
ref to get ref info, which in turn uses at least one call of git
command.
Replace call to git_get_refs_list in git_summary by call to
git_get_references, git_get_heads_list and git_get_tags_list
(simplifying this subroutine a bit). Use git_get_heads_list in
git_heads and git_get_tags_list in git_tags. Modify git_tags_body
slightly to accept output from git_get_tags_list.
Remove no longer used, and a bit hackish, git_get_refs_list.
parse_ref is no longer used, but is left for now.
Generating "summary" and "tags" views should be much faster for
projects which have large number of tags.
CHANGES IN OUTPUT: Before, if ref in refs/tags was tag pointing to
commit we used committer epoch as epoch for ref, and used tagger epoch
as epoch only for tag pointing to object of other type. If ref in
refs/tags was commit, we used committer epoch as epoch for ref (see
parse_ref; we sorted in gitweb by 'epoch' field).
Currently we use committer epoch for refs pointing to commit objects,
and tagger epoch for refs pointing to tag object, even if tag points
to commit. Going back to old behavior needs additional changes to
git-for-each-ref sorting (sort by given field and use other if first
is not available, --sort=<key>|<key>).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Pasky, you asked for faster "summary" and "tags" view. Simple ab benchmark
before and after this patch for my git.git repository (git/jnareb-git.git)
with some heads and tags added as compared to git.git repository, shows
around 2.4-3.0 times speedup for "summary" and "tags" views:
summary 3134 +/- 24.2 ms --> 1081 +/- 30.2 ms
tags 2886 +/- 18.9 ms --> 1196 +/- 15.6 ms
gitweb/gitweb.perl | 153 +++++++++++++++++++++++++++++++---------------------
1 files changed, 92 insertions(+), 61 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bf5f829..7710cc2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1294,47 +1294,88 @@ sub parse_ls_tree_line ($;%) {
## ......................................................................
## parse to array of hashes functions
-sub git_get_refs_list {
- my $type = shift || "";
- my %refs;
- my @reflist;
-
- my @refs;
- open my $fd, "-|", $GIT, "peek-remote", "$projectroot/$project/"
+sub git_get_heads_list {
+ my $limit = shift;
+ my @headslist;
+
+ open my $fd, '-|', git_cmd(), 'for-each-ref',
+ ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
+ '--format=%(objectname) %(refname) %(subject)%00%(committer)',
+ 'refs/heads'
or return;
while (my $line = <$fd>) {
- chomp $line;
- if ($line =~ m/^([0-9a-fA-F]{40})\trefs\/($type\/?([^\^]+))(\^\{\})?$/) {
- if (defined $refs{$1}) {
- push @{$refs{$1}}, $2;
- } else {
- $refs{$1} = [ $2 ];
- }
+ my %ref_item;
- if (! $4) { # unpeeled, direct reference
- push @refs, { hash => $1, name => $3 }; # without type
- } elsif ($3 eq $refs[-1]{'name'}) {
- # most likely a tag is followed by its peeled
- # (deref) one, and when that happens we know the
- # previous one was of type 'tag'.
- $refs[-1]{'type'} = "tag";
- }
+ chomp $line;
+ my ($refinfo, $committerinfo) = split(/\0/, $line);
+ my ($hash, $name, $title) = split(' ', $refinfo, 3);
+ my ($committer, $epoch, $tz) =
+ ($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
+ $name =~ s!^refs/heads/!!;
+
+ $ref_item{'name'} = $name;
+ $ref_item{'id'} = $hash;
+ $ref_item{'title'} = $title || '(no commit message)';
+ $ref_item{'epoch'} = $epoch;
+ if ($epoch) {
+ $ref_item{'age'} = age_string(time - $ref_item{'epoch'});
+ } else {
+ $ref_item{'age'} = "unknown";
}
+
+ push @headslist, \%ref_item;
}
close $fd;
- foreach my $ref (@refs) {
- my $ref_file = $ref->{'name'};
- my $ref_id = $ref->{'hash'};
+ return wantarray ? @headslist : \@headslist;
+}
+
+sub git_get_tags_list {
+ my $limit = shift;
+ my @tagslist;
- my $type = $ref->{'type'} || git_get_type($ref_id) || next;
- my %ref_item = parse_ref($ref_file, $ref_id, $type);
+ open my $fd, '-|', git_cmd(), 'for-each-ref',
+ ($limit ? '--count='.($limit+1) : ()), '--sort=-creatordate',
+ '--format=%(objectname) %(objecttype) %(refname) '.
+ '%(*objectname) %(*objecttype) %(subject)%00%(creator)',
+ 'refs/tags'
+ or return;
+ while (my $line = <$fd>) {
+ my %ref_item;
- push @reflist, \%ref_item;
+ chomp $line;
+ my ($refinfo, $creatorinfo) = split(/\0/, $line);
+ my ($id, $type, $name, $refid, $reftype, $title) = split(' ', $refinfo, 6);
+ my ($creator, $epoch, $tz) =
+ ($creatorinfo =~ /^(.*) ([0-9]+) (.*)$/);
+ $name =~ s!^refs/tags/!!;
+
+ $ref_item{'type'} = $type;
+ $ref_item{'id'} = $id;
+ $ref_item{'name'} = $name;
+ if ($type eq "tag") {
+ $ref_item{'subject'} = $title;
+ $ref_item{'reftype'} = $reftype;
+ $ref_item{'refid'} = $refid;
+ } else {
+ $ref_item{'reftype'} = $type;
+ $ref_item{'refid'} = $id;
+ }
+
+ if ($type eq "tag" || $type eq "commit") {
+ $ref_item{'epoch'} = $epoch;
+ if ($epoch) {
+ $ref_item{'age'} = age_string(time - $ref_item{'epoch'});
+ } else {
+ $ref_item{'age'} = "unknown";
+ }
+ }
+
+ push @tagslist, \%ref_item;
}
- # sort refs by age
- @reflist = sort {$b->{'epoch'} <=> $a->{'epoch'}} @reflist;
- return (\@reflist, \%refs);
+ close $fd;
+
+ return wantarray ? @tagslist : \@tagslist;
}
## ----------------------------------------------------------------------
@@ -2264,8 +2305,7 @@ sub git_tags_body {
for (my $i = $from; $i <= $to; $i++) {
my $entry = $taglist->[$i];
my %tag = %$entry;
- my $comment_lines = $tag{'comment'};
- my $comment = shift @$comment_lines;
+ my $comment = $tag{'subject'};
my $comment_short;
if (defined $comment) {
$comment_short = chop_str($comment, 30, 5);
@@ -2298,7 +2338,7 @@ sub git_tags_body {
$cgi->a({-href => href(action=>$tag{'reftype'}, hash=>$tag{'refid'})}, $tag{'reftype'});
if ($tag{'reftype'} eq "commit") {
print " | " . $cgi->a({-href => href(action=>"shortlog", hash=>$tag{'name'})}, "shortlog") .
- " | " . $cgi->a({-href => href(action=>"log", hash=>$tag{'refid'})}, "log");
+ " | " . $cgi->a({-href => href(action=>"log", hash=>$tag{'name'})}, "log");
} elsif ($tag{'reftype'} eq "blob") {
print " | " . $cgi->a({-href => href(action=>"blob_plain", hash=>$tag{'refid'})}, "raw");
}
@@ -2323,23 +2363,23 @@ sub git_heads_body {
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my $entry = $headlist->[$i];
- my %tag = %$entry;
- my $curr = $tag{'id'} eq $head;
+ my %ref = %$entry;
+ my $curr = $ref{'id'} eq $head;
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- print "<td><i>$tag{'age'}</i></td>\n" .
- ($tag{'id'} eq $head ? "<td class=\"current_head\">" : "<td>") .
- $cgi->a({-href => href(action=>"shortlog", hash=>$tag{'name'}),
- -class => "list name"},esc_html($tag{'name'})) .
+ print "<td><i>$ref{'age'}</i></td>\n" .
+ ($curr ? "<td class=\"current_head\">" : "<td>") .
+ $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'name'}),
+ -class => "list name"},esc_html($ref{'name'})) .
"</td>\n" .
"<td class=\"link\">" .
- $cgi->a({-href => href(action=>"shortlog", hash=>$tag{'name'})}, "shortlog") . " | " .
- $cgi->a({-href => href(action=>"log", hash=>$tag{'name'})}, "log") . " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$tag{'name'}, hash_base=>$tag{'name'})}, "tree") .
+ $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'name'})}, "shortlog") . " | " .
+ $cgi->a({-href => href(action=>"log", hash=>$ref{'name'})}, "log") . " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$ref{'name'}, hash_base=>$ref{'name'})}, "tree") .
"</td>\n" .
"</tr>";
}
@@ -2489,18 +2529,9 @@ sub git_summary {
my $owner = git_get_project_owner($project);
- my ($reflist, $refs) = git_get_refs_list();
-
- my @taglist;
- my @headlist;
- foreach my $ref (@$reflist) {
- if ($ref->{'name'} =~ s!^heads/!!) {
- push @headlist, $ref;
- } else {
- $ref->{'name'} =~ s!^tags/!!;
- push @taglist, $ref;
- }
- }
+ my $refs = git_get_references();
+ my @taglist = git_get_tags_list(15);
+ my @headlist = git_get_heads_list(15);
git_header_html();
git_print_page_nav('summary','', $head);
@@ -2792,9 +2823,9 @@ sub git_tags {
git_print_page_nav('','', $head,undef,$head);
git_print_header_div('summary', $project);
- my ($taglist) = git_get_refs_list("tags");
- if (@$taglist) {
- git_tags_body($taglist);
+ my @tagslist = git_get_tags_list();
+ if (@tagslist) {
+ git_tags_body(\@tagslist);
}
git_footer_html();
}
@@ -2805,9 +2836,9 @@ sub git_heads {
git_print_page_nav('','', $head,undef,$head);
git_print_header_div('summary', $project);
- my ($headlist) = git_get_refs_list("heads");
- if (@$headlist) {
- git_heads_body($headlist, $head);
+ my @headslist = git_get_heads_list();
+ if (@headslist) {
+ git_heads_body(\@headslist, $head);
}
git_footer_html();
}
--
1.4.3.3
^ permalink raw reply related
* Re: Suggestion: drop 'g' in git-describe suffix
From: Nicolas Vilz 'niv' @ 2006-11-02 19:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611021559430.1670@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 Nov 2006, Nicolas Vilz 'niv' wrote:
>
>>> Use the complete output of describe:
>>> $ git show v1.4.3.3-g1e1f76e
>> this one doesn't work for me in my repository.
>
> You need at least v1.4.3-rc1^0~69 (v1.4.2.1-g7dd45e1) for this. You
> indicated in your email that your version is older.
strange, from time to time i have to delete the whole git repository,
not to get stuck on old revisions. Now with a fresh repository i get a
current revision and with this version, it works.
Thx for help
^ permalink raw reply
* Re: [PATCH 6/6] remove .keep pack lock files when done with refs update
From: Nicolas Pitre @ 2006-11-02 17:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611020959410.11384@xanadu.home>
On Thu, 2 Nov 2006, Nicolas Pitre wrote:
> Another area of that patch I'm not really sure of is this:
>
> @@ -408,6 +415,7 @@ fetch_main () {
> append_fetch_head "$sha1" "$remote" \
> "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
> done
> + if [ "$pack_lockfile" ]; then rm -f "$pack_lockfile"; fi
> ) || exit ;;
> esac
>
> How can I make sure to not clobber a non-zero return code with the rm
> that would prevent the exit while still performing the rm in all cases?
OK looking at it again I think the || exit is only meant to match the
exit 1 before that point. Since this is a subshell then the exit 1
wouldn't exit it all on its own. Otherwise there is no errors expected
to trickle out of the while loop and I _think_ the above is correct.
Do you still want a new patch for the micronit quoting issue?
^ permalink raw reply
* git and branches newie questions
From: Doug Reiland @ 2006-11-02 17:02 UTC (permalink / raw)
To: git
I need some suggestions for the best way to setup my repositories.
I have a linux repository cloned right from Linus.
I want to create 2 additional branches in this repository:
internal_current and internal_testing
I want to use internal_current to make modifications to the main Linux
branch for an internal project.
I want other users to clone/pull/push changes to the internal_current branch.
I want to use internal_testing as a branch to merge and test the
latest Linux branch with changes made to internal_current. Once this
testing is complete, merge the changes into internal_current.
That is the best way to do this. I am open to use cogito. I have
messed up this merging process just about each time, and I want to get
a stable process before I open this up to other users.
Also, I can't figure out permissions. I have setup the allow_users
hook in .git/hooks/update. My repository is "owned" by gate_keeper. My
user login is dreiland. I push changes back to the gate_keeper
repository and stuff under .git gets owned by me. Now, I log as a
gate_keeper to get a Linus update or perform the internal_testing
merges and things fail because it is owned by dreiland.
^ permalink raw reply
* Re: how to pass ssh options to git?
From: Linus Torvalds @ 2006-11-02 16:10 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Dennis Stosberg, Matthieu Moy, git
In-Reply-To: <20061102112720.GA8469@mellanox.co.il>
On Thu, 2 Nov 2006, Michael S. Tsirkin wrote:
> Quoting r. Dennis Stosberg <dennis@stosberg.net>:
> > Subject: Re: how to pass ssh options to git?
> >
> > Michael S. Tsirkin wrote:
> >
> > > I know, problem is I want to use different options at different times.
> > > I could use -F configfile ssh option, but how to pass *that* to git?
> >
> > You can set the path of the ssh executable to use with the GIT_SSH
> > environment variable. Create a shell script like
> >
> > #!/bin/sh
> > exec ssh --your-options-- $*
> >
> > and make GIT_SSH point to it.
>
> Thanks, I'll try that.
It's really better to use a ".ssh/config" file instead.
I realize that you want to use different options "dynamically", but what
you can do is to just have different "fake hostnames". For example, you
can do
Host private.host.com
User myname
Hostname host.com
IdentityFile /home/myname/.ssh/private-identity
Host public.host.com
User groupname
Hostname host.com
IdentityFile /home/myname/.ssh/public-identity
and now you can ssh to "host.com" using different identities by just using
"private.host.com" and "public.host.com" respectively. You can do pretty
much any options that way.
Very convenient, if you have just a couple of "standard" setups.
Obviously we _could_ just add support for arbitrary ssh options, but it
gets pretty ugly pretty quickly, so I'd suggest trying to use the
.ssh/config approach with different hostnames if that is at all possible.
^ permalink raw reply
* [PATCH] Add --global option to git-repo-config.
From: Sean @ 2006-11-02 15:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611021550060.1670@wbgn013.biozentrum.uni-wuerzburg.de>
Allow user to set variables in global ~/.gitconfig file
using command line.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
Documentation/git-repo-config.txt | 31 ++++++++++++++++++-------------
builtin-repo-config.c | 13 +++++++++++--
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 8a1ab61..8199615 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -3,19 +3,19 @@ git-repo-config(1)
NAME
----
-git-repo-config - Get and set options in .git/config
+git-repo-config - Get and set repository or global options.
SYNOPSIS
--------
[verse]
-'git-repo-config' [type] name [value [value_regex]]
-'git-repo-config' [type] --replace-all name [value [value_regex]]
-'git-repo-config' [type] --get name [value_regex]
-'git-repo-config' [type] --get-all name [value_regex]
-'git-repo-config' [type] --unset name [value_regex]
-'git-repo-config' [type] --unset-all name [value_regex]
-'git-repo-config' -l | --list
+'git-repo-config' [--global] [type] name [value [value_regex]]
+'git-repo-config' [--global] [type] --replace-all name [value [value_regex]]
+'git-repo-config' [--global] [type] --get name [value_regex]
+'git-repo-config' [--global] [type] --get-all name [value_regex]
+'git-repo-config' [--global] [type] --unset name [value_regex]
+'git-repo-config' [--global] [type] --unset-all name [value_regex]
+'git-repo-config' [--global] -l | --list
DESCRIPTION
-----------
@@ -41,8 +41,9 @@ This command will fail if:
. Can not write to .git/config,
. no section was provided,
. the section or key is invalid,
-. you try to unset an option which does not exist, or
-. you try to unset/set an option for which multiple lines match.
+. you try to unset an option which does not exist,
+. you try to unset/set an option for which multiple lines match, or
+. you use --global option without $HOME being properly set.
OPTIONS
@@ -64,14 +65,17 @@ OPTIONS
--get-regexp::
Like --get-all, but interprets the name as a regular expression.
+--global::
+ Use global ~/.gitconfig file rather than the repository .git/config.
+
--unset::
- Remove the line matching the key from .git/config.
+ Remove the line matching the key from config file.
--unset-all::
- Remove all matching lines from .git/config.
+ Remove all matching lines from config file.
-l, --list::
- List all variables set in .git/config.
+ List all variables set in config file.
ENVIRONMENT
@@ -79,6 +83,7 @@ ENVIRONMENT
GIT_CONFIG::
Take the configuration from the given file instead of .git/config.
+ Using the "--global" option forces this to ~/.gitconfig.
GIT_CONFIG_LOCAL::
Currently the same as $GIT_CONFIG; when Git will support global
diff --git a/builtin-repo-config.c b/builtin-repo-config.c
index f60cee1..7b6e572 100644
--- a/builtin-repo-config.c
+++ b/builtin-repo-config.c
@@ -3,7 +3,7 @@
#include <regex.h>
static const char git_config_set_usage[] =
-"git-repo-config [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --unset | --unset-all] name [value [value_regex]] | --list";
+"git-repo-config [ --global ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --unset | --unset-all] name [value [value_regex]] | --list";
static char *key;
static regex_t *key_regexp;
@@ -139,7 +139,16 @@ int cmd_repo_config(int argc, const char
type = T_BOOL;
else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
return git_config(show_all_config);
- else
+ else if (!strcmp(argv[1], "--global")) {
+ char *home = getenv("HOME");
+ if (home) {
+ char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
+ setenv("GIT_CONFIG", user_config, 1);
+ free(user_config);
+ } else {
+ die("$HOME not set");
+ }
+ } else
break;
argc--;
argv++;
--
1.4.3.3.g869c
^ permalink raw reply related
* Re: [PATCH 6/6] remove .keep pack lock files when done with refs update
From: Nicolas Pitre @ 2006-11-02 15:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmbav2n9.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > --- a/git-fetch.sh
> > +++ b/git-fetch.sh
> > @@ -51,7 +51,7 @@ do
> > verbose=Yes
> > ;;
> > -k|--k|--ke|--kee|--keep)
> > - keep=--keep
> > + keep=-k -k
> > ;;
> > --reflog-action=*)
> > rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
>
> Micronit. This cannot be right without quoting.
OK. Shell programming isn't really my turf.
Another area of that patch I'm not really sure of is this:
@@ -408,6 +415,7 @@ fetch_main () {
append_fetch_head "$sha1" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done
+ if [ "$pack_lockfile" ]; then rm -f "$pack_lockfile"; fi
) || exit ;;
esac
How can I make sure to not clobber a non-zero return code with the rm
that would prevent the exit while still performing the rm in all cases?
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Johannes Schindelin @ 2006-11-02 15:01 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <454A0538.9000104@iaglans.de>
Hi,
On Thu, 2 Nov 2006, Nicolas Vilz 'niv' wrote:
> > Use the complete output of describe:
> > $ git show v1.4.3.3-g1e1f76e
>
> this one doesn't work for me in my repository.
You need at least v1.4.3-rc1^0~69 (v1.4.2.1-g7dd45e1) for this. You
indicated in your email that your version is older.
Ciao,
Dscho
^ permalink raw reply
* Re: Minor documentation problems [RFC PATCH]
From: Johannes Schindelin @ 2006-11-02 14:51 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP042F05A3C71EDC671552FFAEFF0@CEZ.ICE>
Hi,
On Thu, 2 Nov 2006, Sean wrote:
> - else
> + else if (!strcmp(argv[1], "--global")) {
> + char *home = getenv("HOME");
> + if (home) {
> + char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
> + setenv("GIT_CONFIG", user_config, 1);
> + free(user_config);
> + } else {
> + return -1;
Micronit: might be useful to tell the user that she's homeless.
Else: ACK.
Ciao,
Dscho
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Nicolas Vilz 'niv' @ 2006-11-02 14:48 UTC (permalink / raw)
To: git
In-Reply-To: <8aa486160611020312v42047716t6a13e6fa16eeae8@mail.gmail.com>
Santi Béjar wrote:
> On 11/2/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>> Andy Whitcroft escreveu:
>> > Han-Wen Nienhuys wrote:
>> >>
>> >> tag+sha1
>> >>
>> >> to separate the tag and the committish.
>> >
>> > Well there is a non-alphabet character in there, a minus (-). The g
>> > prefix on the sha1 _fragment_ it to indicate that it is in fact a
>> > truncated sha1, not a complete one.
>
> I think it is there to indicate it is a git commit sha1.
>
>>
>> is this policy documented somewhere? None of the tools understand it.
>>
>> [lilydev@haring git]$ git describe
>> v1.4.3.3-g1e1f76e
>> [lilydev@haring git]$ git show g1e1f76e
>> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in
>> the working tree.
>> Use '--' to separate paths from revisions
>>
>
> Use the complete output of describe:
> $ git show v1.4.3.3-g1e1f76e
this one doesn't work for me in my repository.
$ git-describe
release_1_22_v0.7-g85eb121
$ git show release_1_22_v0.7-g85eb121
fatal: ambiguous argument 'release_1_22_v0.7-g85eb121': unknown revision
or path not in the working tree.
Use '--' to separate paths from revisions
> or the abbrev sha1:
> $ git show 1e1f76e
this one works with my repository
$ git show 85eb121
i use git version 1.4.2.rc2.g2686c
(that was next branch of git one or two days ago or so..)
it would be great to let the full output of git describe work as well.
Sincerly
^ permalink raw reply
* Re: Minor documentation problems [RFC PATCH]
From: Sean @ 2006-11-02 14:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611021448100.1670@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 2 Nov 2006 14:54:24 +0100 (CET)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Your patch would be loads shorter and easier to read if you'd just
> override the GIT_CONFIG environment variable (like --git-dir sets
> GIT_DIR).
>
Indeed. Thanks... How 'bout this:
diff --git a/builtin-repo-config.c b/builtin-repo-config.c
index f60cee1..dcdae81 100644
--- a/builtin-repo-config.c
+++ b/builtin-repo-config.c
@@ -139,7 +139,16 @@ int cmd_repo_config(int argc, const char
type = T_BOOL;
else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
return git_config(show_all_config);
- else
+ else if (!strcmp(argv[1], "--global")) {
+ char *home = getenv("HOME");
+ if (home) {
+ char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
+ setenv("GIT_CONFIG", user_config, 1);
+ free(user_config);
+ } else {
+ return -1;
+ }
+ } else
break;
argc--;
argv++;
^ permalink raw reply related
* Re: Suggestion: drop 'g' in git-describe suffix
From: Jakub Narebski @ 2006-11-02 14:07 UTC (permalink / raw)
To: git
In-Reply-To: <4549D519.4080104@xs4all.nl>
Han-Wen Nienhuys wrote:
> Santi Béjar escreveu:
>> One problem I see with this scheme (either 'g', 'git' of '+') is that
>> it does not provide an increasing version number, even for
>> fast-forwarding commits. Then it is not useful as a package version
>> number (deb or rpm). I've already seen deb packages with
>> version+git20061010. One possibility could be to add the number of
>> commits between the tag and the commit as:
>>
>> v1.4.3.3-git12g1e1f76e
>>
>> to provide a weak ordering for fast-forwarding commits. What do you thing?
>
> Is that number well defined if you merge branches in between?
>
> I'd prefer
>
> v1.4.3.3+git-12-1e1f76e
>
> or similar. Pasting together words without separator is bad for readability.
Or even IMVHO better:
v1.4.3.3+12--1e1f76e
or something like that. v1.4.3.3+12 part meaning that v1.4.3.3 is 12 ancestor
in direct shortest direct line, or that v1.4.3.3+12 is 12 generations away
from v1.4.3.3.
Of course that is _costly_ to confitm that, and v1.4.3.3+12 might mean more
than one revision in presence of branching points, especially that there is
no equivalent of "first parent" to distinguish like in case of v1.4.3.3~12
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Minor documentation problems [RFC PATCH]
From: Johannes Schindelin @ 2006-11-02 13:54 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP018DA61B5F35F9603DF8A8AEFF0@CEZ.ICE>
Hi,
On Thu, 2 Nov 2006, Sean wrote:
> The patch below always updates ~/.gitconfig but perhaps it
> should respect GIT_CONFIG and/or GIT_CONFIG_LOCAL
> environment variables.
Your patch would be loads shorter and easier to read if you'd just
override the GIT_CONFIG environment variable (like --git-dir sets
GIT_DIR).
Ciao,
Dscho
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Andy Whitcroft @ 2006-11-02 13:52 UTC (permalink / raw)
To: Santi Béjar; +Cc: hanwen, git
In-Reply-To: <8aa486160611020439r255bcdb1q6e7ece46c77de11c@mail.gmail.com>
Santi Béjar wrote:
> On 11/2/06, Andy Whitcroft <apw@shadowen.org> wrote:
>> Santi Béjar wrote:
>> > One problem I see with this scheme (either 'g', 'git' of '+') is that
>> > it does not provide an increasing version number, even for
>> > fast-forwarding commits. Then it is not useful as a package version
>> > number (deb or rpm). I've already seen deb packages with
>> > version+git20061010. One possibility could be to add the number of
>> > commits between the tag and the commit as:
>> >
>> > v1.4.3.3-git12g1e1f76e
>> >
>> > to provide a weak ordering for fast-forwarding commits. What do you
>> thing?
>>
>> I think you'll restart the 1.2.3.4 versioning is better 'debate' again!
>
> Sorry, I don't undestand this.
There was a long running debate between sha1's and version 'numbers'
1.2.3.4 for each revision.
>
>> Surly if things are being pushed into a .deb or .rpm we should be using
>> a real release version. We should be tagging that. If the project is
>> not providing release number, there is nothing stopping you from tagging
>> them yourself in your copy of the repository and using your tag. you
>> could use like 'unofficial-N' where N increments in the way you want.
>
> And where do you store this tag? It is an upstream commit and you just
> refer to this. With the unofficial-N there is no way to know which
> upstream commit you are refering without having access to the git
> repository of the packager .
Yes that is completly true, but its normally the packer who is doing the
bug fixing of the .deb when its broken. The key problem is you need
your numbering to be stable. The only guarenteed stable thing is the
sha1, tags can change. IMHO you should be including the full sha1 in
the --version output and the package descript, whatever versioning you
are using on the .deb itself.
That said I guess it would be pretty easy to come up with something to
count the number of commits since the last valid tag, something like
that below. Might not be pretty, nor so easy to turn back into a commit
of course.
-apw
#!/bin/sh
let n=0
git log --pretty=one "$@" | \
awk '{print $1}' | \
git name-rev --tags --stdin | \
{
while read sha1 name
do
if [ "$name" != "" ]; then
echo "$sha1 $name $n"
exit 0
fi
let "n=n+1"
done
echo "- unknown 0"
exit 1
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Carl Worth @ 2006-11-02 13:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andy Whitcroft, hanwen, git
In-Reply-To: <20061102110331.GJ20017@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
On Thu, 2 Nov 2006 12:03:31 +0100, Petr Baudis wrote:
>
> Dear diary, on Thu, Nov 02, 2006 at 11:37:31AM CET, I got a letter
> where Andy Whitcroft <apw@shadowen.org> said that...
> > The g prefix on the sha1 _fragment_ it to indicate that it is in fact
> > a truncated sha1, not a complete one.
>
> I think it's rather to indicate that it is a sha1 at all.
Frankly, I've never understood the 'g' prefix at all. I don't use
git-describe much, but some people have sent me things with this 'g'
on the front and every time I've received that I was annoyed to find
the commit identifier they sent didn't work until I manually removed
it.
It's definitely never provided any useful semantic information to me.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* "cg-init arg" silently ignores its argument
From: Matthieu Moy @ 2006-11-02 13:38 UTC (permalink / raw)
To: git
Hi,
It seems that
$ cg-init foo
does the same as
$ cg-init
At best, I'd expect it to do something like
$ mkdir -p foo; cd foo; cg-init
(probably it should disable autocommiting then). That's what bzr does,
and I find it handy to try something on a temporary toy repository.
and at least, if it doesn't, it should complain about invalid
argument.
Thanks,
--
^ permalink raw reply
* Re: Minor documentation problems [RFC PATCH]
From: Matthieu Moy @ 2006-11-02 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP018DA61B5F35F9603DF8A8AEFF0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> This is the git version :
>
> $ git repo-config user.email "myself@myisp.com"
> $ git repo-config user.name "me"
Great!
But this should be mentionned in
http://www.kernel.org/pub/software/scm/git/docs/git-commit-tree.html
too.
Perhaps, "As an alternative to editing the .git/config or ~/.gitconfig
manually, you can use git-repo-config".
BTW,
http://www.kernel.org/pub/software/scm/git/docs/git-commit-tree.html
also fails to mention ~/.gitconfig.
--
^ permalink raw reply
* Re: Minor documentation problems
From: Matthieu Moy @ 2006-11-02 13:20 UTC (permalink / raw)
To: git
In-Reply-To: <20061102114149.GL20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Moreover, I'm more and more thinking about removing the fallback on
> guessing based on /etc/passwd and hostname. _Many_ people were and will
> be burnt by it, and I think it's more sane to require the user to
> confirm once what the valid credentials are (at _that_ point it's ok to
> guess, but the user has to confirm it) than let them unconsciously do
> 200 commits with completely bogus author lines.
IIRC, Darcs will prompt interactively the first time and remember it.
The problem of interactive prompt is that it can break scripts (which
are not always ran from an interactive prompt), so it's probably OK to
do this in cogito, but less so in git.
One nice thing with guess-and-don't-ask is that people who don't care
don't have to bother about this. I mean, some people have been
satisfied with CVS storing the username of the guy doing the access
which is often wrong for years, so ... it's probably OK to use an
incorrect guess for a private project with, say, <5 contributors.
--
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Salikh Zakirov @ 2006-11-02 12:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqnq51v4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> In other words, I do not have a good explanation on what "git
> reset [--hard|--mixed] <commit> <path>..." does that I can write
> in the documentation.
In my humble opinion, git-reset is somewhat overloaded in functionality,
and it takes time to explain its function to git newbies.
Why not split it into two commands, e.g.
git-rewind for manipulations with HEAD
git-reset for manipulations with index and working copy only
?
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Santi Béjar @ 2006-11-02 12:44 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <4549D519.4080104@xs4all.nl>
On 11/2/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> Santi Béjar escreveu:
> > One problem I see with this scheme (either 'g', 'git' of '+') is that
> > it does not provide an increasing version number, even for
> > fast-forwarding commits. Then it is not useful as a package version
> > number (deb or rpm). I've already seen deb packages with
> > version+git20061010. One possibility could be to add the number of
> > commits between the tag and the commit as:
> >
> > v1.4.3.3-git12g1e1f76e
> >
> > to provide a weak ordering for fast-forwarding commits. What do you thing?
>
> Is that number well defined if you merge branches in between?
Yes.
$ git-rev-list 1e1f76e ^v1.4.3.3 | wc -l
>
> I'd prefer
>
> v1.4.3.3+git-12-1e1f76e
>
> or similar. Pasting together words without separator is bad for readability.
>
> --
> Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Minor documentation problems [RFC PATCH]
From: Sean @ 2006-11-02 12:39 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqmz7a1694.fsf@ecrins.imag.fr>
On Thu, 02 Nov 2006 11:40:23 +0100
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> * http://www.kernel.org/pub/software/scm/cogito/docs/cg-commit.1.html
> Mentions .git/config, but not ~/.gitconfig (which is indeed _the_
> place where I think most people want to set their name and email).
>
> Side note: it can be interesting to have a command to do this.
> For example, bzr has "bzr whoami 'me <myself@myisp.com>'", which
> avoids having to learn the config file syntax.
This is the git version :
$ git repo-config user.email "myself@myisp.com"
$ git repo-config user.name "me"
Unfortunately repo-config doesn't update ~/.gitconfig only
the .git/config file.
The patch below adds a --global option to allow:
$ git repo-config --global user.email "myself@myisp.com"
$ git repo-config --global user.name "me"
Although the syntax is a bit depressing, it would seem to
be the path of least resistance.
The patch below always updates ~/.gitconfig but perhaps it
should respect GIT_CONFIG and/or GIT_CONFIG_LOCAL
environment variables.
Sean
diff --git a/builtin-repo-config.c b/builtin-repo-config.c
index f60cee1..8c2b58a 100644
--- a/builtin-repo-config.c
+++ b/builtin-repo-config.c
@@ -127,9 +127,20 @@ free_strings:
return ret;
}
+static int set_config(int global, const char* key, const char* value,
+ const char* value_regex, int multi_replace)
+{
+ if (global)
+ return git_global_config_set_multivar(key, value,
+ value_regex, multi_replace);
+ else
+ return git_config_set_multivar(key, value,
+ value_regex, multi_replace);
+}
+
int cmd_repo_config(int argc, const char **argv, const char *prefix)
{
- int nongit = 0;
+ int nongit = 0, global = 0;
setup_git_directory_gently(&nongit);
while (1 < argc) {
@@ -139,6 +150,8 @@ int cmd_repo_config(int argc, const char
type = T_BOOL;
else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
return git_config(show_all_config);
+ else if (!strcmp(argv[1], "--global"))
+ global = 1;
else
break;
argc--;
@@ -150,9 +163,9 @@ int cmd_repo_config(int argc, const char
return get_value(argv[1], NULL);
case 3:
if (!strcmp(argv[1], "--unset"))
- return git_config_set(argv[2], NULL);
+ return set_config(global, argv[2], NULL, NULL, 0);
else if (!strcmp(argv[1], "--unset-all"))
- return git_config_set_multivar(argv[2], NULL, NULL, 1);
+ return set_config(global, argv[2], NULL, NULL, 1);
else if (!strcmp(argv[1], "--get"))
return get_value(argv[2], NULL);
else if (!strcmp(argv[1], "--get-all")) {
@@ -165,12 +178,12 @@ int cmd_repo_config(int argc, const char
return get_value(argv[2], NULL);
} else
- return git_config_set(argv[1], argv[2]);
+ return set_config(global, argv[1], argv[2], NULL, 0);
case 4:
if (!strcmp(argv[1], "--unset"))
- return git_config_set_multivar(argv[2], NULL, argv[3], 0);
+ return set_config(global, argv[2], NULL, argv[3], 0);
else if (!strcmp(argv[1], "--unset-all"))
- return git_config_set_multivar(argv[2], NULL, argv[3], 1);
+ return set_config(global, argv[2], NULL, argv[3], 1);
else if (!strcmp(argv[1], "--get"))
return get_value(argv[2], argv[3]);
else if (!strcmp(argv[1], "--get-all")) {
@@ -183,13 +196,13 @@ int cmd_repo_config(int argc, const char
return get_value(argv[2], argv[3]);
} else if (!strcmp(argv[1], "--replace-all"))
- return git_config_set_multivar(argv[2], argv[3], NULL, 1);
+ return set_config(global, argv[2], argv[3], NULL, 1);
else
- return git_config_set_multivar(argv[1], argv[2], argv[3], 0);
+ return set_config(global, argv[1], argv[2], argv[3], 0);
case 5:
if (!strcmp(argv[1], "--replace-all"))
- return git_config_set_multivar(argv[2], argv[3], argv[4], 1);
+ return set_config(global, argv[2], argv[3], argv[4], 1);
case 1:
default:
usage(git_config_set_usage);
diff --git a/cache.h b/cache.h
index d0a1657..5f7c599 100644
--- a/cache.h
+++ b/cache.h
@@ -402,6 +402,8 @@ extern int git_config_int(const char *,
extern int git_config_bool(const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
+extern int git_global_config_set(const char*, const char*);
+extern int git_global_config_set_multivar(const char*, const char*, const char*, int);
extern int check_repository_format_version(const char *var, const char *value);
#define MAX_GITNAME (1000)
diff --git a/config.c b/config.c
index e8f0caf..0393b65 100644
--- a/config.c
+++ b/config.c
@@ -529,22 +529,16 @@ int git_config_set(const char* key, cons
* - the config file is removed and the lock file rename()d to it.
*
*/
-int git_config_set_multivar(const char* key, const char* value,
+int git_config_file_set_multivar(char* config_filename,
+ const char* key, const char* value,
const char* value_regex, int multi_replace)
{
int i, dot;
int fd = -1, in_fd;
int ret;
- char* config_filename;
char* lock_file;
const char* last_dot = strrchr(key, '.');
- config_filename = getenv("GIT_CONFIG");
- if (!config_filename) {
- config_filename = getenv("GIT_CONFIG_LOCAL");
- if (!config_filename)
- config_filename = git_path("config");
- }
config_filename = xstrdup(config_filename);
lock_file = xstrdup(mkpath("%s.lock", config_filename));
@@ -742,3 +736,36 @@ out_free:
}
+int git_config_set_multivar(const char* key, const char* value,
+ const char* value_regex, int multi_replace)
+{
+ char* config_filename;
+ config_filename = getenv("GIT_CONFIG");
+ if (!config_filename) {
+ config_filename = getenv("GIT_CONFIG_LOCAL");
+ if (!config_filename)
+ config_filename = git_path("config");
+ }
+ return git_config_file_set_multivar(config_filename, key, value,
+ value_regex, multi_replace);
+}
+
+int git_global_config_set_multivar(const char* key, const char* value,
+ const char* value_regex, int multi_replace)
+{
+ int ret = -1;
+ const char *home = getenv("HOME");
+ if (home) {
+ char * global = xstrdup(mkpath("%s/.gitconfig", home));
+ ret = git_config_file_set_multivar(global, key, value,
+ value_regex, multi_replace);
+ free(global);
+ }
+ return ret;
+}
+
+int git_global_config_set(const char* key, const char* value)
+{
+ return git_global_config_set_multivar(key, value, NULL, 0);
+}
^ permalink raw reply related
* Re: Suggestion: drop 'g' in git-describe suffix
From: Santi Béjar @ 2006-11-02 12:39 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: hanwen, git
In-Reply-To: <4549D4B4.4030601@shadowen.org>
On 11/2/06, Andy Whitcroft <apw@shadowen.org> wrote:
> Santi Béjar wrote:
> > One problem I see with this scheme (either 'g', 'git' of '+') is that
> > it does not provide an increasing version number, even for
> > fast-forwarding commits. Then it is not useful as a package version
> > number (deb or rpm). I've already seen deb packages with
> > version+git20061010. One possibility could be to add the number of
> > commits between the tag and the commit as:
> >
> > v1.4.3.3-git12g1e1f76e
> >
> > to provide a weak ordering for fast-forwarding commits. What do you thing?
>
> I think you'll restart the 1.2.3.4 versioning is better 'debate' again!
Sorry, I don't undestand this.
> Surly if things are being pushed into a .deb or .rpm we should be using
> a real release version. We should be tagging that. If the project is
> not providing release number, there is nothing stopping you from tagging
> them yourself in your copy of the repository and using your tag. you
> could use like 'unofficial-N' where N increments in the way you want.
And where do you store this tag? It is an upstream commit and you just
refer to this. With the unofficial-N there is no way to know which
upstream commit you are refering without having access to the git
repository of the packager .
^ permalink raw reply
* Re: git and "dumb protocols"
From: Petr Baudis @ 2006-11-02 12:21 UTC (permalink / raw)
To: git
In-Reply-To: <vpq4ptixdfj.fsf@ecrins.imag.fr>
Dear diary, on Thu, Nov 02, 2006 at 01:04:16PM CET, I got a letter
where Matthieu Moy <Matthieu.Moy@imag.fr> said that...
> Petr Baudis <pasky@suse.cz> writes:
> > I think a patch that would add support for pushing over sftp or some
> > other dumb protocol would be welcome. One problem is with proper locking
> > of ref updates (not sure how well would sftp cope with that), another is
> > that you will need to do git-update-server-info's job on the server
> > side.
>
> It should be possible (but not implemented AAUI) also to generate the
> additional info of git-update-server-info on the client, isn't it?
Yes, that's what git-http-push does.
--
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
^ permalink raw reply
* Re: git and "dumb protocols"
From: Jakub Narebski @ 2006-11-02 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <vpq4ptixdfj.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> I'll probably do, but my concern is broader than that. I like the
> ability to use almost any webhosting service for my revision control.
> GNU Arch was quite good at that, bzr is also (doesn't support webdav
> very well yet, but read-only-HTTP, sftp and ftp are there), so I'd
> like git to do the same.
Well, git can fetch (read) via http, https, ftp, sftp, rsync, git, ssh+git;
it can push via http(s) with WebDAV, and ssh+git (ssh+git meaning via ssh,
with git installed on the server side).
BTW. rsync is considered obsolete, and suitable only for initial cloning,
perhaps.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git and "dumb protocols"
From: Matthieu Moy @ 2006-11-02 12:04 UTC (permalink / raw)
To: git
In-Reply-To: <20061102104848.GH20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> yes, you can push using HTTP DAV - just push to an HTTP URL; make sure
> you have git-http-push compiled, it is sometimes not compiled because it
> unfortunately adds dependencies on couple of more libraries.
That's great. I don't need this right now, but having worked behind a
firewall + proxy, I know how appreciable it is to push with DAV ;-).
> I think a patch that would add support for pushing over sftp or some
> other dumb protocol would be welcome. One problem is with proper locking
> of ref updates (not sure how well would sftp cope with that), another is
> that you will need to do git-update-server-info's job on the server
> side.
It should be possible (but not implemented AAUI) also to generate the
additional info of git-update-server-info on the client, isn't it?
> If you already have SSH access to the server, why not compile Git
> there and install it to your $HOME, though?
I'll probably do, but my concern is broader than that. I like the
ability to use almost any webhosting service for my revision control.
GNU Arch was quite good at that, bzr is also (doesn't support webdav
very well yet, but read-only-HTTP, sftp and ftp are there), so I'd
like git to do the same.
And yes, there are tons of reasons not to install git on the server.
In particular, the fact that I'm not root there, and too lazy to do
more than "aptitude install git" with pleasure ;-).
--
^ 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