Am 25.05.2015 um 16:57 schrieb Ivan Vučica <i...@vucica.net>:
> (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.mott...@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?
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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
