Re: [Mingw-w64-public] mingw-w64 may move to git in the future

[JonY <jo...@us...>]

On 4/29/2014 14:49, Rodny wrote:
> JonY <jon_y@...> writes:
> 
>>
>> Hi,
>>
>> mingw-w64 may migrate from svn to git in the future, seeing that sf can
>> now do multiple repos per project.
>>
>> Structure wise, everything under trunk will still stay together in the
>> new repo, but any externals, /experimental/* and /web may move into its
>> own repo.
>>
>> Discuss.
> 
> Hello, world.  First time poster, long time user.
> 
> I know I'm in the minority, but I'd just like to say that I'm actually
> against this change.  We use your products in house here almost constantly
> (Bob's your uncle for that!), and we really love how easy it is to use your
> code base.  We always build our own toolchains, and we are setup to
> interface directly to you.  Switching this up for no apparent reason throws
> a giant wrench into our operation.  With our staffing, we will be fubar
> bundied for all you WW2 buffs out there.
> 
> I noticed that everyone in this thread, including this original post, is
> coming from the standpoint of "why not use git?" while I'd like to ask you
> the question, "Why are you changing?"
> 

Because it was a pain to track down patches applied to other branches
and reapply it again and again, cherry-pick is god sent. Not to mention
merging is quick and simple. It is also far far easier to do a long term
private branch in git than in SVN, not to mention, multi-part commit
patches are nice.

> Ignoring the endless holy wars, some practical concerns that we have here
> are the dismal support on native windows for git.  TortoiseSVN makes
> browsing your changes and picking the ones we want extremely easy in a
> graphical environment on the platform that you're built to provide
> compilers for.  It just seems natural for a Windows Compiler Project to use
> tools that... you know... work on windows.  (Yes, I know of msysgit.  My
> statements stand.)
> 

TortoiseGit. And no, you are not expected to work using Windows tools
just because it is for Windows. You'd be surprised to learn most of the
changes are not done on Windows at all.

> Another practical concern -- do we now have to checkout your entire
> repository just to get one revision?  git lets you get All or Head.  What
> about  the equivalent of 1234?  Will you provide documentation for users
> like us to adapt to this new model?  Or are we stuck?
> 

Just grab it once (or use a local cache) and then checkout the revision
you want.

> How will you handle all the various things that you currently distribute? 
> You have a lot of stuff in your repository, and it all works nicely because
> of how svn treats each directory as essentially a separate repo.  What are
> you going to do about the branches, tags, and experimentals?
> 

Already mentioned in the original email.

> Have you even considered other distributed systems?  Mercurial, Bazaar?  Or
> is it git all the way just because it's git?  Git is much more of a "Do
> what Linus says" project, than it is a tool that's solving a problem.
> 

What does Linus have to do with the decision? If anything, I'll use it
because Linus recommends it.

> I'd actually like to see you move to a more recent version of svn that has
> a lot of new whiz-bang features that make it more desirable to stay with
> the status quo.  Contrary to popular belief, git doesn't merge/branch any
> better than svn, unless you compare brand new git to svn v1.0.
> 
> Finally... why not just set up a git mirror like so many other projects do?
> 

Because git commits cannot easily push back to SVN, and great, you have
all the power of git and the inconvenience of SVN.