Re: [gem5-dev] Migrating to git and gerrit
Hi Brandon, You can make your changes to the code, then run "git commit --amend" to amend the most recent commit. Basically, you want to update the same commit that you pushed before. After that, you can push it using the same command and gerrit will figure it out. Does this answer your question about the commit log? Basically, the main difference between hg and git is that git allows you to easily change history. Whereas hg makes it impossible (or very hard) to change history. There are arguments for both sides, but let's be honest, git won. I'm not git expert, so maybe others have better answers (and it looks like Gabe replied while I was writing this anyway). Cheers, Jason On Wed, Mar 1, 2017 at 4:31 PM Potter, Brandon <brandon.pot...@amd.com> wrote: > Hello Andreas, > > Newbie gerrit/git questions here: > > If someone requests a modification to a changeset in a review (or I > realize something is wrong with the changeset myself), how do I update the > posted review on Gerrit for the specified changeset? Mercurial/Reviewboard > would be something like hg qref followed by hg postreview -oue and the > patch on Reviewboard would be updated to reflect the changes. How do we > achieve a similar behavior here? > > Furthermore, what does the resulting commit log look like given whatever > workflow you use? Ideally, we'd like the commit log to reflect coherent, > atomic changes that implement one specific feature at a time. I don't want > to public many incoherent changesets that are iterating to the > right/accepted solution to implement a feature. > > Regards, > Brandon > > -Original Message- > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas > Sandberg > Sent: Wednesday, March 1, 2017 8:44 AM > To: gem5 Developer List <gem5-dev@gem5.org> > Subject: Re: [gem5-dev] Migrating to git and gerrit > > Hi Everyone, > > The new Gerrit-based infrastructure is now live with the old Mercurial > repository as a read-only mirror. Mirroring is currently done using a cron > job that executes every 15 minutes, which means that there is some amount > of lag between the gerrit master version and the mirrors. > > Those of you with commit access who plan to submit patches that have been > on reviewed using the old infrastructure will need to convert these patches > to git and push them to the main repository. It is highly recommended that > patches without reviews are discarded and re-posted using the Gerrit flow > to reduce the maintenance overhead of committing patches. > > Existing Mercurial patches (e.g., from patch queues) can be converted > using the hg-patch-to-git-patch [1] script from Mozilla. The patch > conversion script makes sure that the commit message and author information > can be understood by git. Before converting your patches, make sure they > apply cleanly on the current master branch. The best way to check this is > by qpop:ing your patch queue, pulling in new changes, and then reapplying > it. If you get warnings when applying patches, you need to qrefresh them to > make sure that the diffs are up to date. > Failing to do so will result in git refusing the patch. > > Once you have a patch queue that applies cleanly, you can import it into a > new git branch using the following commands: > > # Create a new clone of the master repository git clone > https://gem5.googlesource.com/public/gem5 gem5 cd gem5 # Install Gerrit's > commit message hook. This is done automatically by scons when you build > gem5. > cp ext/git-commit-msg .git/hooks/commit-msg > > # Create a new branch for the outgoing changes git checkout -b fixes > origin/master > > hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patch1.patch | git am > # Run the commit message hook to generate a Change-id by amending the > commit git commit --amend ... > hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patchN.patch | git am > git commit --amend > > To push the branch for review (remember to test it and verify that the > commit log looks OK first!), execute the following command: > > git push origin HEAD:refs/for/master > > It's sometimes useful to set a patch series topic if you're submitting > multiple patches. To do that when you submit patches for review, use this > command instead: > > git push origin HEAD:refs/for/master%topic=my/topic > > Some users can bypass reviews and push changes straight into the master > branch. This should only be done for code that has been reviewed using the > ReviewBoard-based flow. If you're one of the select few, you can use the > following push command to bypass review: > > git push origin HEAD:refs/heads/master > > > Cheers, > Andreas > > [1] > https://github
Re: [gem5-dev] Migrating to git and gerrit
In the gerrit instances we use at work, the changes will have a commit ID in their commit message (added automatically by a hook, at least in our work flow) and that will uniquely identify a change to gerrit even if it changes significantly, is rebased, etc. You can use git commit --amend to update an existing commit, and git rebase -i to manage a local branch of changes and combine them together, reorder them, get rid of them, etc. One workflow people use with git is to make a lot of little commits which as an aggregate do whatever they're trying to do, and then at the end squash them together (or their tool does, but gerrit does not) for review. What I do is to keep a set of patches which are more like the finished product, and when I need to make additional changes I fold that into the commits immediately with the commands I mentioned. Either should work. Gabe On Wed, Mar 1, 2017 at 1:31 PM, Potter, Brandon <brandon.pot...@amd.com> wrote: > Hello Andreas, > > Newbie gerrit/git questions here: > > If someone requests a modification to a changeset in a review (or I > realize something is wrong with the changeset myself), how do I update the > posted review on Gerrit for the specified changeset? Mercurial/Reviewboard > would be something like hg qref followed by hg postreview -oue and the > patch on Reviewboard would be updated to reflect the changes. How do we > achieve a similar behavior here? > > Furthermore, what does the resulting commit log look like given whatever > workflow you use? Ideally, we'd like the commit log to reflect coherent, > atomic changes that implement one specific feature at a time. I don't want > to public many incoherent changesets that are iterating to the > right/accepted solution to implement a feature. > > Regards, > Brandon > > -Original Message- > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas > Sandberg > Sent: Wednesday, March 1, 2017 8:44 AM > To: gem5 Developer List <gem5-dev@gem5.org> > Subject: Re: [gem5-dev] Migrating to git and gerrit > > Hi Everyone, > > The new Gerrit-based infrastructure is now live with the old Mercurial > repository as a read-only mirror. Mirroring is currently done using a cron > job that executes every 15 minutes, which means that there is some amount > of lag between the gerrit master version and the mirrors. > > Those of you with commit access who plan to submit patches that have been > on reviewed using the old infrastructure will need to convert these patches > to git and push them to the main repository. It is highly recommended that > patches without reviews are discarded and re-posted using the Gerrit flow > to reduce the maintenance overhead of committing patches. > > Existing Mercurial patches (e.g., from patch queues) can be converted > using the hg-patch-to-git-patch [1] script from Mozilla. The patch > conversion script makes sure that the commit message and author information > can be understood by git. Before converting your patches, make sure they > apply cleanly on the current master branch. The best way to check this is > by qpop:ing your patch queue, pulling in new changes, and then reapplying > it. If you get warnings when applying patches, you need to qrefresh them to > make sure that the diffs are up to date. > Failing to do so will result in git refusing the patch. > > Once you have a patch queue that applies cleanly, you can import it into a > new git branch using the following commands: > > # Create a new clone of the master repository git clone > https://gem5.googlesource.com/public/gem5 gem5 cd gem5 # Install Gerrit's > commit message hook. This is done automatically by scons when you build > gem5. > cp ext/git-commit-msg .git/hooks/commit-msg > > # Create a new branch for the outgoing changes git checkout -b fixes > origin/master > > hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patch1.patch | git am > # Run the commit message hook to generate a Change-id by amending the > commit git commit --amend ... > hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patchN.patch | git am > git commit --amend > > To push the branch for review (remember to test it and verify that the > commit log looks OK first!), execute the following command: > > git push origin HEAD:refs/for/master > > It's sometimes useful to set a patch series topic if you're submitting > multiple patches. To do that when you submit patches for review, use this > command instead: > > git push origin HEAD:refs/for/master%topic=my/topic > > Some users can bypass reviews and push changes straight into the master > branch. This should only be done for code that has been reviewed using the > ReviewBoard-based flow. If you're one of the select few, you can use t
Re: [gem5-dev] Migrating to git and gerrit
Hello Andreas, Newbie gerrit/git questions here: If someone requests a modification to a changeset in a review (or I realize something is wrong with the changeset myself), how do I update the posted review on Gerrit for the specified changeset? Mercurial/Reviewboard would be something like hg qref followed by hg postreview -oue and the patch on Reviewboard would be updated to reflect the changes. How do we achieve a similar behavior here? Furthermore, what does the resulting commit log look like given whatever workflow you use? Ideally, we'd like the commit log to reflect coherent, atomic changes that implement one specific feature at a time. I don't want to public many incoherent changesets that are iterating to the right/accepted solution to implement a feature. Regards, Brandon -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Sandberg Sent: Wednesday, March 1, 2017 8:44 AM To: gem5 Developer List <gem5-dev@gem5.org> Subject: Re: [gem5-dev] Migrating to git and gerrit Hi Everyone, The new Gerrit-based infrastructure is now live with the old Mercurial repository as a read-only mirror. Mirroring is currently done using a cron job that executes every 15 minutes, which means that there is some amount of lag between the gerrit master version and the mirrors. Those of you with commit access who plan to submit patches that have been on reviewed using the old infrastructure will need to convert these patches to git and push them to the main repository. It is highly recommended that patches without reviews are discarded and re-posted using the Gerrit flow to reduce the maintenance overhead of committing patches. Existing Mercurial patches (e.g., from patch queues) can be converted using the hg-patch-to-git-patch [1] script from Mozilla. The patch conversion script makes sure that the commit message and author information can be understood by git. Before converting your patches, make sure they apply cleanly on the current master branch. The best way to check this is by qpop:ing your patch queue, pulling in new changes, and then reapplying it. If you get warnings when applying patches, you need to qrefresh them to make sure that the diffs are up to date. Failing to do so will result in git refusing the patch. Once you have a patch queue that applies cleanly, you can import it into a new git branch using the following commands: # Create a new clone of the master repository git clone https://gem5.googlesource.com/public/gem5 gem5 cd gem5 # Install Gerrit's commit message hook. This is done automatically by scons when you build gem5. cp ext/git-commit-msg .git/hooks/commit-msg # Create a new branch for the outgoing changes git checkout -b fixes origin/master hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patch1.patch | git am # Run the commit message hook to generate a Change-id by amending the commit git commit --amend ... hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patchN.patch | git am git commit --amend To push the branch for review (remember to test it and verify that the commit log looks OK first!), execute the following command: git push origin HEAD:refs/for/master It's sometimes useful to set a patch series topic if you're submitting multiple patches. To do that when you submit patches for review, use this command instead: git push origin HEAD:refs/for/master%topic=my/topic Some users can bypass reviews and push changes straight into the master branch. This should only be done for code that has been reviewed using the ReviewBoard-based flow. If you're one of the select few, you can use the following push command to bypass review: git push origin HEAD:refs/heads/master Cheers, Andreas [1] https://github.com/mozilla/moz-git-tools/raw/master/hg-patch-to-git-patch On 16/02/2017 16:54, Jason Lowe-Power wrote: > Hi all, > > We've been talking about this for a while, but now it's time! Special > thanks to Andreas Sandberg for all of his hard work for putting this > together. > > We will be migrating our infrastructure from the self-hosted mercurial > repo at repo.gem5.org and reviewboard to git and gerrit hosted on > Google's new googlesource website. You can find a live version (not > ready for primetime) of this at https://gem5.googlesource.com/. > > We are planning on flipping the switch on *March 1st*, unless there is > an objection from the community. Note: I'm announcing this on gem5-dev > before announcing on gem5-users and gem5-announce in case there's any > details we've missed. > > I've posted a patch on reviewboard that contains a new CONTRIBUTING > document that details the new contribution process. Please review that > document so it can be pushed before we transition. ( > http://reviews.gem5.org/r/3814/) > > The major changes are detailed below: > 1. REPOSITORIES >* The canonical version
Re: [gem5-dev] Migrating to git and gerrit
Hi Everyone, The new Gerrit-based infrastructure is now live with the old Mercurial repository as a read-only mirror. Mirroring is currently done using a cron job that executes every 15 minutes, which means that there is some amount of lag between the gerrit master version and the mirrors. Those of you with commit access who plan to submit patches that have been on reviewed using the old infrastructure will need to convert these patches to git and push them to the main repository. It is highly recommended that patches without reviews are discarded and re-posted using the Gerrit flow to reduce the maintenance overhead of committing patches. Existing Mercurial patches (e.g., from patch queues) can be converted using the hg-patch-to-git-patch [1] script from Mozilla. The patch conversion script makes sure that the commit message and author information can be understood by git. Before converting your patches, make sure they apply cleanly on the current master branch. The best way to check this is by qpop:ing your patch queue, pulling in new changes, and then reapplying it. If you get warnings when applying patches, you need to qrefresh them to make sure that the diffs are up to date. Failing to do so will result in git refusing the patch. Once you have a patch queue that applies cleanly, you can import it into a new git branch using the following commands: # Create a new clone of the master repository git clone https://gem5.googlesource.com/public/gem5 gem5 cd gem5 # Install Gerrit's commit message hook. This is done automatically by scons when you build gem5. cp ext/git-commit-msg .git/hooks/commit-msg # Create a new branch for the outgoing changes git checkout -b fixes origin/master hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patch1.patch | git am # Run the commit message hook to generate a Change-id by amending the commit git commit --amend ... hg-patch-to-git-patch /path/to/old/gem5/.hg/patches/patchN.patch | git am git commit --amend To push the branch for review (remember to test it and verify that the commit log looks OK first!), execute the following command: git push origin HEAD:refs/for/master It's sometimes useful to set a patch series topic if you're submitting multiple patches. To do that when you submit patches for review, use this command instead: git push origin HEAD:refs/for/master%topic=my/topic Some users can bypass reviews and push changes straight into the master branch. This should only be done for code that has been reviewed using the ReviewBoard-based flow. If you're one of the select few, you can use the following push command to bypass review: git push origin HEAD:refs/heads/master Cheers, Andreas [1] https://github.com/mozilla/moz-git-tools/raw/master/hg-patch-to-git-patch On 16/02/2017 16:54, Jason Lowe-Power wrote: Hi all, We've been talking about this for a while, but now it's time! Special thanks to Andreas Sandberg for all of his hard work for putting this together. We will be migrating our infrastructure from the self-hosted mercurial repo at repo.gem5.org and reviewboard to git and gerrit hosted on Google's new googlesource website. You can find a live version (not ready for primetime) of this at https://gem5.googlesource.com/. We are planning on flipping the switch on *March 1st*, unless there is an objection from the community. Note: I'm announcing this on gem5-dev before announcing on gem5-users and gem5-announce in case there's any details we've missed. I've posted a patch on reviewboard that contains a new CONTRIBUTING document that details the new contribution process. Please review that document so it can be pushed before we transition. ( http://reviews.gem5.org/r/3814/) The major changes are detailed below: 1. REPOSITORIES * The canonical version of gem5 will now live at https://gem5.googlesource.com/, not repo.gem5.org * The mercurial repository at repo.gem5.org will be a read-only mirror of the googlesource repo. * We will keep the github mirror 2. CODE REVIEWS * All reviews will happen on https://gem5-review.googlesource.com/. * No new patches will be accepted on reviewboard after March 1. Any patches still on reviewboard will be discussed/reviewed there, but committers will have to manually commit them to the git repo (not unlike our current situation). Main differences for developers: 1. You will have to learn to use git, if you haven't already 2. Developers who submit patches will be able to *commit their own patches* after review. No more waiting for me to push patches for you! 3. Continuous integration tests are coming soon, and must pass before a patch is committed. 4. Gerrit has a different user-interface than reviewboard... sorry for the change. 5. Many of the policies we have for commits will be *strictly enforced* automatically by gerrit. E.g., it will no longer be possible to post a patch that has a non-conforming commit message. 6. Instead of using postreview, patches will be posted by pushing to special
[gem5-dev] Migrating to git and gerrit
Hi all, We've been talking about this for a while, but now it's time! Special thanks to Andreas Sandberg for all of his hard work for putting this together. We will be migrating our infrastructure from the self-hosted mercurial repo at repo.gem5.org and reviewboard to git and gerrit hosted on Google's new googlesource website. You can find a live version (not ready for primetime) of this at https://gem5.googlesource.com/. We are planning on flipping the switch on *March 1st*, unless there is an objection from the community. Note: I'm announcing this on gem5-dev before announcing on gem5-users and gem5-announce in case there's any details we've missed. I've posted a patch on reviewboard that contains a new CONTRIBUTING document that details the new contribution process. Please review that document so it can be pushed before we transition. ( http://reviews.gem5.org/r/3814/) The major changes are detailed below: 1. REPOSITORIES * The canonical version of gem5 will now live at https://gem5.googlesource.com/, not repo.gem5.org * The mercurial repository at repo.gem5.org will be a read-only mirror of the googlesource repo. * We will keep the github mirror 2. CODE REVIEWS * All reviews will happen on https://gem5-review.googlesource.com/. * No new patches will be accepted on reviewboard after March 1. Any patches still on reviewboard will be discussed/reviewed there, but committers will have to manually commit them to the git repo (not unlike our current situation). Main differences for developers: 1. You will have to learn to use git, if you haven't already 2. Developers who submit patches will be able to *commit their own patches* after review. No more waiting for me to push patches for you! 3. Continuous integration tests are coming soon, and must pass before a patch is committed. 4. Gerrit has a different user-interface than reviewboard... sorry for the change. 5. Many of the policies we have for commits will be *strictly enforced* automatically by gerrit. E.g., it will no longer be possible to post a patch that has a non-conforming commit message. 6. Instead of using postreview, patches will be posted by pushing to special git branches on our gerrit instance. *Please let me know if you have any questions or concerns. I'd like to iron all of this out in the next few days so we can post the announcement on gem5-users and gem5-announce.* I would also like to thank the team at Google that has generously donated their time to set up this infrastructure. This include Rahul Thakur, Jason Buberel, Haihong Zhuo, and many others. Cheers, Jason ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
