Hi, On Mon, Apr 28, 2014 at 12:38 PM, Adrien Nader <adr...@notk.org> wrote: > On Mon, Apr 28, 2014, Matthew Brett wrote: >> Hi, >> >> On Mon, Apr 28, 2014 at 11:42 AM, Adrien Nader <adr...@notk.org> wrote: >> > On Mon, Apr 28, 2014, Matthew Brett wrote: >> >> Hi, >> >> >> >> On Mon, Apr 28, 2014 at 8:04 AM, John E. / TDM <tdra...@tdragon.net> >> >> 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).
Sure, if the changes get large, then I often find myself checking out the branch locally as well. The pain comes when commenting on changes line by line using email, and that soon becomes very annoying on a commit - by - commit basis, and tough for the author to track. I haven't found it much of a problem going between the web interface for comments and using local tools to look at diffs, but ``git-pulls browse`` looks like a nice way do to that. Cheers, Matthew ------------------------------------------------------------------------------ "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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
