question about gitweb for android
allstars
about the
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=shortlog
in some commits, there's a pink button in the end of the log summary
i.e.
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=commit;h=a27353c1965911f69be8d02a01b15389189eab9d
the pink button says "changes/38/15738/3"
what does this mean?
can i get this number in git log or gitk???
thanks
allstars
and seems only handled by gitweb
On Aug 3, 6:23 pm, allstars <allstars....@gmail.com> wrote:
> hi
> about thehttp://android.git.kernel.org/?p=platform/frameworks/base.git;a=shortlog
> in some commits, there's a pink button in the end of the log summary
>
Magnus Bäck
allstars <allsta...@gmail.com> wrote:
> about the
> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=shortlog
>
> in some commits, there's a pink button in the end of the log summary
>
> i.e.
> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=commit;h=a27353c1965911f69be8d02a01b15389189eab9d
>
> the pink button says "changes/38/15738/3"
>
> what does this mean?
That should mean that commit is patch set 3 of change 15738. What
puzzles me is that AOSP change 15738[*] is actually a change in
kernel/experimental.
> can i get this number in git log or gitk???
The refs/change namespace is not downloaded by default, but can be
downloaded like this:
git fetch origin refs/changes/*:refs/changes/*
(Or should they be fetched into refs/remotes/origin/changes/* instead?)
Once in your local repository they'll show up in git log and gitk like
any other branches. If you always want those refs downloaded I suppose
you can adjust the remote.origin.fetch configuration variable to not
only fetch refs/heads from the origin but also refs/changes/*.
[*] https://review.source.android.com/15783
--
Magnus B�ck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
Shawn Pearce
>
> That should mean that commit is patch set 3 of change 15738. What
> puzzles me is that AOSP change 15738[*] is actually a change in
> kernel/experimental.
>
Nope. Its framework/base. You typo'd the number and looked up 83 not 38. :-)
Dmitry Fink
1. When working in cherry-pick mode, not all the commits on the final
master tree have these buttons, I assume only the ones that were
simple FF have it, other changes that waited long enough to be
submitted and were forced to be cherry-picked (and changed their SHA1
in the process) loose the button. Is that correct? Does it make sense
to shift ref/changes/xxx to the final SHA1 once the commit is
submitted?
2. How difficult is it to hack gitweb to make this button link back to
the change in gerrit? It will be really nice to browse the gitweb
history and jump to gerrit to see the background and the history of
every individual commit.
Thanks
Dmitry
On Aug 3, 7:02 am, Shawn Pearce <s...@google.com> wrote:
Shawn Pearce
> Two additional question regarding these buttons:
>
> 1. When working in cherry-pick mode, not all the commits on the final
> master tree have these buttons, I assume only the ones that were
> simple FF have it, other changes that waited long enough to be
> submitted and were forced to be cherry-picked (and changed their SHA1
> in the process) loose the button. Is that correct?
I believe so, yes.
> Does it make sense
> to shift ref/changes/xxx to the final SHA1 once the commit is
> submitted?
I actually wanted to do this in cherry-pick mode. But I couldn't call
the code needed from the cherry-pick code path. I don't want to
actually replace /1 with the new SHA-1, I want to add a /2 patch set
that shows the final form that was cherry-picked. Thus every
cherry-picked change would have two patch sets, the original commit
that was uploaded, and the final version that was generated by the
server, making it look similar to the user cherry-picking it
themselves, uploading a replacement, and submitting a fast-forward.
Unfortunately the code to handle creation of a new patch set is buried
inside of this massive class called ReceiveCommits, which is
essentially the server side of git push for Gerrit Code Review. And
this class isn't invokable from within the MergeOp class that handles
the cherry-pick during submit activity. So I sort of shot myself in
the foot here by not having the replacement patch set code factored
out by itself. Extracting it is a non-trivial project, so it keeps
getting put off.
So I agree with you, and would love to do it. But I think its a
multi-day project for me.
> 2. How difficult is it to hack gitweb to make this button link back to
> the change in gerrit? It will be really nice to browse the gitweb
> history and jump to gerrit to see the background and the history of
> every individual commit.
I'm not sure a lot of hacking is required. Modern gitweb supports
adding your own links to the pages. If you put this in your
gitweb.conf, you may get what you want. The /review/ bit below needs
to be the URL of your Gerrit Code Review server.
if ($cgi->param('a') =~ /^(commit|commitdiff)$/) {
my $h = $cgi->param('h');
my $r = "/review/#q,$h,n,z";
push @{$feature{'actions'}{'default'}}, ('review',$r,'commitdiff');
} elsif ($cgi->param('a') =~ /^(tree|blob)$/) {
my $h = $cgi->param('hb');
my $r = "/review/#q,$h,n,z";
push @{$feature{'actions'}{'default'}}, ('review',$r,'commitdiff');
}
If you let Gerrit run your gitweb.cgi for you, it automatically sets
this up in the CGI's configuration file.