With the submission of [1], any change that is submitted to one of the
Gerrit core plugins[2] will trigger a superproject subscription. That
results in a change to Gerrit updating the submodule pointer to the
last state of the plugin.
Changes like [3] are no longer necessary. In fact the submodules are
kept up to date automatically now, so we get a commit in Gerrit even
if the submodule is just getting refactored.
Thanks,
Stefan
[1] https://gerrit-review.googlesource.com/#/q/topic:gerrit-submodules
[2] commit-message-length-validator cookbook-plugin
download-commands hooks replication reviewnotes singleusergroup
[3] https://gerrit-review.googlesource.com/#/c/80083/
https://gerrit-review.googlesource.com/#/c/77609/
--
--
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/d/optout.
On Thu, Jul 28, 2016 at 12:11 AM, 'Stefan Beller' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:With the submission of [1], any change that is submitted to one of the
Gerrit core plugins[2] will trigger a superproject subscription. That
results in a change to Gerrit updating the submodule pointer to the
last state of the plugin.Hey, that's really great!! :-)There is still one use-case where we want to update the submodule pointer in Gerrit manually.This is when we make a non-compatible change in Gerrit that requires the core plugins to be updated.
On Thu, Jul 28, 2016 at 2:58 AM, Edwin Kempin <eke...@google.com> wrote:On Thu, Jul 28, 2016 at 12:11 AM, 'Stefan Beller' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:With the submission of [1], any change that is submitted to one of the
Gerrit core plugins[2] will trigger a superproject subscription. That
results in a change to Gerrit updating the submodule pointer to the
last state of the plugin.Hey, that's really great!! :-)There is still one use-case where we want to update the submodule pointer in Gerrit manually.This is when we make a non-compatible change in Gerrit that requires the core plugins to be updated.This change doesn't preclude doing that, the superproject update step should just detect that it's a no-op in that case.Although I'm not sure I agree with you here that we have to update the submodule link manually in this case. What would be wrong with just changing the code, linking the two changes together by topic, and letting Gerrit update the submodule link when you click "submit whole topic"?
There is still one use-case where we want to update the submodule pointer in Gerrit manually.This is when we make a non-compatible change in Gerrit that requires the core plugins to be updated.In this case the change in Gerrit which is incompatible for the plugins would also update the submodulepointers to plugin versions which were adapted to the incompatible change. The adapted plugin versionsare uploaded as changes as well and all changes are marked with the same topic so that they are submittedtogether. I guess in this case the superproject subscription would just find that there is nothing to do, right?
Am 28.07.2016 18:21 schrieb "'Stefan Beller' via Repo and Gerrit Discussion" <repo-d...@googlegroups.com>:
>
> Edwin wrote:
> > "That results in a change to Gerrit updating the submodule pointer to the last state of the plugin."
> > like it creates a change that still needs to be submitted. And in this case the submodules would be broken until somebody submits that change.
>
> Well that was unclear on my part, there is no change that needs to be
> submitted separately.
>
> Back then, we could only handle topics with no commit in the superproject,
> i.e. you submit in the submodule and Gerrit puts a commit in the superproject
> advancing the submodule pointer. (That worked across multiple submodules)
> That is where my phrasing came from.
>
> What's new (Thanks czhen!), is the ability of Gerrit to cope with a topic
> that also contains commits in the superproject as well as in the submodule.
>
> It's up to you if you want to do the submodule pointer update yourself
> or let Gerrit handle it.
Thanks for clarifying. If this works then I leave the update of the submodule pointer to Gerrit of course :-)
>
>
> On Thu, Jul 28, 2016 at 7:40 AM, Björn Pedersen <ice...@googlemail.com> wrote:
> > Hi,
> >>
> >>
> >> There is still one use-case where we want to update the submodule pointer
> >> in Gerrit manually.
> >> This is when we make a non-compatible change in Gerrit that requires the
> >> core plugins to be updated.
> >> In this case the change in Gerrit which is incompatible for the plugins
> >> would also update the submodule
> >> pointers to plugin versions which were adapted to the incompatible change.
> >> The adapted plugin versions
> >> are uploaded as changes as well and all changes are marked with the same
> >> topic so that they are submitted
> >> together. I guess in this case the superproject subscription would just
> >> find that there is nothing to do, right?
>
> Essentially it should "no-op".
> However when you use e.g. Merge-Always/Cherry-pick in the submodule,
> your manual update of the submodule pointer is wrong (as you don't know
> the sha1 yet) and Gerrit corrects it for you.
>
> >>
> >
> > I guess [1] should have solved this use-case.
> >
> > [1] https://gerrit-review.googlesource.com/#/c/79030/
>
Am 28.07.2016 18:21 schrieb "'Stefan Beller' via Repo and Gerrit Discussion" <repo-d...@googlegroups.com>:
> > "That results in a change to Gerrit updating the submodule pointer to the last state of the plugin."
>
> Edwin wrote:
> > like it creates a change that still needs to be submitted. And in this case the submodules would be broken until somebody submits that change.
>
> Well that was unclear on my part, there is no change that needs to be
> submitted separately.
>
> Back then, we could only handle topics with no commit in the superproject,
> i.e. you submit in the submodule and Gerrit puts a commit in the superproject
> advancing the submodule pointer. (That worked across multiple submodules)
> That is where my phrasing came from.
>
> What's new (Thanks czhen!), is the ability of Gerrit to cope with a topic
> that also contains commits in the superproject as well as in the submodule.
>
> It's up to you if you want to do the submodule pointer update yourself
> or let Gerrit handle it.
Thanks for clarifying. If this works then I leave the update of the submodule pointer to Gerrit of course :-)
On Fri, Jul 29, 2016 at 1:28 AM, Edwin Kempin <eke...@google.com> wrote:
>> Thanks for clarifying. If this works then I leave the update of the
>> submodule pointer to Gerrit of course :-)
>
> I think there is actually a slight disadvantage with letting Gerrit do it.
> Doesn't this mean that my local workspace is broken, when I checkout that
> Gerrit change, because the submodules would not be updated and hence don't
> compile? If I could checkout the topic that would work, but we don't have
> that yet.
Right, I think the endgoal is to not pay too much attention to the topic, but
rather the superproject being correct.
e.g. for CI/testing we need a REST API call that answers "does this change have
a superproject, and if so how would that look like submission?"
Then you can either ask for the plugin or gerrit change and the CI would test
gerrit with the updated submodule.
>
> How is it after the change is submitted, are the submodules updated when I
> checkout the merged commit?
I think teaching "git checkout" to checkout the submodules or to run
"submodule update" automatically is the next step in Git.
Note that the behavior of Git is constant, no matter if we have
manual or automatic gitlink updates. (e.g. you update gerrit+plugin, and get
it merged, I pull the latest gerrit and notice it doesn't compile with
the plugins.
I could not tell if you or the Gerrit made the superproject update. No matter
how, I need to update the plugin myself for now)
Regards,
Sebastian