I tried working with git several times, every time I told myself "this time
you're going to give it a serious try", and yet I kept going back to SVN
each and every time. At times I thought "it's because you're too familiar
with SVN, git is probably at least as good once you'll get to master it".
But every time I re-started, I found myself reading about git workflow
again. Every time it made sense to me, every time I felt "this time I
really got it", yet nothing stuck in my brain.

Maybe it's because I never gave it a very long try (I think a week was
longest). But it feels too complicated. Too much typing on the command line
compared to SVN.

What does it give us over SVN? I'm not talking about GIT-vs-SVN, I'm asking
what will GIT give us that we cannot do in our SVN today already. Would
appreciate if someone can point out some benefits.

I don't have a strong opinion. I would not move to GIT myself (we use SVN
at work too) but wouldn't object if the community decides to move to GIT.
If there are barriers (like Uwe's check-svn script), we need to resolve
them.

Question: is it possible to keep the back-end SVN, but have people interact
with it through GIT or SVN clients? My experience with GIT was by forking
Lucene's GIT on github, but I never tried committing from there...

Shai


On Fri, Jan 3, 2014 at 5:17 PM, Mark Miller <[email protected]> wrote:

> Just to answer some of your questions:
>
> On Jan 3, 2014, at 8:18 AM, Uwe Schindler <[email protected]> wrote:
>
> > Hi,
> >
> > I fully agree with Robert: I don't want to move to GIT. In addition,
> unless there is some tool that works as good as Windows' TortoiseSVN also
> for GIT, so I can merge in milliseconds(TM), I won't commit anything.
>
> SmartGit is way better than TortoiseSVN IMO. Your favorite tool is a silly
> way to decide something like this IMO as well though.
>
> >
> > I just note: I was working as committer for the PHP project (maintaining
> the SAPI module for Oracle iPlanet Webserver), but since they moved to GIT
> 2 years ago, I never contributed anything anymore. I just don't understand
> how it works and its completely unusable to me. E.g. look at this bullshit:
> https://wiki.php.net/vcs/gitworkflow - Sorry this is a no-go. And I have
> no idea what all these cryptic commands mean and I don't want to learn
> that. If we move to GIT, somebody else have to commit my patches.
>
> Others committed your patches in the past and I’m sure they will continue
> to do so in the future if you desire.
>
> >
> > And the other comment that was given here is not true: Merging with SVN
> works perfectly fine and is easy to do, unless you use the command line or
> Eclipse's bullshit SVN client (that never works correctly). With a good GUI
> (like the fantastic TortoiseSVN), merging is so simple and conflicts can be
> processed in milliseconds(TM). And it is much easier to understand.
>
> An opinion not commonly shared by my reading. At a minimum, simply opinion
> though.
>
> >
> > Also Subversion is an Apache Project and I want to add: We should eat
> our own dog food. Just to move to something with a crazy license and a
> broken user interface, just because it's cool, is a no-go to me.
>
> Certainly not because it’s cool! Who argued that?
>
> > We would also need to rewrite all our checking tasks (like the
> check-svn-working-copy ANT task) to work with GIT. Is there a pure Java
> library that works for GIT? I assume: No.
>
> You assume wrong. JGit is used by many projects, I’ve used it myself.
>
> > So this is another no-go for me. The checks we do cannot be done by
> command line.
>
> I guess it’s not a no go then, because your assumption was wrong…
>
> - Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to