Yeah, that's what I was asking. Sounds a lot easier than what I was thinking I would have to do, too. Thanks!
On Mon, Apr 23, 2018 at 12:54 PM, Jason Lowe-Power <[email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
