Hallo,
As you may be aware, the git-review based developer experience on Windows is less than perfect - especially compared to the old TortoiseSVN based workflow. I have tried several options, which I will try to document in the coming weeks.
One of the options is using the GitHub workflow. Yuvi Panda is working on an automatic way to move Pull requests to Gerrit [1], which would make this workflow a possibility.
The basic idea is to have a 'triangular workflow': You pull from a central repository, push to a public fork of that repository and then submit a pull request. I have documented this process, using GitHub for Windows at https://www.mediawiki.org/wiki/Gerrit/GitHub.
Any comments are, of course, welcome. Any ideas on how to improve the contributing experience for Windows-based developers - or information on how Windows-based developers contribute currently - would also be appreciated.
Best, Merlijn
Am 15.09.2013 17:13 schrieb "Merlijn van Deen" valhallasw@arctus.nl: ...
As you may be aware, the git-review based developer experience on Windows is less than perfect - especially compared to the old TortoiseSVN based workflow.
Merlijn, as i m not contributing code here but am very interested in suitable git workflows, i am a little shy to ask, but what is the main disadvantage compared to contributors on linux, and whats the main disadvantage compared to subversion?
Rupert
On Sun, 15 Sep 2013 21:46:11 +0200, rupert THURNER rupert.thurner@gmail.com wrote:
what is the main disadvantage compared to contributors on linux
The only disadvantage I'm aware of is that most recent versions of git-review are broken and unable to install the commit-msg hook which adds Change-Id lines to commit messages. It can still be installed manually and everything works perfectly then. (This was already fixed once and then they unfixed it.)
Le 15/09/13 22:00, Bartosz Dziewoński a écrit :
The only disadvantage I'm aware of is that most recent versions of git-review are broken and unable to install the commit-msg hook which adds Change-Id lines to commit messages. It can still be installed manually and everything works perfectly then. (This was already fixed once and then they unfixed it.)
Has it been reported upstream on launchpad.net ? We have good karma with them and I can help getting patches getting reviewed/merged.
On Sun, Sep 15, 2013 at 12:46 PM, rupert THURNER rupert.thurner@gmail.comwrote:
Am 15.09.2013 17:13 schrieb "Merlijn van Deen" valhallasw@arctus.nl: ...
As you may be aware, the git-review based developer experience on Windows is less than perfect - especially compared to the old TortoiseSVN based workflow.
Merlijn, as i m not contributing code here but am very interested in suitable git workflows, i am a little shy to ask, but what is the main disadvantage compared to contributors on linux, and whats the main disadvantage compared to subversion?
I believe it's not subversion itself as much as the user-interface of TortoiseSVN, which lots of people have found easy to use and powerful.
git-review kind of forces you to use the command-line interface to git, which also tends to be slightly more complicated on Windows than on Linux because you're kind of smashing together a Unix-like environment and a Windows-like environment. (ick!) I'm used to git on Linux and OS X, but I'm still a bit frustrated when I end up having to do some git work on Windows.
GitHub has a nice GUI app for Windows which should make it fairly easy to send a pull request (which we then bridge straight into gerrit), or folks may more easily use a different git front-end UI they prefer, if they don't have to poke git-review directly.
Alternatively, we could try to get git-review type support into some of those GUI tools...
-- brion
Since we already have github mirrors of wmf repos and a tool already written to bridge github and credit, it seems like we should give that a go before starting to work on any other alternatives. As I understand it, projects/repos have to opt-in to the github bridge bot, and not many repos have done so yet. Can we start by turning it on more generally? --scott On Sep 15, 2013 4:01 PM, "Brion Vibber" bvibber@wikimedia.org wrote:
On Sun, Sep 15, 2013 at 12:46 PM, rupert THURNER rupert.thurner@gmail.comwrote:
Am 15.09.2013 17:13 schrieb "Merlijn van Deen" valhallasw@arctus.nl: ...
As you may be aware, the git-review based developer experience on
Windows
is less than perfect - especially compared to the old TortoiseSVN based workflow.
Merlijn, as i m not contributing code here but am very interested in suitable git workflows, i am a little shy to ask, but what is the main disadvantage compared to contributors on linux, and whats the main disadvantage compared to subversion?
I believe it's not subversion itself as much as the user-interface of TortoiseSVN, which lots of people have found easy to use and powerful.
git-review kind of forces you to use the command-line interface to git, which also tends to be slightly more complicated on Windows than on Linux because you're kind of smashing together a Unix-like environment and a Windows-like environment. (ick!) I'm used to git on Linux and OS X, but I'm still a bit frustrated when I end up having to do some git work on Windows.
GitHub has a nice GUI app for Windows which should make it fairly easy to send a pull request (which we then bridge straight into gerrit), or folks may more easily use a different git front-end UI they prefer, if they don't have to poke git-review directly.
Alternatively, we could try to get git-review type support into some of those GUI tools...
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 15 September 2013 22:01, Brion Vibber bvibber@wikimedia.org wrote:
I believe it's not subversion itself as much as the user-interface of TortoiseSVN, which lots of people have found easy to use and powerful.
git-review kind of forces you to use the command-line interface to git, which also tends to be slightly more complicated on Windows than on Linux because you're kind of smashing together a Unix-like environment and a Windows-like environment.
Those are indeed basically the two reasons I'm looking into this. On linux, the git-review workflow is relatively smooth, but on windows it's so much harder because the console is clunky, and the GUI-based tools are nowhere near how great they were in the SVN era. This, of course, partially has to do with complexity, but also with the audience: if the typical developer uses linux, who will develop something great for windows?
GitHub has a nice GUI app for Windows which should make it fairly easy to send a pull request (which we then bridge straight into gerrit), or folks may more easily use a different git front-end UI they prefer, if they don't have to poke git-review directly.
In this case, I mainly used GitHub for Windows because it has some GH integration - but it's nowhere near complete. The triangular push/pull doesn't work without occasional hickups. I have contacted the GHfW team, and they are working on a better integration. I could very well be the best solution is via GitHub but not using GHfW - I'm still experimenting with different options :-)
Alternatively, we could try to get git-review type support into some of those GUI tools...
Eclipse, using Mylyn, in theory has support for this. However, the Mylyn Gerrit connector only works with 2.6, while we already use 2.7. They are working on support [1], and I will try how well it works once I get it to work. Unfortunately, it also means you have to deal with a lot of the typical Eclipse 'I have a wizard, and it won't close'-type issues. GitEye is basically a stripped down Eclipse with Mylyn and EGit.
I'm not sure how much effort it would be to add support to existing tools - in the end, the Gerrit workflow is not that difficult - it basically adds an 'commit to secondary branch and submit' option and a 'review' option. It might very well be worth the effort.
Merlijn
On Mon, Sep 16, 2013 at 5:07 PM, Merlijn van Deen valhallasw@arctus.nl wrote:
Eclipse, using Mylyn, in theory has support for this. However, the Mylyn Gerrit connector only works with 2.6, while we already use 2.7. They are working on support [1], and I will try how well it works once I get it to work. Unfortunately, it also means you have to deal with a lot of the typical Eclipse 'I have a wizard, and it won't close'-type issues. GitEye is basically a stripped down Eclipse with Mylyn and EGit.
If you install Eclipse Kepler and Mylyn Review from the Nightlies (at http://download.eclipse.org/reviews/nightly) it already works with Wikimedia.
David E. Narvaez
On Sun, Sep 15, 2013 at 10:01 PM, Brion Vibber bvibber@wikimedia.orgwrote:
On Sun, Sep 15, 2013 at 12:46 PM, rupert THURNER rupert.thurner@gmail.comwrote:
Am 15.09.2013 17:13 schrieb "Merlijn van Deen" valhallasw@arctus.nl: ...
As you may be aware, the git-review based developer experience on
Windows
is less than perfect - especially compared to the old TortoiseSVN based workflow.
Merlijn, as i m not contributing code here but am very interested in suitable git workflows, i am a little shy to ask, but what is the main disadvantage compared to contributors on linux, and whats the main disadvantage compared to subversion?
I believe it's not subversion itself as much as the user-interface of TortoiseSVN, which lots of people have found easy to use and powerful. [...]
Alternatively, we could try to get git-review type support into some of those GUI tools...
Git for Eclipse has very good support for Gerrit and is very easy to use.
I've screenshots for every step that you need to use Git for Eclipse with Wikimedia's Gerrit, with the intention to eventually write a tutorial, but that may take some time to finish.
Bryan
Le 15/09/13 17:12, Merlijn van Deen a écrit :
As you may be aware, the git-review based developer experience on Windows is less than perfect - especially compared to the old TortoiseSVN based workflow. I have tried several options, which I will try to document in the coming weeks.
Dont we have a bunch of VisualStudio aware folks to hack in tortoiseGit and add support for Gerrit in it?
One of the options is using the GitHub workflow. Yuvi Panda is working on an automatic way to move Pull requests to Gerrit [1], which would make this workflow a possibility.
<snip>
If I understand it properly, people send their pull requests via GitHub and a bot sync them in Gerrit. What would happen when someone review the change in Gerrit and the user does not use Gerrit either? :-]
It appears that YuviPanda is a magician (oops, am I not supposed to use that word?) and comments are sync'ed bidirectionally: https://git.wikimedia.org/blob/labs%2Ftools%2FSuchABot.git/62c8fcd6764db7d31... --scott
On Wed, Sep 18, 2013 at 3:57 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 15/09/13 17:12, Merlijn van Deen a écrit :
As you may be aware, the git-review based developer experience on Windows is less than perfect - especially compared to the old TortoiseSVN based workflow. I have tried several options, which I will try to document in
the
coming weeks.
Dont we have a bunch of VisualStudio aware folks to hack in tortoiseGit and add support for Gerrit in it?
One of the options is using the GitHub workflow. Yuvi Panda is working on an automatic way to move Pull requests to Gerrit [1], which would make
this
workflow a possibility.
<snip>
If I understand it properly, people send their pull requests via GitHub and a bot sync them in Gerrit. What would happen when someone review the change in Gerrit and the user does not use Gerrit either? :-]
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 18/09/13 16:27, C. Scott Ananian a écrit :
It appears that YuviPanda is a magician (oops, am I not supposed to use that word?) and comments are sync'ed bidirectionally: https://git.wikimedia.org/blob/labs%2Ftools%2FSuchABot.git/62c8fcd6764db7d31...
As much I hate how much effort we put in GitHub, I guess that would work for me :-]
wikitech-l@lists.wikimedia.org