It also doesn't deal with a major difference between git and svn - in svn, directories are first-class objects, and in git they aren't (they are created as needed). So when you try using gitsvn you almost always wind up with directories you want to remove but can't.
Karl From: ext Michael Della Bitta [mailto:[email protected]] Sent: Friday, January 03, 2014 11:21 AM To: [email protected] Subject: Re: The Old Git Discussion > 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... There's git svn: http://git-scm.com/book/ch8-1.html But it doesn't really achieve many of the benefits of using Git, chiefly, the distributed revision control paradigm. Michael Della Bitta Applications Developer o: +1 646 532 3062 | c: +1 917 477 7906 appinions inc. "The Science of Influence Marketing" 18 East 41st Street New York, NY 10017 t: @appinions<https://twitter.com/Appinions> | g+: plus.google.com/appinions<https://plus.google.com/u/0/b/112002776285509593336/112002776285509593336/posts> w: appinions.com<http://www.appinions.com/> On Fri, Jan 3, 2014 at 11:08 AM, Shai Erera <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>> wrote: Just to answer some of your questions: On Jan 3, 2014, at 8:18 AM, Uwe Schindler <[email protected]<mailto:[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]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]>
