Hi Alec, On github you should be using a different branch other than master (say, riscv-fs). Then, you can just rebase that branch on top of master (or origin/master if you've got other commits on master). I often use "git rebase -i master" when doing this. Then, during the rebase you can squash/fixup and reword commits so they fit the gem5 style guides. After rebasing, you can simply push to gem5.googlesource.com to create the review requests :).
With rebasing you do lose the "local" history, but if you want to keep that you can simply rebase to a branch with a different name (say, upstream/riscv-fs in this example). I would argue that it's OK to lose the history in most of these cases as it's really the final cleaned-up commits that matter. I hope this is what you were asking :). I should do a write up on what my git+gem5 workflow is... I'll put that on the (increasingly long) list of blog posts I need to write. Cheers, Jason On Sat, Apr 21, 2018 at 5:29 PM Alec Roelke <[email protected]> wrote: > That's essentially what I was getting at, but I think you put it better. > If I do that, then what is the best way to create a patch from the changes? > > On Fri, Apr 20, 2018 at 6:15 PM, Jason Lowe-Power <[email protected]> > wrote: > > > Hi Alec, > > > > What you're describing is *hard* and requires a lot of coordination > between > > people. I think the best way to do it today is to use something > out-of-band > > like a github mirror and then have one person rebase, etc. and submit to > > the mainline. That's basically what AMD and ARM do internally. It's > harder > > to do with a geographically diverse set of people. > > > > If you need hosting and want to use gerrit for code review during > > development, we can set you up with a repository on > gem5.googlesource.com. > > However, I think the path of least resistance is to set up a github repo. > > E.g., I have a github repo for my research group and that's what we used > > when I was at Wisconsin, too. > > > > Cheers, > > Jason > > > > On Thu, Apr 19, 2018 at 12:02 PM Alec Roelke <[email protected]> wrote: > > > > > I'm not trying to suggest that there should be an "official" way to > > > collaborate on patches, since that's probably not a common enough > > > occurrence to warrant the effort of maintaining such a feature; I was > > > mostly wondering if there was a way to leverage what's already > available > > to > > > do it. Downloading and uploading revisions to others' patches is > clunky > > > and, as Gabe mentioned, can lead to loss of work. I was thinking more > of > > > something like what Jason mentioned with creating a "riscv-fs" clone of > > > gem5 in GitHub or similar and creating patches out of commits to it > > > somehow. Is that possible? > > > > > > I think overall what I'm trying to figure out is proper version control > > for > > > patches before they're uploaded to Gerrit so that two or more people > can > > > work on one thing without worrying about losing work to conflicts. > > > > > > On Wed, Apr 18, 2018 at 8:49 PM, Gabe Black <[email protected]> > > wrote: > > > > > > > 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 > > > > > > > _______________________________________________ > > > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
