* [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
* [PATCH 1/2] for-each-ref: "creator" and "creatordate" fields
From: Jakub Narebski @ 2006-11-02 19:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslh86uz9.fsf@assigned-by-dhcp.cox.net>
From fa1a32c9a7c8a31b122df7d07f4a8885cbe120d0 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sat, 28 Oct 2006 13:33:46 -0700
Subject: [PATCH 1/2] for-each-ref: "creator" and "creatordate" fields
This adds "creator" (which is parallel to "tagger" or "committer")
and "creatordate" (corresponds to "taggerdate" and
"committerdate").
As other "date" fields, "creatordate" sorts numerically
and displays human readably. This allows for example for
sorting together heavyweigth and lightweight tags.
[jn: originally fields were named "epoch" and "epochdate".]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Jakub Narebski <jnareb@gmail.com>
---
builtin-for-each-ref.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 93d3d7e..173bf38 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -59,6 +59,8 @@ static struct {
{ "taggername" },
{ "taggeremail" },
{ "taggerdate", FIELD_TIME },
+ { "creator" },
+ { "creatordate", FIELD_TIME },
{ "subject" },
{ "body" },
{ "contents" },
@@ -401,6 +403,29 @@ static void grab_person(const char *who,
else if (!strcmp(name + wholen, "date"))
grab_date(wholine, v);
}
+
+ /* For a tag or a commit object, if "creator" or "creatordate" is
+ * requested, do something special.
+ */
+ if (strcmp(who, "tagger") && strcmp(who, "committer"))
+ return; /* "author" for commit object is not wanted */
+ if (!wholine)
+ wholine = find_wholine(who, wholen, buf, sz);
+ if (!wholine)
+ return;
+ for (i = 0; i < used_atom_cnt; i++) {
+ const char *name = used_atom[i];
+ struct atom_value *v = &val[i];
+ if (!!deref != (*name == '*'))
+ continue;
+ if (deref)
+ name++;
+
+ if (!strcmp(name, "creatordate"))
+ grab_date(wholine, v);
+ else if (!strcmp(name, "creator"))
+ v->s = copy_line(wholine);
+ }
}
static void find_subpos(const char *buf, unsigned long sz, const char **sub, const char **body)
--
1.4.3.3
^ permalink raw reply related
* Re: how to pass ssh options to git?
From: Shawn Pearce @ 2006-11-02 20:22 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611020801160.25218@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> 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
I often setup not only multiple fake hostnames in my .ssh/config
but I also setup multiple remote files under any given repository's
.git/remotes directory, using one file per fake hostname.
That way I can pick which options to apply at the time of git push
or git fetch by just changing the name passed to it.
$ ls .git/remotes
private public
$ cat .git/remotes/private
URL: private.host.com:/path/to/repo
Pull: refs/heads/master:refs/heads/origin
$ cat .git/remotes/public
URL: public.host.com:/path/to/repo
Pull: refs/heads/master:refs/heads/origin
$ git push private
$ git fetch public
I often need this to traverse around firewalls and whatnot.
It works pretty well, assuming I can remember where I'm currently
connected to. :-)
--
^ permalink raw reply
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Martin Langhoff @ 2006-11-02 23:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, git
In-Reply-To: <20060924172838.GZ13132@pasky.or.cz>
On 9/25/06, Petr Baudis <pasky@suse.cz> wrote:
> > >But I can adjust such details when applying your patch.
> >
> > Great! -- I'm travelling and at an airport "free access" computer. It
> > should be illegal to run airports without free wifi in this day and
> > age.
>
> Heartily agreed.
Paski, did this one get dropped? Change of heart? Heart attack?
cheers,
^ permalink raw reply
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Petr Baudis @ 2006-11-03 0:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff, git
In-Reply-To: <46a038f90611021540s14b6098p477a68ef00c826e9@mail.gmail.com>
Dear diary, on Fri, Nov 03, 2006 at 12:40:38AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 9/25/06, Petr Baudis <pasky@suse.cz> wrote:
> >> >But I can adjust such details when applying your patch.
> >>
> >> Great! -- I'm travelling and at an airport "free access" computer. It
> >> should be illegal to run airports without free wifi in this day and
> >> age.
> >
> >Heartily agreed.
>
> Paski, did this one get dropped? Change of heart? Heart attack?
Hmm, I thought we've agreed to go for the cg-resolve solution
instead...?
--
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
* multiple branches or multiple repositories
From: Han-Wen Nienhuys @ 2006-11-03 1:51 UTC (permalink / raw)
To: git
We're in the process of converting the LilyPond CVS repository at
savannah.gnu.org to GIT. One of the questions we need to deal with, is
how handle modules.
There seem to be two approaches:
- for each module, create a separate git repository. Inside the
repository, each subproject has its own branching
- put each module as a separate branch in a shared repository.
I think the first option is the most natural one, but are there any
issues, besides namespace pollution to the second option?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: multiple branches or multiple repositories
From: Junio C Hamano @ 2006-11-03 2:38 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <eie7ae$ib6$1@sea.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> We're in the process of converting the LilyPond CVS repository at
> savannah.gnu.org to GIT. One of the questions we need to deal with,
> is how handle modules.
>
> There seem to be two approaches:
>
> - for each module, create a separate git repository. Inside the
> repository, each subproject has its own branching
>
> - put each module as a separate branch in a shared repository.
>
> I think the first option is the most natural one, but are there any
> issues, besides namespace pollution to the second option?
As the layout for a distribution point, the second one may be
easier to handle (one place to remotely sync with), but in all
other aspects the first option should be easier to deal with
day-to-day.
^ permalink raw reply
* Re: [PATCH] Added description for reversing git-update-index using --index-info
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611021113.01812.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> +One particular use of --index-info is to reverse the effect of
> +"git-update-index frotz":
> +
> +------------
> +git ls-tree HEAD frotz | git update-index --index-info
> +------------
> +
> +This makes the index hold the file frotz from HEAD rather than from the
> +working copy.
Up to this point is good, but I am unhappy about the next example.
> +------------
> +git ls-tree -r HEAD | git update-index --index-info
> +------------
> +
> +Will undo everything except "git add" from the index, as
> +"git-ls-tree -r" lists everything in the last commit.
While this is correct in the mechanical sense, it _sucks_ as an
example, especially since you do not mention that the user would
most likely need to do 'git update-index --refresh' afterwards
to make the result useful.
^ permalink raw reply
* Re: [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611021111.22604.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Adds support for display_mode == 2; which shows all non-tag refs.
That is a change in behaviour and given that we introduced
remotes for the explicit purpose of not to clutter the local
branch namespace, I doubt defaulting to _show_ remotes is a good
change. See the 'bitfield' comment in my other reply.
^ permalink raw reply
* Re: git bug? + question
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Miles Bader; +Cc: git, Karl Hasselström
In-Reply-To: <buoejsme6ho.fsf@dhapc248.dev.necel.com>
Miles Bader <miles.bader@necel.com> writes:
> Also, a question: Is there anyway to make git-clone use
> --use-separate-remote by default? I'm trying for a "lots of branches in
> a single shared remote repository" style, and use-separate-remote seems
> more sane for this usage.
This was suggested last week on the list, and I think it is a
sensible thing to do.
Karl Hasselström <kha@treskal.com> writes:
> On 2006-10-26 10:11:50 -0700, Linus Torvalds wrote:
>
>> But it's a good rule in general, just because it makes a certain
>> common workflow explicit. In fact, we really probably should start
>> to always use the "refs/remote/origin/HEAD" kind of syntax by
>> default, where you can't even _switch_ to the branch maintained in
>> the remote repository, because it's not a real branch locally.
>
> Seconded. I really like having remote branches in their own namespace
> where I can't confuse them with my local branches by mistake -- and
> that the branches of different remotes end up in different separate
> namespaces.
>
>> So normally you should consider the "origin" branch to be a pointer
>> to WHAT YOU FETCHED LAST - and that implies that you shouldn't
>> commit to it, because then it loses that meaning (now it's "what you
>> fetched last and then committed your own work on top of", which is
>> something totally different).
>
> Defaulting to --use-separate-remotes would mean not having to explain
> this to every single confused new user. :-)
The only downside that I can think of is that it affects me or
anybody who works on more than one machine on multiple branches
slightly negatively.
I know I keep "master" checked out on my secondary machines when
I am done working there, so the mapping origin:master,
maint:maint, next:next, and +pu:pu I get by default has been
easy for me to work on. With the current layout, updating and
building four variants can be done with:
git pull
for b in master maint next pu
do
git checkout $b && make || break
done
which is efficient (guaranteed to do only one fetch from remote)
and convenient. Also I have Push: mapping set up on my
main machine to do master:origin, next:next, maint:maint, and
+pu:pu so that I can replace the first "git pull" on the
secondary machine with "git push secondary" on my main machine.
With separate remotes, I'd need something like:
for b in master maint next pu
do
git checkout $b && git pull && make || break
done
And I also would need to have per-branch configuration to merge
from ". remotes/origin/$b" without re-fetching while on a
non-master branch $b, for the above to work. I still need to
remember to process "master" first, so all things considered,
this is a regression in usability for my workflow.
But that is probably a minor inconvenience to a minority. Most
of the world follow others' repositories that have a single
primary head, and defaulting to use separate-remote would help
them a lot.
So I am in favor of the change, but this is not something we can
do in a flag-day fashion. We would probably need updating the
tutorial and the documentation first.
^ permalink raw reply
* Re: [PATCH 4/4] Show the branch type after the branch name for remotes
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611021111.32759.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Instead of prefixing the remote branches with "remotes/" suffix them with
> "[read only]"
This is a change in UI and while I understand why you want to
say r/o instead of remotes/, I think this needs a bit more
thought and discussion. People should not be feeding the output
of "git branch" Porcelainish to their scripts, but you'll never
know...
By the way, does "git branch -r" (without any of your patches)
even say "remotes/"?
^ permalink raw reply
* Re: [PATCH 1/2] for-each-ref: "creator" and "creatordate" fields
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611022017.31351.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> From fa1a32c9a7c8a31b122df7d07f4a8885cbe120d0 Mon Sep 17 00:00:00 2001
> From: Junio C Hamano <junkio@cox.net>
> Date: Sat, 28 Oct 2006 13:33:46 -0700
> Subject: [PATCH 1/2] for-each-ref: "creator" and "creatordate" fields
>
> This adds "creator" (which is parallel to "tagger" or "committer")
> and "creatordate" (corresponds to "taggerdate" and
> "committerdate").
The first line should not be in the message. I agree that it is
sensible not to call this "epoch", and "creator" is fine by me.
Thanks. Will apply.
^ permalink raw reply
* Re: [PATCH] Improve git-prune -n output
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611021112.26420.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> prune_object() in show_only mode would previously just show the path to the
> object that would be deleted. The path the object is stored in shouldn't be
> shown to users, they only know about sha1 identifiers so show that instead.
>
> Further, the sha1 alone isn't that useful for examining what is going to be
> deleted. This patch also adds the object type to the output, which makes it
> easy to pick out, say, the commits and use git-show to display them.
>
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
List members and git users,
if you are using "prune -n" output in your scripts, this
change could cause those scripts to break; so please holler.
I am inclined to take this output format change, so if you are
going to holler please do so fast.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Use git-for-each-ref to generate list of heads and/or tags
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611022023.12246.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> 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
The first line should not be in the body of the message.
> 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).
I think that behaviour was inconsistent and just silly. Using
creatordate consistently is better so if the code generates what
the commit log claims to, I think that is fine (I haven't looked
at it deeply yet).
Thanks. Will apply.
^ permalink raw reply
* Re: Problem with git-push
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611021018040.1670@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> What I proposed does not break that. It only means that you only try to
> adjust the permissions if the mkdir succeeded. If somebody else created
> the directory in the mean time, it is not our job to adjust the
> permissions.
> So I think that my patch is correct, but does not matter very much.
Ok. I misread the patch. Will apply with a one-liner log.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/4] Rename remote_only to display_mode
From: Junio C Hamano @ 2006-11-03 2:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611021111.09434.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> -static void print_ref_list(int remote_only)
> +static void print_ref_list(int display_mode)
> {
> int i;
> char c;
>
> - if (remote_only)
> + if (display_mode)
> for_each_remote_ref(append_ref, NULL);
> else
> for_each_branch_ref(append_ref, NULL);
If you make this a "mode", it probably is better to make 1 and 0
into symbolic constants. This patch taken alone is regression
in readability.
By the way, it might make sense to make it bitfields; that would
allow you to show either one kind or both.
Something like this untested patch, that is...
diff --git a/builtin-branch.c b/builtin-branch.c
index 368b68e..182648c 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -79,45 +79,73 @@ static void delete_branches(int argc, co
}
}
+#define REF_LOCAL_BRANCH 01
+#define REF_REMOTE_BRANCH 02
+
static int ref_index, ref_alloc;
-static char **ref_list;
+static struct ref_list {
+ int kind;
+ char name[FLEX_ARRAY];
+} **ref_list;
-static int append_ref(const char *refname, const unsigned char *sha1, int flags,
- void *cb_data)
+static int append_ref(const char *refname, const unsigned char *sha1,
+ int flags, void *cb_data)
{
+ int kinds = *((int*)cb_data);
+ int this_kind, strip;
+ struct ref_list *elem;
+
+ if (!strncmp(refname, "refs/heads/", 11)) {
+ this_kind = REF_LOCAL_BRANCH;
+ strip = 11;
+ }
+ else if (!strncmp(refname, "refs/remotes/", 13)) {
+ this_kind = REF_REMOTE_BRANCH;
+ strip = 13;
+ }
+ else
+ this_kind = 0;
+
+ if ((this_kind & kinds) == 0)
+ return 0;
+
if (ref_index >= ref_alloc) {
ref_alloc = alloc_nr(ref_alloc);
ref_list = xrealloc(ref_list, ref_alloc * sizeof(char *));
}
-
- ref_list[ref_index++] = xstrdup(refname);
+
+ elem = xcalloc(1, sizeof(*elem) + strlen(refname) - strip);
+ strcpy(elem->name, refname + strip);
+ elem->kind = this_kind;
+ ref_list[ref_index++] = elem;
return 0;
}
-static int ref_cmp(const void *r1, const void *r2)
+static int ref_cmp(const void *r1_, const void *r2_)
{
- return strcmp(*(char **)r1, *(char **)r2);
+ const struct ref_list *r1 = *((const struct ref_list **)r1_);
+ const struct ref_list *r2 = *((const struct ref_list **)r2_);
+
+ if (r1->kind != r2->kind)
+ return r1->kind - r2->kind;
+ return strcmp(r1->name, r2->name);
}
-static void print_ref_list(int remote_only)
+static void print_ref_list(int kinds)
{
int i;
char c;
- if (remote_only)
- for_each_remote_ref(append_ref, NULL);
- else
- for_each_branch_ref(append_ref, NULL);
-
+ for_each_ref(append_ref, &kinds);
qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
for (i = 0; i < ref_index; i++) {
c = ' ';
- if (!strcmp(ref_list[i], head))
+ if (ref_list[i]->kind == REF_LOCAL_BRANCH &&
+ !strcmp(ref_list[i]->name, head))
c = '*';
-
- printf("%c %s\n", c, ref_list[i]);
+ printf("%c %s\n", c, ref_list[i]->name);
}
}
@@ -160,8 +188,9 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, remote_only = 0;
+ int delete = 0, force_delete = 0, force_create = 0;
int reflog = 0;
+ int kinds = REF_LOCAL_BRANCH;
int i;
git_config(git_default_config);
@@ -189,7 +218,11 @@ int cmd_branch(int argc, const char **ar
continue;
}
if (!strcmp(arg, "-r")) {
- remote_only = 1;
+ kinds = REF_REMOTE_BRANCH;
+ continue;
+ }
+ if (!strcmp(arg, "-a")) {
+ kinds = REF_REMOTE_BRANCH | REF_LOCAL_BRANCH;
continue;
}
if (!strcmp(arg, "-l")) {
@@ -209,7 +242,7 @@ int cmd_branch(int argc, const char **ar
if (delete)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
- print_ref_list(remote_only);
+ print_ref_list(kinds);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
^ permalink raw reply related
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Martin Langhoff @ 2006-11-03 2:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, git
In-Reply-To: <20061103001135.GN20017@pasky.or.cz>
On 11/3/06, Petr Baudis <pasky@suse.cz> wrote:
> > Paski, did this one get dropped? Change of heart? Heart attack?
>
> Hmm, I thought we've agreed to go for the cg-resolve solution
> instead...?
Oops. That wasn't my reading. Misunderstood. In any case, if you go
back a bit in the conversation, the usage model I find this useful is
one where it makes sense to try different tools that have entirely
different parameters. That is why it makes sense to call them
differently.
So cg-meld [meld params] , is different from cg-xxdiff [xxdiff params]
and cg-wiggle [wiggle params] makes more sense to me and can be
maintained by different people (those who like meld probably dont' use
xxdiff ;-)
And from a packaging perspective, cg-resolve will depend on a zillion things.
cheers,
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Use git-for-each-ref to generate list of heads and/or tags
From: Jakub Narebski @ 2006-11-03 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcxhl0bh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> 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).
>
> I think that behaviour was inconsistent and just silly. Using
> creatordate consistently is better so if the code generates what
> the commit log claims to, I think that is fine (I haven't looked
> at it deeply yet).
Well, I _could_ argue on the former behaviour, namely that we use
committerdate when available (when ref points to commit, or to tag
pointing to commit), and if it is not available we use taggerdate
if possible.
The latter is that we use always "creation" date.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 1/2] for-each-ref: "creator" and "creatordate" fields
From: Jakub Narebski @ 2006-11-03 3:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz79l0bi.fsf@assigned-by-dhcp.cox.net>
Dnia piątek 3. listopada 2006 03:40, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> From fa1a32c9a7c8a31b122df7d07f4a8885cbe120d0 Mon Sep 17 00:00:00 2001
>> From: Junio C Hamano <junkio@cox.net>
>> Date: Sat, 28 Oct 2006 13:33:46 -0700
>> Subject: [PATCH 1/2] for-each-ref: "creator" and "creatordate" fields
>>
>> This adds "creator" (which is parallel to "tagger" or "committer")
>> and "creatordate" (corresponds to "taggerdate" and
>> "committerdate").
>
> The first line should not be in the message.
I'm sorry. I just tried to send patch without changing authorship
(from yours).
--
Jakub Narebski
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Matthew Hannigan @ 2006-11-03 3:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git, Shawn Pearce
In-Reply-To: <9e4733910610201115g1790b5am55105bf0c662a0da@mail.gmail.com>
On Fri, Oct 20, 2006 at 02:15:15PM -0400, Jon Smirl wrote:
> [ ... ]
> You could have a file of macro substitutions that is applied/expanded
> when files go in/out of git. The macros would replace the copyright
> notices improving the move/rename tracking and the reducing repository
> size. The macros could be recorded out of band to eliminate the need
> for escaping the file contents. Even simpler, the only valid place for
> the macro could be the beginning of the file.
That probably belongs in the class of transformations
best done outside the VCS such as the permissions
and system config file idea Linus outlined earlier.
Matt
^ permalink raw reply
* Re: git bug? + question
From: Sean @ 2006-11-03 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, git, Karl Hasselström
In-Reply-To: <7v4pthmew1.fsf@assigned-by-dhcp.cox.net>
On Thu, 02 Nov 2006 18:40:30 -0800
Junio C Hamano <junkio@cox.net> wrote:
> which is efficient (guaranteed to do only one fetch from remote)
> and convenient. Also I have Push: mapping set up on my
> main machine to do master:origin, next:next, maint:maint, and
> +pu:pu so that I can replace the first "git pull" on the
> secondary machine with "git push secondary" on my main machine.
One thing that would make separate-remotes nicer to work with
is to have an automatic mapping between any local branch and
one of the same name in remotes.
So for instance, if you have a local branch named pu checked
out and you pull from origin, remotes/origin/pu would be merged
after the fetch unless a manual mapping was defined in the
remotes or config file.
Maybe even going as far as automatically creating a local branch
for each remote branch on clone is worth considering.
On a peripherally related topic, someone on the xorg list was
complaining that after the initial clone, there is no easy way
to track branches that get added/deleted from the remote repo.
It would be nice if pull had an option to automatically add
and remove remote branches from the remotes/<remote>/xxx
namespace.
^ permalink raw reply
* [PATCH] gitweb: Remove extra "/" in path names for git_get_project_list
From: Aneesh Kumar K.V @ 2006-11-03 5:11 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitweb-Remove-extra-in-path-names-for-git_get_project_list.txt --]
[-- Type: text/plain, Size: 745 bytes --]
Without this change we get a wrong $pfxlen value and the check_export_ok()
checks with with a wrong directory name. Without this patch the below
$projects_list fails with gitweb
$projects_list = "/tmp/a/b/";
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7710cc2..a0a9aaf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -897,6 +897,8 @@ sub git_get_projects_list {
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
+ # remove the trailing "/"
+ $dir =~ s!/+$!!;
my $pfxlen = length("$dir");
File::Find::find({
--
1.4.3.3.gc954-dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: Remove extra "/" in path names for git_get_project_list
From: Junio C Hamano @ 2006-11-03 5:59 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <454ACF91.50601@gmail.com>
"Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:
> Without this change we get a wrong $pfxlen value and the check_export_ok()
> checks with with a wrong directory name. Without this patch the below
> $projects_list fails with gitweb
>
> $projects_list = "/tmp/a/b/";
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Hmph. Doesn't this break $projects_list = "/", I wonder?
> + # remove the trailing "/"
> + $dir =~ s!/+$!!;
^ permalink raw reply
* Re: [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same name as path
From: Junio C Hamano @ 2006-11-03 6:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611020949.34276.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I'll be pushing out a "master" update
>> sometime today, and do not expect to be able to get to your "n
>> turned out to be ten" series, so it might be worthwhile to
>> reroll the remaining bits that you still care about on top of
>> what I push out tonight to make sure we are on the same page.
>
> I'll wait a while if there are any comments (for example on formatting
> used), and resend cleaned-up series.
> ...
> I've send series early to get some comments, but I see while I got
> some comments on "take 1" and "take 2" on _single_ "new commitdiff"
> RFC patch, I got comments only about half-baked '&iquot;' idea.
Well, I think some of the major reasons you did not get any
response were:
(1) it was unclear where it started, where it was heading to,
and where it ended until you sent out "by the way n=10"
message at the end;
(2) the first major oand interesting one in the series (5/n)
were linewrapped and could not be applied;
and it is rather hard to comment on gitweb changes unless you
view two instances of gitweb output side-by-side for before and
after each patch.
I'd see if I can add some constructive comments on patches 5-10
tonight, but I'm in the middle of other things so don't hold
your breath ;-).
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Martin Langhoff @ 2006-11-03 6:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, Jan Hudec, Jeff King, bazaar-ng, git
In-Reply-To: <200610212121.58245.jnareb@gmail.com>
On 10/22/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Lack of --follow is not a big issue because you can do this "by hand";
> you can use git-diff-tree -M at the end of file history to check if
> [git considers] it was moved from somewhere.
This 'by hand' can be done in shell. cg-log has a half-complete
implementation of it. Seems to be disabled now :-(
cheers,
^ 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