Re: Proposal: Switch back to savannah using GIT

[Ivan Vučica]

(Note: This email is not an attack on Subversion. I am not a fan of Git -- in fact, I avoid it whenever I can in favor of Mercurial. And it most certainly is not personal :-) but a discussion of technical merits I think Git has for our specific use case.)

On Mon, May 25, 2015 at 2:26 PM, Riccardo Mottola <riccardo.mottola@libero.it> wrote:

Of course, you will find a lot of "pro GIT" articles: clear, if it is a trend it is always so, I just wanted to point out that SVN works for us and works quite well

Does it? 

I think it works.

I don't think it works well.

I certainly don't think it works quite well.

- Is commenting on patches in an email the best we can do? Wouldn't inline comments be better?

- Do you enjoy wrestling with svn switch --relocate when you want to make a patch for a project that was checked out with .../modules/?

- Is it not better to encourage multiple smaller commits, for readability's sake? DVCS systems make this less painful without fear of breaking the build for other users.

And Git particularly, even though its UI is horrible (but made tolerable with SourceTree et al), lets me commit a single line, even though locally I have thirty other modifications.

I'm not saying Subversion is the wrong tool for every project. For example, even with git annex (or hg largefiles) I would strongly consider tracking binary files with Subversion or other centralized version control.

But I do strongly feel Git is a better fit for GNUstep.

Not because of trends. Instead, because Git-based code is faster to manage, nicely hosted, easier to migrate, trivial to fork from and then merge back (with code review, even!).

And I usually want my code to be reviewed if I'm touching one of the core libraries. And since code review won't happen unless it's trivial to do, I want tools to support that. Not flinging patches over email and hoping people can scrape time to open the patch, browse through it, apply it to test it, then figure out which lines they want to comment on, composing that in the email. That's terrible experience, one that should not be experienced by people willing to spend their time reviewing contributions.

While 'divide-and-conquer' searching to find the exact commit where a certain bug was introduced, do you honestly want to deal with the delays introduced by 'svn up'?

Do you want to wait for the server every time you need to 'svn blame' a file? What if you want to 'svn blame' fifty files?

You mention binary and large files -- how many binary and large files do we stash? If it's "many", do we care enough to want to store them in the main repository?

I'd gladly sacrifice empty directories for speed, for ability to add single line even though a file has twenty lines of changes, for merging a set of patches with a single 'git pull', for attributing the patches to their rightful authors, instead of 'committed by x, thanks for the patch to y'.