In my past experience with gerrit, anybody can overwrite anybody else's patch. That may not be true for our instance here, but I suspect it is. All you have to do is make sure the Change-Id: field is the same since that's how gerrit identifies changes. It's generally something to avoid since it can be inconvenient for the original author to download your new version to replace their own locally, to make your edits locally, etc., to avoid blowing away your changes when they upload their own new version.
I think the linux kernel uses both multiple git repositories and multiple git branches within those repositories to separate independent projects. A big problem with that approach is that it takes concerted effort to keep all those different threads in sync and make sure they reconverge at all, and ideally frequently. They have vastly more developers and projects to coordinate than we do, and I don't think the overhead of that approach makes a lot of sense for us at this point and with our current capacity for administrative overhead. If you want to push up your own independent version of somebody's CL for some reason, all you have to do is replace the Change-Id field (delete it and let git recreate it with a new value, for instance) and gerrit will treat it as a new patch even if everything else is the same. There are other ways to put changes up on gerrit which are work in progress sorts of things. Those used to be draft changes, but I think they (the gerrit developers) reworked that into one or two similar but different features. I think one is actually called a work in progress CL? Gabe On Wed, Apr 18, 2018 at 3:18 PM, Jason Lowe-Power <[email protected]> wrote: > Hi Alec, > > First, I'm not sure if collaborating on a single changeset is a common use > case for code review platforms. Though, I have run into a number of times > where it would have been useful. > > Am I understanding your suggestion correctly? What you're envisioning is > there would be a feature branch (say, riscv-fs) and many people could push > changesets onto that branch. Then, when the feature is working you would > merge into master? Or, squash and go through code review? I'm not sure how > the final part would work. > > I'm open to this kind of workflow. We can create branches on gerrit. > Another option is what ARM and AMD are doing which is having their own repo > hosted on gem5.googlesource.com. > > What does the Linux kernel do in this case, I wonder. They have done a good > job working out procedures for massive open source development. They are > usually a good inspiration. > > Second, as a maintainer, I believe you have enough access to just overwrite > someone else's commit. For instance, if you download a changeset, then > rebase, then push to refs/for/master it will update the review request. So, > as a maintainer, you can make a small change instead of asking the original > author. (I think this is right... I know *I* can modify patches and I think > it's the maintainer flag, not admin. If I'm wrong we can talk about > changing this permission.) > > Cheers, > Jason > > On Wed, Apr 18, 2018 at 1:02 PM Alec Roelke <[email protected]> wrote: > > > Hi Everyone, > > > > Is there a way to allow multiple people to collaborate on a patch? Right > > now it looks to me like the only person who can make changes to a patch > is > > the owner, which means that others' contributions have to be manually > > added. Would it be possible for a person to create a personal branch of > > gem5 on GitHub or other git repository and then somehow push changes from > > there to Gerrit? > > > > Thanks, > > Alec Roelke > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
