On Mon, Apr 28, 2014, Matthew Brett wrote: > Hi, > > On Mon, Apr 28, 2014 at 11:42 AM, Adrien Nader <[email protected]> wrote: > > On Mon, Apr 28, 2014, Matthew Brett wrote: > >> Hi, > >> > >> On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM <[email protected]> wrote: > >> > On 4/28/2014 5:17 AM, JonY wrote: > >> >> mingw-w64 may migrate from svn to git in the future, seeing that sf can > >> >> now do multiple repos per project. > >> > *snip* > >> >> Discuss. > >> > > >> > I'm a bit surprised at the choice of Git -- in my experience, Windows > >> > developers usually prefer Mercurial (<http://mercurial.selenic.com/>) > >> > because on Windows it is more lightweight and performant than Git. > >> > > >> > I also prefer Mercurial to Git because I find its syntax and workflow > >> > more intuitive. This is of course personal taste. > >> > > >> > Mercurial repositories are also available in SourceForge. But if the > >> > primary MinGW-w64 contributors are all more familiar with Git then I > >> > suppose it shall be Git. > >> > > >> > My two cents. :) > >> > >> >From the sidelines - a big yes please for switching to git. In my > >> experience, the ease of git branching makes it far more comfortable > >> making and proposing changes, even substantial changes. > >> > >> I hear the same is true of mercurial, but I know it much less well. > >> > >> I very much like the github pull-request system for code review - does > >> sourceforge have something similar? I know bitbucket does. For the > >> projects I'm involved in, pull requests make proposing changes very > >> fluid, and they are good for recording discussion as well. > > > > I quite dislike github and its UI in particular. Uses flash on every > > page (no idea what for) and lots of javascript which makes my laptop > > heat and get noisy when displaying something as small as a 3-lines diff. > > > > Anyway, is there an advantage github's pages over doing it on the > > mailing-list like it is currently done? The amount of messages which > > comes from that doesn't seem to be an issue. > > Sometimes it doesn't seem as if small things will make much > difference, but when you try them, they do. > > Things really change when you're using git - because > > a) work is naturally arranged in commits (this helps review and organization) > b) you can make more substantial changes because branching / merging is so > easy > > This makes it harder to review patches as text in email, because > patches usually don't carry the commit info, and because it's only > comfortable to review small changes in email text. It's very > inconvenient reviewing larger work-in-progress changes via patches, > because it's easy to lose track of the relationship of previous > comments and code changes. If the author responds to comments, they > either have to email the whole revised patch again, or you the > developer need to keep a branch of your own in sync with theirs, in > order to test their changes. > > This is why the pull-request mechanism is so remarkably good in github > - it makes proposing changes part of ordinary workflow. A proposed > change is always just a branch. > > 1) Start work on your own branch > 2) Push to your own fork on github while you're working > 3) Make pull request via a few clicks or 'hub' command line tool > 4) Anyone can comment on whole pull request, individual commits or > individual lines, using github email interface or web form interface. > 5) Comments remain on web interface for public record. > 6) Developer can rebase on master as needed using same pull request pages. > > I think this isn't very obvious at first because svn is so hard to > branch that you very rarely get substantial / long-lived changes > except by the lead developers. > > I really like the command line, I use vim as my editor, never use GUIs > for git - but I couldn't live without the github pull-request > interface for my projects.
I see, thanks. When the amount of code to review gets larger, I simply run gitk which is not pretty but works really well. Gives the commit history and diffs and files modified; it's one of the 3 non-CLI applications I run on a daily basis. I also like that once the changes are available locally (not necessarily checked out on disk), I can use the usual tools to find and grep while github's search has never helped me find something interesting (and same for everyone around me). -- Adrien Nader ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
