Re: gerrit with linux kernel
945 views
Skip to first unread message
Magnus Bäck
May 9, 2013, 11:12:23 AM5/9/13
to repo-d...@googlegroups.com
On Monday, May 06, 2013 at 14:40 EDT,
christop...@gmail.com wrote:
> I work on the linux kernel with some other people. Sometimes we write
> and review patches amongst ourselves, and then those patches get sent
> to the main kernel mailing list. Once those patches are merged, I pull
> the kernel's master branch back into our local repo. The annoying part
> is that patches that were merged by upstream still show up as being
> open on our end. How does Gerrit fit into a project that it doesn't
> own? None of us actually have the power to merge into master, but it
> seems like Gerrit requires the project ower to do just that. I've
> tried rebaseing patch sets with with the rebase button, but patches
> that were merged don't disappear as with a normal git rebase.
Correct, the rebase of a patch set onto a new base in which the
patch is included won't cause it to disappear. However, the resulting
patch should become empty.
I don't think there's a better way of dealing with this except
abandoning the change (and preferably referring to the SHA-1 of
the accepted upstream patch).
--
Magnus Bäck
ba...@google.com
christop...@gmail.com wrote:
> I work on the linux kernel with some other people. Sometimes we write
> and review patches amongst ourselves, and then those patches get sent
> to the main kernel mailing list. Once those patches are merged, I pull
> the kernel's master branch back into our local repo. The annoying part
> is that patches that were merged by upstream still show up as being
> open on our end. How does Gerrit fit into a project that it doesn't
> own? None of us actually have the power to merge into master, but it
> seems like Gerrit requires the project ower to do just that. I've
> tried rebaseing patch sets with with the rebase button, but patches
> that were merged don't disappear as with a normal git rebase.
Correct, the rebase of a patch set onto a new base in which the
patch is included won't cause it to disappear. However, the resulting
patch should become empty.
I don't think there's a better way of dealing with this except
abandoning the change (and preferably referring to the SHA-1 of
the accepted upstream patch).
--
Magnus Bäck
ba...@google.com
Joshua J. Kugler
Jun 7, 2013, 7:39:07 PM6/7/13
to repo-d...@googlegroups.com, christop...@gmail.com
On Monday, May 06, 2013 11:40:34 christop...@gmail.com wrote:
> I work on the linux kernel with some other people. Sometimes we write and
> review patches amongst ourselves, and then those patches get sent to the
> main kernel mailing list. Once those patches are merged, I pull the
> kernel's master branch back into our local repo.
So, we're going to start doing this, so I thought I'd pick up where this left
> I work on the linux kernel with some other people. Sometimes we write and
> review patches amongst ourselves, and then those patches get sent to the
> main kernel mailing list. Once those patches are merged, I pull the
> kernel's master branch back into our local repo.
off.
What method do you use for keeping the gerrit "copy" in sync with the upstream
tree? A cron job that runs 'git pull' in the local checkout? Pull it down to
another location and push to the local copy? Other?
Others have suggestions? I assume changing the git repo "under" gerrit won't
bother gerrit any, as it doesn't index/store anything in the DB except pending
changes.
Thanks!
j
--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: peda...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
Alex Blewitt
Jun 7, 2013, 7:55:34 PM6/7/13
to Joshua J. Kugler, repo-d...@googlegroups.com, christop...@gmail.com
On 8 Jun 2013, at 00:39, "Joshua J. Kugler" <jos...@azariah.com> wrote:
> On Monday, May 06, 2013 11:40:34 christop...@gmail.com wrote:
>> I work on the linux kernel with some other people. Sometimes we write and
>> review patches amongst ourselves, and then those patches get sent to the
>> main kernel mailing list. Once those patches are merged, I pull the
>> kernel's master branch back into our local repo.
>
> So, we're going to start doing this, so I thought I'd pick up where this left
> off.
>
> What method do you use for keeping the gerrit "copy" in sync with the upstream
> tree? A cron job that runs 'git pull' in the local checkout? Pull it down to
> another location and push to the local copy? Other?
>
> Others have suggestions? I assume changing the git repo "under" gerrit won't
> bother gerrit any, as it doesn't index/store anything in the DB except pending
> changes.
>
> Thanks!
So you should be able to set something up that has write access to the same Git repositories as on the server. If you are doing this kind of mirroring you will have to have a convention for what branches are owned by the remote mirror and what are local; ie is "master" something that you sync with the remote or something you are working on?
> On Monday, May 06, 2013 11:40:34 christop...@gmail.com wrote:
>> I work on the linux kernel with some other people. Sometimes we write and
>> review patches amongst ourselves, and then those patches get sent to the
>> main kernel mailing list. Once those patches are merged, I pull the
>> kernel's master branch back into our local repo.
>
> So, we're going to start doing this, so I thought I'd pick up where this left
> off.
>
> What method do you use for keeping the gerrit "copy" in sync with the upstream
> tree? A cron job that runs 'git pull' in the local checkout? Pull it down to
> another location and push to the local copy? Other?
>
> Others have suggestions? I assume changing the git repo "under" gerrit won't
> bother gerrit any, as it doesn't index/store anything in the DB except pending
> changes.
>
> Thanks!
>
One way is to use hierarchical ref names (eg refs/mirror/master vs refs/heads/master) which is basically what remote does on your local checkout.
That way your mirroring script can just do a force pull and override existing refs without merging. You can then merge your branches as appropriate.
When you next do an operation to list refs it will realise the branches have moved on and will pick up where it left off.
One thing to watch out for; if you push a merge node for review which depends on changes that have been inserted like this, you may inadvertently trigger review creation for everything on both sides of the merge node. I'm not sure if this happened in an error on my part but for such forks one needs to be careful and try out the process in a test instance first to ensure you don't accidentally end up reviewing the last decade of kernel development ...
Alex
Magnus Bäck
Jun 11, 2013, 8:46:35 AM6/11/13
to repo-d...@googlegroups.com
On Friday, June 07, 2013 at 19:55 EDT,
Alex Blewitt <alex.b...@gmail.com> wrote:
[...]
> One thing to watch out for; if you push a merge node for review which
> depends on changes that have been inserted like this, you may
> inadvertently trigger review creation for everything on both sides of
> the merge node. I'm not sure if this happened in an error on my part
> but for such forks one needs to be careful and try out the process in
> a test instance first to ensure you don't accidentally end up
> reviewing the last decade of kernel development ...
Just make sure all upstream commits are pushed straight to Gerrit first
(i.e. pushed to refs/heads/foo) as part of the mirroring process. When
pushing to refs/heads/foo Gerrit creates changes for all commits it
hasn't seen before. After that you won't have any problems merging from
an upstream-originating commit and pushing the resulting merge commit
for review.
--
Magnus Bäck
ba...@google.com
Alex Blewitt <alex.b...@gmail.com> wrote:
[...]
> One thing to watch out for; if you push a merge node for review which
> depends on changes that have been inserted like this, you may
> inadvertently trigger review creation for everything on both sides of
> the merge node. I'm not sure if this happened in an error on my part
> but for such forks one needs to be careful and try out the process in
> a test instance first to ensure you don't accidentally end up
> reviewing the last decade of kernel development ...
(i.e. pushed to refs/heads/foo) as part of the mirroring process. When
pushing to refs/heads/foo Gerrit creates changes for all commits it
hasn't seen before. After that you won't have any problems merging from
an upstream-originating commit and pushing the resulting merge commit
for review.
--
Magnus Bäck
ba...@google.com
Ian Kumlien
Jun 11, 2013, 8:58:27 AM6/11/13
to Repo and Gerrit Discussion
This is what i use, in the bare gits config file:
# mirror the linux kernel
[remote "kernel.org"]
fetch = +refs/heads/*:refs/heads/community/kernel.org/*
fetch = +refs/tags/*:refs/tags/*
---
this will create all branches under refs/heads/community/kernel.org/ as you see above, you might want to change that or not.
Then i have a cron job that does:
#!/bin/bash
BASE=$HOME/review_site/
GC=$BASE/etc/gerrit.config
TOP=$(git config --file "$GC" --get gerrit.basepath)
GERRIT_PORT=29418
# space separated list
PROJECTS=(path/to/kernel.git)
for proj in ${PROJECTS[@]}
do
git --git-dir=${TOP}${proj} fetch --all -q
done
---
You could add "git gc --quiet" if you want to keep it clean - this is not my exact script as you might understand ;)
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Ian Kumlien
Jun 11, 2013, 10:13:37 AM6/11/13
to Repo and Gerrit Discussion
Just for reference, you might want to keep multiple kernel trees in one git, i do this at home to track Linus and stable:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "stable"]
fetch = +refs/heads/*:refs/remotes/stable/*
---
This would mean that you can fork of at any point, keep rebasing at any branch/tag when needed.
This would mean that you can fork of at any point, keep rebasing at any branch/tag when needed.
Reply all
Reply to author
Forward
0 new messages