Re: Proposal: Switch back to savannah using GIT

[Dr. H. Nikolaus Schaller]

Am 25.05.2015 um 16:57 schrieb Ivan Vučica <address@hidden>:

(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 <address@hidden> 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?

Well, this is not a feature of git. But of github.

- 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.

Exactly. My typical workflow is:

checkout a branch

work on it, test

then git diff to see what I have really changed after editing the sources back and forth

use git add -p to make small and logically connected patches

git commit each one and repeat git add -p until done

finally git push when connected to the network next time

I couldn’t do that when working with SVN.

Rather my workflow was:

svn update

work on it, test

git commit everything (related or unrelated) before I lost network connection (e.g. when working on the road) to be able to svn update on a different machine

This ended up in big commits with multiple, completely unrelated changes. Yes, the resulting working tree was what I wanted to have, but the intermediate steps were horrible, untraceable and unrevertable.

You can still do the same with git (git commit -a), but you do not need to use it that way. If commits are done carefully, it is easy to git revert it weeks later.

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 this are more facts than opinions. They are amongst the reasons why there is a trend from SVN towards git. Even if some projects decide for good reasons to go with SVN, they are a minority.

Well, the minority might be right. And sometimes is. But sometimes the majority might be right. Especially if it is about “tools” and not the project itself.

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,

If a patch is small, even that works as on LKML.

apply it to test it,

this is indeed very important. With git I open a new branch, apply the patch, test - and perhaps modify. But don’t have to commit or push anything. This is here git am or git cherry pick does a good job.

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'?

I have rarely tried to use git bisect - and if I wasn’t successful (because it needs some discipline when committing patches). But that is indeed a powerful git feature.

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 think we should not have any.

I’d gladly sacrifice empty directories

What do we need them for?

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'.

+++

You see, I am strongly in favour of git - but not because I am a “fan” (I hated it the first months and sometimes still do), but because it is better to use. I would immediately switch if I could get access to something even better than git.

BR,

Nikolaus

PS: Better is the enemy of good.