Subversion Project Migrates To Git

← Back to Stories (view on slashdot.org)

Subversion Project Migrates To Git

Posted by timothy on Tuesday April 1, 2014 @05:02AM from the seasonal-variety dept.

New submitter gitficionado (3600283) writes "The Apache Subversion project has begun migrating its source code from the ASF Subversion repo to git. Last week, the Subversion PMC (project management committee) voted to migrate, and the migration has already begun. Although there was strong opposition to the move from the older and more conservative SVN devs, and reportedly a lot of grumbling and ranting when the vote was tallied, a member of the PMC (who asked to remain anonymous) told the author that 'this [migration] will finally let us get rid of the current broken design to a decentralized source control model [and we'll get] merge and rename done right after all this time.'" Source for the new git backend.

117 of 162 comments (clear)

Min score:

Reason:

Sort:

April Fool's! by barlevg · 2014-04-01 05:04 · Score: 5, Funny

In related news, Microsoft will be using Gmail for their company email, and Apple will be replacing their workstations with Linux boxes.
1. Re:April Fool's! by lgw · 2014-04-01 05:47 · Score: 3, Informative
  
  Apple seriously uses Outlook Exchange for their mail servers, though.
  [Archer]You can just say "Exchange"[/Archer]
  And the iCloud is stored on Azure. The whole "Onion or Reality" test can be difficult in tech these days.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
2. Re:April Fool's! by Darinbob · 2014-04-01 06:59 · Score: 1
  
  I actually believed the headline until I read more of the summary. Ya it sounds totally crazy and stupid, yet that's the sort of idiocy that happens every day in computing.
3. Re:April Fool's! by drolli · 2014-04-01 08:02 · Score: 2
  
  I am a happy user of both. Subversion and Git have different fields of application, and that is good.
4. Re:April Fool's! by tlhIngan · 2014-04-01 08:21 · Score: 2, Insightful
  
  Apple seriously uses Outlook Exchange for their mail servers, though.
  [Archer]You can just say "Exchange"[/Archer]
  And the iCloud is stored on Azure. The whole "Onion or Reality" test can be difficult in tech these days.
  Well, given Apple's not exactly a well known entity in the MTA market, or in the cloud computing market, I don't see the big deal that they're using Exchange and Azure.
  They're both good products run by people who know what they're doing. At least, know more than Apple on those topics. And neither is something Apple wants to get in and support directly. I mean, yes they could do it, but I suspect that Microsoft simply does it better and probably more securely than Apple on their own.
5. Re:April Fool's! by lgw · 2014-04-01 08:51 · Score: 1
  
  There's also a lot to be said for sticking to what you can be great at, and leaving the rest to someone else. But it's anathema to "Apple fans" who are really "Microsoft anti-fans", who show up a lot on Slashdot.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
6. Re:April Fool's! by TangoMargarine · 2014-04-01 09:46 · Score: 1
  
  I actually believed the headline until I read more of the summary.
  And...? The summary and headline are in agreement. (There was a Soylent article too that looked like a blatant April Fool's Day joke but actually wasn't.)
  Granted, in the months leading up to the Slashcott, I actively assumed that every summary was blatantly lying to me or at least attempting to mischaracterize the situation...so read the comments until you find the one guy who knows what's actually going on...but the quality seems to have spiked recently. (Gee, isn't that a remarkable coincidence?)
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
7. Re:April Fool's! by TangoMargarine · 2014-04-01 09:59 · Score: 1
  
  Tony Stevenson made changes - Today 16:51
  Comment [ Pfft! Happy April's fool!
  For immediate release: Apache Subversion votes to rename itself Apache Irony, creates a black hole and disappears. ]
  Hmm. Buried in a separate tab from the huge page of comments of everybody taking it seriously.
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
8. Re:April Fool's! by Anonymous Coward · 2014-04-01 10:44 · Score: 2, Funny
  
  Troll time:
  So Apple fans are the 'Microsoft anti-fans' who don't understand linux...
April Fools! by AnontheDestroyer · 2014-04-01 05:07 · Score: 1, Troll

Subversion is really a joke. Gotcha!
1. Re:April Fools! by Anonymous Coward · 2014-04-01 05:31 · Score: 5, Insightful
  
  I've never understood the popularity of git. It may be useful for open source by supporting distributed development but it seems far less useful for a traditional corporate environment. SVN just makes far more sense to me in terms of command structure. If I wanted a DVCS I would probably go with Mercurial. Git is just awful.
2. Re:April Fools! by EvanED · 2014-04-01 05:45 · Score: 1
  
  I haven't used Mercurial enough to compare it meaningfully to Git, but even in a traditional corporate environment I'd take either over Subversion in a heartbeat. (In my little use of Hg I haven't liked it as much as Git, particularly TortoiseHg vs TortoiseGit, but I'm sure most of that has to do with familiarity.)
  The "D" part is still occasionally useful for things like working on an airplane or something, and it's nice to commit half-baked changes without polluting a global branch namespace and worrying about policies and stuff. I recently embarked on a couple-day change to one part of our code, and made just a local Git repo so I could play around with my changes without having to go to the ground-truth repository (SVN). (I've thought about working with git-svn and haven't tried it, but I think our repository structure wouldn't work very well with that.) Once I got things done over the course of a dozen or so Git commits, I could clean them up and for submission to the actual repo.
  In addition, both Git and Hg offer just a bunch of really nice features that have nothing to do with their distributed-ness; in particular, I love Git's index and add --patch/--interactive, to the point of which I actually wrote a script that tries to duplicate the add --patch with Subversion. But in part because Git was built around that idea, my script doesn't and more or less can't work as well as Git.
  
  Git is just awful.
  I have two or so big usability complaints about git, but in general I actually like it quite a bit. (And I don't say that about much software...) My general impression is that it has a sharper learning curve than Hg at the front but that it rewards that by being able to do some really nice things.
3. Re:April Fools! by lgw · 2014-04-01 05:51 · Score: 5, Insightful
  
  Git solves one incredibly important problem: it stops "Linux kernel commit privileges" from being a constant political battle on Linus's part. By making "official builds" pull based, instead of push based, the whole question of "who gets to commit" vanishes and Linus has full control by change, instead of by author - a far less emotional and political thing.
  So Git is overwhelmingly better if you're Linus Torvalds. And, hey, that's how open source gets written. If anyone else finds it useful for anything, that's just gravy.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
4. Re:April Fools! by Anonymous Coward · 2014-04-01 05:55 · Score: 2, Insightful
  
  I, too, was happy with Mercurial and wonder why Git is so popular. I find Git inconsistent and confusing, and it seems to implement the idiom of most-surprise: that is, whatever a command does by default is probably not what you wanted, and the way to do anything you might consider simple is complicated.
  
  The only reason I can come up with Gits popularity over Mercurial is that Linus wrote it. That's about it.
5. Re:April Fools! by Wootery · 2014-04-01 05:55 · Score: 4, Informative
  
  Disagree. I've seen Git used to good effect in a traditional corporate environment. The ability to quickly make your own branches is useful, even if there's just an SVN-style single trunk of proper code-reviewed commits. (Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)
  The ability to make team-specific branches is also valuable: a team can work toward a feature using a team-local branch, and only once they're done, rebase and push their work into the the trunk. (Yes, rebasing might take work, but it can be beneficial to just 'do this all in one go' when the team is done implementing the feature, as it means the ground isn't moving beneath their feet during 'proper' development time.)
  Git does everything SVN does, and an awful lot more - personally I'd only even consider going with SVN if there were a developer team who only knew SVN and didn't have time to learn Git.
  Don't know much about Mercurial, but I'm sure it's good too.
6. Re:April Fools! by EvanED · 2014-04-01 06:05 · Score: 3, Informative
  
  The only reason I can come up with Gits popularity over Mercurial is that Linus wrote it.
  You may be partly right. But I think a lot of it is that for a while, Git was a lot more "powerful" -- it supported some very useful modes of operation that Hg either didn't have or wasn't very good at. So while Git was confusing, once you learned the model and commands it did a really good job of rewarding you for it.
  This gap has closed substantially, particularly on the Hg side -- a lot of the "missing features" have been implemented either in core Hg or in extensions. At the same time, Git has been doing a reasonably good job at improving usability, though some issues remain.
  Then again, I'm a Git user who hasn't worked much with Hg, so take what I said with a strong dose of salt.
7. Re:April Fools! by Anonymous Coward · 2014-04-01 06:24 · Score: 1
  
  Uh, while it might be better in some cases, git will be vastly worse bandwidth-wise in some case, like getting a fresh checkout.
  Git is designed to always make a full copy of the complete history, the sparse/minimal checkout feature doesn't really work well (and usually just means you end up with the huge data transfer when you try to update, and in addition a huge mess and no history even when you are online).
  It's also close to fatal when you want (need?) to store large binaries in version control.
  So if you want "works for all projects", git is a huge step further from that than SVN.
8. Re:April Fools! by Anonymous Coward · 2014-04-01 06:25 · Score: 5, Insightful
  
  discovering git- but I'm actually curious what is awful about it?
  Linus's decision to screw over everyone that has ever used SCM by refusing to use normal terms is the most awful part. Instead, as he admitted, he just randomly assigned words to concepts. For example, he randomly picked the word checkout to mean revert. Ditto using the word reset to mean unstage. "git pull" refuses to update the source like a normal system would. Instead you have to do the "git stash; git stash apply stash@{0}" dance. And stash/unstash is not standard in the first place since Bazaar, Mercurial, Perforce, TFS, etc. use the terms shelve/unshelve. The word clone is another odd one. On the topic, the decision to not allow clone to checkout a subset of a repository like is often done with Subversion is a curious one. Another not understanding users is the decision to disallow checking out only the current version of all files rather than every single version of every single file.
  His decision to add so many dependencies to make it difficult to run Git on anything but Linux is another awful decision. The msysgit directory on Windows contains 14,589 files in 622Mbytes. A simple SCM should not require over 14,000 files! Finally, the decision to make the server side weak, especially wrt security, is also awful. As Linus admitted, his belief is that you should give everyone full access to everything. That obviously doesn't scale.
  Of course, everything below the covers with Git is spectacular. We use it for a 500k file repo, and have had no problems after nine months. Before converting, our developers were wasting hours a week running "svn cleanup." Our artists are converting to it from Perforce, and other than the stupid decisions on command names and decision to not allow checking out just HEAD or a subset of the repo, they've had no problems despite working with hundreds of multigigabyte files.
9. Re:April Fools! by sam0ht · 2014-04-01 06:27 · Score: 3, Insightful
  
  I use Git to good effect in a fairly traditional corporate environment. We're much better off since switching over from SVN.
  Never mind the 'distributed' part - the big challenge for source control in a traditional setup is when two people have both modified different parts of the same files, and the second guy goes to check in. Git is much better at handling conflicts than SVN is - conflicts that would cause real pain in SVN often merge smoothly in Git.
  It's also much better at handling branches, e.g. a release branch. Remember 'tree conflicts' in SVN? Not an issue in Git.
  Git is a better SVN, as well as being a distributed source control system.
10. Re:April Fools! by EvanED · 2014-04-01 06:42 · Score: 5, Insightful
  
  For example, he randomly picked the word checkout to mean revert
  That choice actually makes sense from the Git model. A Subversion person would ask why there is one command for three+ different things (svn revert, svn switch, svn up -r### are all done using git checkout). But if you turn your head around and look at it from a different perspective, all three of those are doing the same thing: copying something from the repository store to the working copy. From the Git perspective, Subversion is giving three different names to the same thing, each of which only works some of the time.
  I don't want to argue Git is right, just that if it has a fault here, Git's is that its terms are at a lower level than users usually think and not that it's inconsistent on this point.
  
  Ditto using the word reset to mean unstage.
  
  Oh boy. The whole index is a mess of inconsistent terminology. You stage something to the index using git add, unless you're using git add --interactive in which case that process is called updating. And of course you see what the changes are in your index by using git diff --cached. Wut?
  (Yes, I know, git diff --staged is now an alias for the last. Good, now all they have to do is deal with the three other synonyms for the same thing.)
  
  "git pull" refuses to update the source like a normal system would. Instead you have to do the "git stash; git stash apply stash@{0}" dance
  Here I also defend git, because I think this is a significant selling point. One major advantage that Git has is that once something is actually added to the store, it's nearly impossible to accidentally lose information. git stash adds the state to the store.
  Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.
  Compare to git. You have to run stash before pulling (merging/rebasing technically of course), so now the state of the working copy right before the pull is in the store. You then stash apply. You get the conflicts, say "I give up for now". Now all you have to do is figure out what the SHA1 of the copy that was in the stash is. Might have to do some reflog digging, but it is not only possible but actually pretty easy if you know about the reflog.
11. Re:April Fools! by jythie · 2014-04-01 06:54 · Score: 1
  
  Let the religious wars begin!
  
  In all seriousness, SVN and git have strengths and weaknesses depending on the project and its needs, though usually the biggest one is going to be 'what do your developers already know'. Git was built to support distributed projects and is really strong in those cases, SVN was built to be highly centralized and administered and tends to be stronger when that is the plan. For most small projects they are functionally equivalent, well, outside git's 'local repo' system, which ads a bit of unnecessary complexity in simple cases.
12. Re:April Fools! by jythie · 2014-04-01 07:02 · Score: 4, Insightful
  
  I can answer at least some of that. I am a long time SVN user who is now using git, and while I would not call it 'awful', I do find the 'local repo' structure to be frustrating and needlessly complex, and generally comes across as over-engineered. Kinda like ClearCase, it can handle more complex situations then SVN, but that additional support causes complexity to seep into simpler cases.
  
  I have also had difficulties with the client that I never had under SVN, with pretty much no luck with it working 'out of the box' on any of the machines I use. So in each case I have had to install the full development chain in order to rebuild the client because the one already installed is incompatible. SVN, for all its dullness, tends to be pretty conservative about changes and generally the distro installed one works.
  
  However, for my use case, the community aspect (i.e. the finding projects) and traveling are not important, so those advantages do not get me much.
13. Re:April Fools! by jythie · 2014-04-01 07:06 · Score: 4, Informative
  
  That strikes me as an issue with your server, not SVN. I have worked on projects where SVN handled tens of thousands of files, dozens of branches, thousands of tags, etc, and found syncing to be pretty reasonable. In fact we switched over to SVN in part because Clear Case was having trouble keeping up with the volume.
14. Re:April Fools! by jythie · 2014-04-01 07:10 · Score: 2
  
  I keep hearing this, but so far I have encountered about the same amount of branch conflict in git as I have with SVN, just with the added complexity of local repo vs checkout. But I have not found any magical advantage in its ability to merge a file that has been changed by two different developers.
  
  Branching does not seem any harder or easier.
15. Re:April Fools! by Dynedain · 2014-04-01 07:47 · Score: 1
  
  As someone who uses SVN, Git, and Hg in a corporate environment (plus we have the MS solution around here somewhere but I don't touch it), I love using Git or Hg. I've setup some pretty complex project structures and branch behaviors that take advantage of how the different systems work.
  That said, I haven't seen anything that would distinguish Git over Hg (or the opposite) when used in a corporate setting. If you like Hg over SVN, then you'll like Git as well because it behaves pretty much the same way, just different syntax for the commands.
  Plus, something like SourceTree goes a long way to minimizing the differences between repository types.
  
  --
  I'm out of my mind right now, but feel free to leave a message.....
16. Re:April Fools! by Dynedain · 2014-04-01 07:49 · Score: 1
  
  The difference I've seen is that Git doesn't fail miserably and corrupt your local repository tracking info the way SVN tends to.
  
  --
  I'm out of my mind right now, but feel free to leave a message.....
17. Re:April Fools! by Anonymous Coward · 2014-04-01 07:51 · Score: 1
  
  You are almost certainly using git wrong. The benefit comes from the ability to keep feeding out changes to the main branch much faster. You don't magically find merges of to the same place easier but you find that they happen much less often because your changes are already out there.
  The fundamental philosophy here is merge early, merge often which is much better supported in git than any other tool.
18. Re:April Fools! by JesseMcDonald · 2014-04-01 08:00 · Score: 2
  
  You then stash apply. You get the conflicts, say "I give up for now". Now all you have to do is figure out what the SHA1 of the copy that was in the stash is. Might have to do some reflog digging, but it is not only possible but actually pretty easy if you know about the reflog.
  You don't even need to bother finding the SHA1 or searching the reflog. stash apply doesn't get rid of the stash, so it's still right there as stash@{0}. You can also find it with stash list. stash pop would normally get rid of the stash after applying it, but even there the original stash is preserved if there were any merge conflicts.
  
  --
  "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
19. Re:April Fools! by Zebedeu · 2014-04-01 08:45 · Score: 1
  
  I've used git in a traditional corporate environment, and done right, it can be a lot more powerful than SVN.
  "Done right" means you have someone dedicated to the role of "git master" who merges the team's commits into the master repository.
  This is what Linus does, and it works to great effect. The great advantage is that individuals and teams can very easily work on their private branches before merging into mainline.
  The second method is to set up a server which runs automatic tests on all commits and guarantees at least that the git history remains clean and contributions do not break the build.
  From my experience, people tend to resist git because the concepts are a bit difficult to get in, especially when coming from other SCMs. It doesn't help that git uses many of the same nomenclature as other systems for slightly different operations.
  However once the concept starts to settle in, git is actually quite simple and its use becomes second nature.
  I don't know mercurial that well. From my experiments and what I've read on the Internet, it's essentially the same as git. Some people have strong opinions (like you seem to have) towards one or the other, but I've found that it's mostly down to small differences.
  However, to me it makes no sense to use mercurial when almost all open-source projects already use git. Using mercurial only means you have to deal with two SCMs rather than one.
20. Re:April Fools! by Anrego · 2014-04-01 09:15 · Score: 3, Insightful
  
  Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.
  Totally this. As a subversion fanboy who has yet to jump on the git train, I see this as one of the major oversights in svn.
  Personally I'm a fan of one developer, one branch. It's a bit of overhead for sure, but everyone having their own branch where they can check in their changes before merging in changes from the main branch is a nice safety net. You just have to learn to reintegrate to the feature branch often to avoid silo effect.
21. Re:April Fools! by gatkinso · 2014-04-01 09:18 · Score: 1
  
  I use both git and svn heavily. They both have strengths and shortcomings. Git has far stronger merge and is very useful if you are a dev who has to be disconnected for any period of time. Svn is far easier to maintain from an admin point of view and is far simpler.
  Choose your poison - both seem to work fine.
  
  --
  I am very small, utmostly microscopic.
22. Re:April Fools! by Anrego · 2014-04-01 09:24 · Score: 1
  
  That sounds like a configuration problem. SVN is seriously one of the better ones in this regard (try ClearCase if you want to see what being limited by bandwidth feels like).
  If your workspace itself was on an NFS share, this might be part of it. By default svn creates a tonne of tiny files, which can take forever over NFS due to overhead.
23. Re:April Fools! by gatkinso · 2014-04-01 09:28 · Score: 1
  
  Both git and svn have the same performance hit for an initial checkout/clone. Ditto for a large team pushing changes when you update/pull. Git seems to "push" much faster than svn "commit".
  Git "commit" is nothing of the sort it is basically a tagging mechanism - which is also awesome and its major strength IMO - maybe a local commit is a better description of it, but I digress. Git with its much more powerful merge functionality is also awesome.... right up to the point that something gets fucked up. Then... well... you will spend a few hours getting straightened out where with svn the fix usually takes 5 or so minutes.
  When things are working well they seem to be about the same, honestly.
  
  --
  I am very small, utmostly microscopic.
24. Re:April Fools! by gatkinso · 2014-04-01 09:31 · Score: 1
  
  Ha! I see just the opposite: git fucking up miserably to the point where a dev has to locally pull their changes, reclone, and overlay the changes... where svn I have never seen that.
  Of course when the network goes down, so does svn.... choose your poison.
  
  --
  I am very small, utmostly microscopic.
25. Re:April Fools! by gatkinso · 2014-04-01 09:37 · Score: 1
  
  I thought svn was developed to fix the problems with cvs... which it has mostly accomplished.
  
  --
  I am very small, utmostly microscopic.
26. Re:April Fools! by Anrego · 2014-04-01 10:07 · Score: 1
  
  "Done right" means you have someone dedicated to the role of "git master" who merges the team's commits into the master repository.
  I would argue that this is a good practice with svn as well. You can have a free-for-all dev branch, or even a whole dev trunk, but having someone at the top (some kind of coordinator.. of builds..) makes a lot of sense.
  
  The second method is to set up a server which runs automatic tests on all commits and guarantees at least that the git history remains clean and contributions do not break the build.
  Again, this is in no way git specific. Commit hooks are well supported in svn, and tools like hudson and jenkins handle continuous integration with svn just as well as with git.
  Personally I'm an svn fan, but I think with both it comes down to using it appropriately.
  My main argument for svn in the corporate argument over git is that svn is more or less designed around centralized approach whereas with git if you want that (which in a lot of corporate cases you do) it has to be enforced procedurally, but both are perfectly doable.
27. Re:April Fools! by madprof · 2014-04-01 10:12 · Score: 1
  
  As someone who moved from SVN to HG and now from HG to Git for the same codebase, it's quite a natural step.
  The HG to Git move was because of branching behaviour, which we preferred in Git, plus the ability to use Stash.
  Git has its quirks but I'm having zero problems moving.
  I'd always always go with HG over SVN, any day of the week and twice on a Sunday.
28. Re:April Fools! by madprof · 2014-04-01 10:16 · Score: 1
  
  Maybe you want HG instead of Git?
29. Re:April Fools! by madprof · 2014-04-01 10:19 · Score: 1
  
  My team wanted to use bookmarks instead of HG branches. Sadly our version of Rhodecode did not support them. So we've moved the team to Git and it's actually turning out OK. Yes, different and I miss the simplicity of HG and the lovely logical nature of it. Git feels more inconsistent. But it's doing the job.
30. Re:April Fools! by Zebedeu · 2014-04-01 10:26 · Score: 1
  
  Again, this is in no way git specific. Commit hooks are well supported in svn, and tools like hudson and jenkins handle continuous integration with svn just as well as with git.
  It wasn't my intention to imply that these techniques are unique to git.
  The original poster mentioned liking SVN better because of the command structure, and I was pointing out that that's possible as well with git. My point was that for certain corporate environments (or large teams in general) git can be made more centralized without losing many of its benefits.
31. Re:April Fools! by EvanED · 2014-04-01 10:30 · Score: 1
  
  stash pop would normally get rid of the stash after applying it, but even there the original stash is preserved if there were any merge conflicts.
  I didn't know/forgot about that (in addition to confusing stash pop, which is what I virtually always use, and stash apply). Though I will point out that there can be conflicts other than textual ones.
32. Re:April Fools! by Dynedain · 2014-04-01 10:57 · Score: 1
  
  Try deleting a local folder without deleting the subfolders (and committing) first. Instant corruption in SVN.
  Move a folder (with subfolders). Instant corruption in SVN.
  Since Git (and Hg) do a diff of the entire checkout rather than maintaining meta deta per directory, it's a lot easier to do refactoring without screwing things up.
  
  --
  I'm out of my mind right now, but feel free to leave a message.....
33. Re:April Fools! by hibiki_r · 2014-04-01 11:33 · Score: 1
  
  The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git. There's also how git has this crazy staging area that is the cause of 90% of bad commits to our git repos. Commits that are missing a file, or have an extra file, are the bane of SVN and Git repos. In hg, the expected behavior is commit everything that is not in a patch. More discipline required, less chances of shooting yourself in the foot.
  As far as the interface goes, other than the well known stuff, there's the fact that default behaviors seem to be all built around pulls, not pushes, so if your typical corporate environment, where pulls are often nonsense, people get very confused when 'natural' behaviors tell them that the files that changed from a merge are the files from the upstream, that they did not edit, and things like that. To minimize it, I keep telling people to avoid git pull like the plague, and instead use git fetch, followed by git rebase as the baseline case.
  Either way, both are pretty useful, and beat SVN in almost all use cases. I just think that it's easier to teach people hg than telling people to learn a bunch about git internals before they can contribute properly.
34. Re:April Fools! by gatkinso · 2014-04-01 11:42 · Score: 1
  
  It is true, you must use "svn mv" as opposed to "mv."
  The horror.
  
  --
  I am very small, utmostly microscopic.
35. Re:April Fools! by Dynedain · 2014-04-01 12:27 · Score: 1
  
  Yeah, try teaching that to people who's job is to do front-end development or other tasks where the OS GUI is the right tool, not the command line.
  
  --
  I'm out of my mind right now, but feel free to leave a message.....
36. Re:April Fools! by Anonymous Coward · 2014-04-01 12:31 · Score: 1
  
  And "git status" doesn't show the status! Instead of doing something reasonable like:
  {
  "branch" : "testing-maven-git-plugin",
  "describe" : "v2.1.0-2-g2346463",
  "commitTime" : "06.01.1970 @ 16:16:26 CET",
  "commitId" : "787e39f61f99110e74deed68ab9093088d64b969",
  "commitIdAbbrev" : "787e39f",
  "commitUserName" : "Konrad Malawski",
  "commitUserEmail" : "konrad.malawski@java.pl",
  "commitMessageFull" : "releasing my fun plugin :-)
  + fixed some typos
  + cleaned up directory structure
  + added license etc",
  "commitMessageShort" : "releasing my fun plugin :-)",
  "buildTime" : "06.01.1970 @ 16:17:53 CET",
  "buildUserName" : "Konrad Malawski",
  "buildUserEmail" : "konrad.malawski@java.pl"
  }
  Linus refused to show any of the above information. The tool used to generate the above required more than 350 revisions with contributions from 22 contributors. When it takes a monumental group effort just to get the status, you know Linus is intentionally fucking us over.
37. Re:April Fools! by aztracker1 · 2014-04-01 13:16 · Score: 1
  
  I've seen a few internal git based projects go a step farther.. feature branch from master, with a per-task branch that's short lived.. branch from feature branch, work on your changes, usually committing local, and/or pushing to internal repo. When ready to apply to feature branch, (optionally rebase) and do a pull request... at the pull request comes peer review (a couple +1's) and you merge up... regular merges in from master, and push to master == CD release.
  
  For smaller modules, the branch is typically PR'd straight to master for that project (with review). It's worked very well, and I have to say that working with multiple local and remote branches in git has been quite a bit nicer than with any other source control I've used, including SVN (of course getting used to git took some time, and git extensions helped with that learning curve).
  
  --
  Michael J. Ryan - tracker1.info
38. Re:April Fools! by aztracker1 · 2014-04-01 13:17 · Score: 1
  
  Also, new projects have required 100% code coverage for CI/CD.
  
  --
  Michael J. Ryan - tracker1.info
39. Re:April Fools! by complete+loony · 2014-04-01 13:31 · Score: 1
  
  > git stash branch []
  You're welcome.
  
  --
  09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
40. Re:April Fools! by EvanED · 2014-04-01 15:04 · Score: 1
  
  cat .git/`cat .git/HEAD | cut -f 2 -d " "`
  Or, you know, git rev-parse HEAD. Though I'll admit that doesn't address your "I have to run something" objection, at least it's a far cleaner command with less shell and quoting dependencies and issues.
41. Re:April Fools! by tapspace · 2014-04-01 15:09 · Score: 1
  To counter your terminology argument, often in technology, backwards compatible is preferable to a redesign. Git redesigned the version control interface and that seems unnecessary. Only the most stubborn git users would say git has a better interface than subversion, which has an excellent one.
  If subversion took the git lessons and added them in, it would be so much better than git ever could be. The stellar parts of git could be added into subversion more cleanly than vice versa.
  To make me never think of git again, subversion needs:
  * distributed and offline operation (duh)
  * the stash/shelve feature (and might as well add in auto-stashing when an update is performed on a repo with changes)
  * staging for all commits (no auto-staging of known files anymore)
  * the auto-merging excellence of git
  For git to be better than subversion with those features, it needs a complete redesign.
42. Re:April Fools! by EvanED · 2014-04-01 15:12 · Score: 1
  
  The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git.
  As a git user, I've done a bit of reading about Hg branches. The difference seems to be pretty much "the name of the branch is stored permanently with the commit." Is that it, or is there more?
  (The "is that it" is meant to be a question, not a dismissive value judgement.)
  
  To minimize it, I keep telling people to avoid git pull like the plague, and instead use git fetch, followed by git rebase as the baseline case.
  You probably know this, but you can git pull --rebase and still do it in one step. You could also add a config alias (e.g. git get or something) for that; heck, I'd bet $20 you can make --rebase the default for just git pull.
43. Re:April Fools! by EvanED · 2014-04-01 15:47 · Score: 1
  
  To counter your terminology argument, often in technology, backwards compatible is preferable to a redesign.
  I agree... but at the same time, I think the opposite is true too: it's really easy to cling to backwards compatible way too much. That's the source of most of Windows's biggest problems, for example.
  
  Only the most stubborn git users would say git has a better interface than subversion, which has an excellent one.
  That depends on what you consider part of the interface. For example, if you say that the index and git add --interactive (primarily --patch, but the "nice" UI to the index is really good too apart from inventing new terms for the hell of it) is part of "the interface", that alone is useful enough to make up for all of git's other UI deficiencies to my mind. If you demanded that I choose between Subversion as it is today and a modified version of Subversion that had a UI as confusing to learn as Gits but it had the index and interactive adding, I'd pick the latter.
  I know some people dislike the index, but to me its one of the star attractions of git. It's not so useful most of the time, but boy, when it is useful it's amazing.
  
  To make me never think of git again, subversion needs:
  To that list I would add rebasing support, both branch-style rebasing (as an alternative to merging) as well as rebase --interactive-style rebasing (for cleaning up a WIP to make it presentable).
  
  For git to be better than subversion with those features, it needs a complete redesign.
  That... I think depends on whether you prefer front end or back end design. :-) I suspect that either supporting decent offline operation or awesome git-style merging would be a substantial undertaking, while at the same time I suspect you could graft a Mercurial-style UI (which most people say is also really good) onto the Git back end without really changing the back end.
44. Re:April Fools! by defcon-11 · 2014-04-01 16:07 · Score: 1
  
  As someone who uses git in a traditional corporate environment... I would never go back to SVN. Yes, there is a learning curve, but it's so worth it. Even if you don't use any of git's features, the speed increase alone is worth the change.
45. Re:April Fools! by defcon-11 · 2014-04-01 16:09 · Score: 1
  
  git is massively faster. Checkouts that take 2 hours with SVN take 10 minutes with git.
46. Re:April Fools! by defcon-11 · 2014-04-01 16:11 · Score: 1
  
  Pull requests are also massively useful for a corporate environment. They allow you to easily integrate code changes from teams (or contractors) that don't have write access to the origin repo.
47. Re:April Fools! by CBravo · 2014-04-01 17:57 · Score: 1
  
  This... I don't think about checkout-time any more.
  
  --
  nosig today
48. Re:April Fools! by jeremyp · 2014-04-01 23:28 · Score: 1
  
  I keep hearing the "git is better than svn at handling conflicts" meme, but of course neither handles conflicts at all. A conflict is a file where the tool can't figure out how to merge two versions and therefore has to offload it to a human.
  I've also heard on the Internet that git is better than svn at doing merges, but everybody I know who has used both git and svn in real production environments says the opposite.
  In my company we use svn. I did consider moving us to git or - more likely - Mercurial (the hg user interface is more similar to svn so that would make the transition easier), but I found out that it is really easy to make a directory both an svn working copy and a git/hg repository just by using setting ignore properties so I can do local commits and still have a central svn repo.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
49. Re:April Fools! by orasio · 2014-04-02 00:36 · Score: 1
  
  I've never understood the popularity of git. It may be useful for open source by supporting distributed development but it seems far less useful for a traditional corporate environment. SVN just makes far more sense to me in terms of command structure. If I wanted a DVCS I would probably go with Mercurial. Git is just awful.
  I am working in a traditional corporate environment right now.
  SVN sorks great, even when you use branchs. The problem is that merging is just not worth it.
  Right now, we use SVN, and the equivalent of a pull request in github or similar, is a manual process, with several pain points, that works against the grain of development. We need to have separate code reviews for commits, and then count on developers merging code that is accepted.
  We also have problems creating branches, destroying them.
  I think SVN was OK for the enterprise when the enterprise didn't need all the pretty things modern development processes bring. Right now, they want to deploy every few days, automated testing, decentralized development, and SVN doesn't fit well.
  About Git being awful, that might be true, even though I doon't see it. There might be a need for better tools, but the command line client is good, specially compared to the svn client. In any case, it's the dominant player in DVCS, it's the safest investment.
50. Re:April Fools! by tibit · 2014-04-02 03:23 · Score: 1
  
  First of all, I don't think that it's sane to use svn or git without a graphical front-end. That said, I find that git-svn works way better than svn itself. Subversion merging starts looking downright silly once you see how git does it. And I was one of those who actually argued that svn's merging is "good enough". Eventually I convinced myself, through experimentation, that it's nowhere near good enough. To me, subversion is a way of centrally storing git repos without having to configure server-side git, and also a way of doing partial checkouts when I don't need the whole thing.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
51. Re:April Fools! by tibit · 2014-04-02 03:32 · Score: 1
  
  The shallow clone have fixed this, mostly. So far, I find no downsides to shallow clones, other than the loss of history.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
52. Re:April Fools! by tibit · 2014-04-02 03:36 · Score: 1
  
  The initial checkout from svn doesn't clone the entire history. With git, a shallow clone (--depth 1) doesn't either. Git's smart http transport is bound to be faster than svn, since compression can be applied across multiple files, and if there are similar files in the repository, their common chunks will always be factored out by design. With svn, it's not guaranteed and depends on how file copies/moves were managed.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
53. Re:April Fools! by aled · 2014-04-02 07:38 · Score: 1
  
  yes, most people comparing subversion with hit should check instead mercurial.
  Mercurial is much easier to understand than git and has a nice portable GUI.
  I'm not saying got is bad, just it appear to work at a lower level than other SCMs.
  
  --
  
  "I think this line is mostly filler"
54. Re:April Fools! by Mortimer82 · 2014-04-02 08:41 · Score: 1
  
  Our project's team decided to move from SVN to Git a few months back. We develop for .NET and were all used to working with TortoiseSVN with code being managed on a server which could control access to different repositories.
  
  We had one guy who recently joined our team who knew Git and felt it was worth taking the plunge and moving to it, acknowledging that we would initially be frustrated at having to learn a new tool.
  We use TortoiseGit along with Gitblit to host the repositories and at this point I have to say I am super happy we made the move. Learning something new is always a little painful, but it was well worth it in this case. If you're used to TortoiseSVN, then TortoiseGit really helps and I personally have not had to use a single Git command.
  
  Git empowers you more as a developer because while SVN essentially forces its changes onto you as you fetch latest, with Git, you get much greater control in how and when you merge your changes with the repository. If you are uneasy about a merge, you can make a branch in just a few seconds and test it there first. The nicest though is how you can commit locally without having to push your changes to other users, this is especially useful if you are doing a refactor and want the ability to create rollback points every hour, but don't want other developers getting your not yet complete work. You create a branch locally, commit every 30 minutes or hour, then when the whole task is completed, you can merge your commits into one (if you want), then push to the central repository for the rest of the team.
  
  If your refactor took a week, you can avoid the merge pain of other developers work by regularly pulling their changes into your perhaps every day or even every hour, and everytime you want to merge, you can roll it back if something turns our badly.
  
  The thing to understand about Git is that there is no "central" repository authority like with SVN, instead everyone has there own repository and Git provides a nice way to selectively pull and push changes between different repositories in a way that you have much greater control over. In our corporate environment, we do use a central repository as that's where the backups happen and it's also much easier than trying to sync with peers. The end result is a process that in practice can work identically to SVN, but also gives developers greater power on their own computers, if they want it.
  
  It really does empower you, but as with anything truly worth doing, there is effort required and you must be prepared to invest. I also recommended that at least one person on your team is already familiar with Git as an in person explanation to any issue you have is much faster than trying to research it online.
55. Re:April Fools! by gatkinso · 2014-04-02 11:11 · Score: 1
  
  TortoiseSVN (for example), right click drag, drop, select SVN Move versioned files here. That was exhausting.
  So much worse than when, say SmartGit, gets stuck in an endless rebaseing state thereby complete fsking your local repo along with any stashes you may have.
  But this is what you get for replying on a GUI.
  However most GUI devs I work with (myself included) operate from the command line.
  
  --
  I am very small, utmostly microscopic.
56. Re:April Fools! by gatkinso · 2014-04-02 11:16 · Score: 1
  
  So an svn "checkout" doesn't "clone"... harharhar, but a git "checkout" "reverts"... terrible humor. Sorry.
  Well, they both can take a long ass time for an initial checkout/clone was all I was trying to say, I have never raced identical repositories with identical histories, but that would be mildly interesting.
  
  --
  I am very small, utmostly microscopic.
57. Re:April Fools! by gatkinso · 2014-04-02 11:17 · Score: 1
  
  Replying on a GUI. Jesus wept.
  
  --
  I am very small, utmostly microscopic.
58. Re:April Fools! by Dynedain · 2014-04-02 12:03 · Score: 1
  
  Or you know, just drag and drop using my existing filesystem viewer and not need a special client to do something simple like renaming a folder.
  Nothing like reinventing the wheel!
  
  --
  I'm out of my mind right now, but feel free to leave a message.....
Ahahaha by Anonymous Coward · 2014-04-01 05:08 · Score: 2, Funny

See, what they've done here is concocted and published an implausible story (or in this case, tracking issue) that is designed to misdirect, nay, fool people into believing it is real. These jolly japesters have done this in the full knowledge that it will mislead people into believing it to be true, and they have chosen to do it today, on the very first day of April, as is customary in these matters.

Oh Apache and Slashdot, you are truly such ruse masters!

Seriously, April 1st is such a fucking bag of shit. Just fucking stop.
funny thing is by epiphani · 2014-04-01 05:09 · Score: 5, Insightful

This would probably be a good idea for the future of subversion.

--
.
1. Re:funny thing is by javilon · 2014-04-01 05:34 · Score: 2
  
  The day git implements subversion externals functionality so it is easy and risk free to update from and commit to external branches, I'll swich my team. Git modules functionality is close, but you can make a mess if you commit while having a module set up.
  
  --
  
  When his defense asked, "Which computer has Jon Johansen trespassed upon?" the answer was: "His own."
2. Re:funny thing is by stoploss · 2014-04-01 05:43 · Score: 1
  
  The day git implements subversion externals functionality so it is easy and risk free to update from and commit to external branches, I'll swich my team. Git modules functionality is close, but you can make a mess if you commit while having a module set up.
  Okay, I admit to not fully researching this, but because I have found svn externals useful in the past I thought I would inquire.
  Is this something repo (used in the Android Open Source Project, I call it "meta-git") could handle? From my experience with it, repo did many of the same things I would have used a svn external for. I admit the workflow for repo didn't seem very polished, but it did allow AOSP/CyanogenMod to meta-version various git repos for a build.
  Secondly, if you dont mind going into detail, what about git modules fell short? I would like to avoid pitfalls if possible.
Hmm by Anrego · 2014-04-01 05:10 · Score: 3, Informative

I've got to admit. The discussion going on in that ticket is pretty convincing, leading me to think that either:
a) legit
b) they sucked in a lot of their own people
c) really well thought out
I'm thinking (and hoping) b, with c as an unlikely but possible second.
1. Re:Hmm by mooingyak · 2014-04-01 05:26 · Score: 3, Insightful
  
  I've got to admit. The discussion going on in that ticket is pretty convincing, leading me to think that either:
  a) legit
  b) they sucked in a lot of their own people
  c) really well thought out
  I'm thinking (and hoping) b, with c as an unlikely but possible second.
  I'll confess I was fooled until I remember what day it is.
  
  --
  William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
2. Re:Hmm by EvanED · 2014-04-01 05:27 · Score: 1
  
  Yeah it got me for a good bit too. I was about to go post it to a chat in a making-fun-of-SVN-way at which point my brain was like "waaaaiiiit a minnnute..."
3. Re:Hmm by hagnat · 2014-04-01 05:35 · Score: 1
  
  unlike other years, this time slashdot has been low on april fool articles... so i was fooled as well XD
  
  --
  "life is a joke, and someone is laughing at me"
4. Re:Hmm by mooingyak · 2014-04-01 05:36 · Score: 3, Insightful
  
  Yeah. They're doing it right, finally.
  
  --
  William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
5. Re:Hmm by Bengie · 2014-04-01 05:42 · Score: 1
  
  Didn't fool me. Subversion wouldn't be eating their own dog-food and that would reduce their ability to properly expand it. What better testing of something than to actually use it day-to-day? This would akin to Linus using FreeBSD. He would start to lose touch.
6. Re:Hmm by Anrego · 2014-04-01 05:48 · Score: 1
  
  Honestly I think it's way more political than practical.
  Tools tend to have use cases that they are more suited to, while having use cases that their competition is more suited to. It's not unheard of to actually fall into your competitors use case while developing a product that competes in some other use case.
  Politics however will almost always force you to use your own products when it's an option, even if it's the worst option.
  Also I think if I use the words "use case" one more time today I fear I might actually grow a suit and tie.. I feel like I need a shower :(
7. Re:Hmm by Adrian+Harvey · 2014-04-01 06:13 · Score: 1
  
  A good example of this is Xero (accounting software company) who recently had to stop using their own software because they got too big - way, way too big - but they hung in for a long time because they didn't want to be a company that didn't use it's own software.
8. Re:Hmm by D.+Taylor · 2014-04-01 10:02 · Score: 1
  
  I'm voting for (a) with a helping of very-not-(c), given:
  - the comments on https://issues.apache.org/jira...
  - this story http://www.infoq.com/news/2014...
  - and this twitter conversation https://twitter.com/gstein/sta...
9. Re:Hmm by mooingyak · 2014-04-01 11:21 · Score: 1
  
  So this is either legit or an absolutely brilliantly executed joke.
  
  --
  William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
10. Re:Hmm by EvanED · 2014-04-01 15:54 · Score: 1
  
  Turns on it's the latter. From the issue thread:
  Resolving as "Not a problem". We sure as hell don't want to do this. :-)
  My major thanks to [~jfarrell] for the concept.
  And plenty of thanks to all of my co-conspirators on this issue. Yes.. even my antagonist [~jimjag] was in on the ruse :-) â¦ the Infra team handled this with perfect aplomb. And the Directors and Exec Officers came in with a perfect level of wrath. Our Subversion teammates showed a great sense of community and circling the wagonsâ¦ Thank you all for making this work!!!
11. Re:Hmm by Anrego · 2014-04-01 16:26 · Score: 1
  
  Legitimately impressed.
  They really sold it. I was convinced it was April fools earlier today, but as it exploded I actually started to buy it. This was very well executed.
  I can't help but wonder who wasn't in on it.
12. Re:Hmm by EvanED · 2014-04-01 16:49 · Score: 1
  
  Yeah, same here. Later in the day, after they carried it over to Twitter and stuff, I posted the "news" to a chat I was in saying basically "The SVN project is either (1) moving to git or (2) in the mist of an incredibly committed April Fool's day joke, and I honestly can't tell which it is."
  A lot of other sites had nice gags for the 1st, but this was the only one I saw that could legitimately earn the "April Fools" label.
April's Fools? by RockoW · 2014-04-01 05:11 · Score: 1

Really?
Re:April Fool's by Anrego · 2014-04-01 05:17 · Score: 1

It's kinda depressing that while just about everyone external got it immediately, people (high up people) seem to have bought into it wholesale (assuming they arn't all in on it).
The joke wasn't all that funny, but yeah, the internal reaction is.
(this is assuming it's not legit of course).
Not so much an April's Fool Day joke... by Anonymous Coward · 2014-04-01 05:20 · Score: 1

...as wishful thinking I am guessing.
Change by Yunzil · 2014-04-01 05:23 · Score: 4, Funny

'this [migration] will finally let us get rid of the current broken design... ... and replace it with a completely new broken design. (I hate git.)
1. Re:Change by caseih · 2014-04-01 06:06 · Score: 1
  
  What specifically don't you like about git? How is it a new broken design? Is it broken because it does not fit with your work flow or handle certain types of development? Curious to know.
2. Re:Change by Anonymous Coward · 2014-04-01 06:24 · Score: 1
  
  Apparently, it's designed so that every commit needs an e-mail address associated with it. This idiotic requirement may be appropriate for some forms of distributed development but to force this policy on all repositories is fascist nonsense.
  The symptom of the problem is that git refuses to rebase without an e-mail address set for the base commit. I had to create a new branch and cherry-pick each commit I wanted on top of it in the proper order.
  Of course this is not the worst design flaw. It's just the dumbest, with absolutely no reasonable justification possible.
3. Re:Change by Anonymous Coward · 2014-04-01 06:26 · Score: 1
  
  Broken in terms of usability mainly. It's like learning the many string and array functions of PHP, one even more powerful than the other. Some do the same thing in a different way but there is no cohesion in the way function names are formatted or what should be the order of arguments you pass in. This forces a user to memorize everything instead of using logic to figure out new possibilities or commands. I think this limits what a lot of users do with Git as a lot of users simply learn enough about Git to get them through the day when they work on their projects and don't feel any temptation to investigate any further.
4. Re:Change by ebno-10db · 2014-04-01 06:33 · Score: 2
  
  Not the OP here, but the main thing I dislike about git is the UI. The internals may be good, but the UI is a hack, complete with counter-intuitive alternate uses of commands via switches that seem like they should be used elsewhere, etc., etc., etc. Contrast that with Mercurial, which has a much more logical and consistent UI, and UI's are important (command line or of that other trendy variety). People who think the git UI is fine are probably just used to it. If you can get used to the spelling of my mother tongue, English, then you can get used to anything. That doesn't mean it was the best choice though.
  As for features and capabilities, it seems to be neck and neck, which of course leads to endless debates about pros and cons. It's interesting that before git was quite so popular, people that actually sat down and compared the two, like FogCreek and Google Code, generally chose Hg. I suspect the main reason that git initially won the popularity contest is that Linus wrote it. Nowadays the choice is a bit different because using anything other than git is trying to swim against the tide, but the initial reason for its success over Hg bugs me.
5. Re:Change by enigma32 · 2014-04-01 06:58 · Score: 1
  
  +1 UI madness.
  For me the problem with git is the extreme un-usability of the standard command-line client.
  There are countless ways of doing the same operations, all of which are confusing. Unless I use a specific command on a daily basis I end up having to look it up and sift through results with varying ways of doing the same thing. It is extremely frustrating. Some of the other dvcs solutions are far superior in this regard.
  Architecturally, git is fantastic. It seems to me it shouldn't be that difficult to make the standard client app easier to use on the command line. Too bad this article is a joke, I would actually love to see it happen.
6. Re:Change by charlesnw · 2014-04-01 07:05 · Score: 1
  
  No it's not. Sit down and actually use it. You'll find that it doesn't require an email address at all.
  
  --
  Charles Wyble System Engineer
7. Re:Change by BlackPignouf · 2014-04-01 07:28 · Score: 3, Funny
  
  Exactly.
  I love git, because all my development repos are self-contained, easy to backup and work perfectly offline.
  "git rebase -i" is just wonderful.
  BUT :
  You want to pull and overwrite your local changes? It's as easy as :
  git add *
  git commit -a -m "auto dev server commit"
  git fetch origin master
  git merge -s recursive -X theirs origin/master
  You want to clone your local repo to a new remote one and use it as origin? Sure :
  #On local machine
  cd foo_project
  git init
  git add *
  git commit -m "My initial commit message"
  #On remote machine (Git remote repository)
  sudo su - git
  cd /usr/local/git_root/
  mkdir foo-project.git
  cd foo-project.git/
  git --bare init
  git config core.sharedrepository 1
  git config receive.denyNonFastforwards true
  find objects -type d -exec chmod 02770 {} \;
  #On local machine, in your git project
  git remote add origin ssh://git@example.com:2227/usr/local/git_root/foo_project.git
  git push -u origin master
  Those are just 2 examples that come often enough to be an annoyance, but not often enough that I can remember them.
8. Re:Change by Yunzil · 2014-04-01 07:28 · Score: 2
  
  Terrible, unintuitive syntax. Horrible documentation that was apparently written for people who already understand it. Obscure error messages. Too much knowledge required up front to start using it effectively. Hard to pick up the pieces when something inevitably goes wrong.
  I've seen posts elsewhere where people say "Oh, once you understand that behind the scenes it's working on blobs and trees and commits then it makes more sense. Also, graph theory." OK, but should I need to know any of that? I don't need to know how an internal combustion engine works to drive my car.
  It probably makes perfect sense to Linus and people who shares his brainwaves. To us mere mortals, not so much.
  But this is all moot because I just realized the article is a joke.
9. Re:Change by tibit · 2014-04-02 03:47 · Score: 1
  
  OK, but should I need to know any of that?
  Yes. I've found that there's no way to use it without knowing this. It's as simple as that, and I don't consider it a deficiency of git at all. You're supposed to understand the tools that you use. The things you speak of are not implementation details, they are part of the semantics exposed directly to the user. They make the whole thing work and useful.
  Yes, the command line syntax is abhorrent, but then I almost never use it. SmartGit/Hg has won me over.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
Ah, there it is... by thevirtualcat · 2014-04-01 05:30 · Score: 1

Not as bad as some of the jokes in years past.
I miss the old days... by markhb · 2014-04-01 05:42 · Score: 3, Insightful

... when Slashdot posted nothing but joke stories all day on April 1; it was the best way to catch all of them. Maybe they decided they couldn't top themselves after OMG PONIES!!!!! (which I missed), but just sticking in one joke stories amongst a bunch of uninteresting real ones is lame. There isn't even an article on the Google prank!

--
Save Maine's economy: write stuff down. All comments are exclusively my own, not my employer.
1. Re:I miss the old days... by Nimey · 2014-04-01 06:26 · Score: 1
  
  I don't miss those days when every goddamn post on 1 April was an unfunny joke.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
2. Re:I miss the old days... by ArsonSmith · 2014-04-01 06:57 · Score: 1
  
  Now it seems every post on any day is an unfunny joke.
  
  --
  Paying taxes to buy civilization is like paying a hooker to buy love.
3. Re:I miss the old days... by sootman · 2014-04-01 12:20 · Score: 1
  
  You've got it exactly backwards. The whole point of April Fool's is to -- get this -- FOOL people. So instead of a bunch of OBVIOUSLY wrong stories that fool NO ONE (and are totally un-funny to boot), you sneak in one or two plausible-sounding stories among the rest and fool people.
  In other words, Slashdot doesn't want to just list a bunch of jokes that other people made -- they want to play some tricks themselves.
  I much prefer this to "shitty jokes that make Slashdot totally unreadable" day.
  
  --
  Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Hotmail (True!) by rstanley · 2014-04-01 06:20 · Score: 1

When Mickey$oft first bought Hotmail in 1997, and for many years after, it was running Qmail, on FreeBSD, and Solaris computers! (See also, Qmail.org)
IMHO, it hasn't worked as well since they moved it to their own software! ;^)
The "joke" is on Mickey$oft! ;^)
1. Re:Hotmail (True!) by barlevg · 2014-04-01 06:25 · Score: 1
  
  Microsoft evidently relies on Linux servers a decent amount. A Microsoft dev is also apparently a top contributor to the Linux kernel.
Two for one by Dan+East · 2014-04-01 06:52 · Score: 1

Nah, they're just lumping April 1 and April 20 into one event: an Easter Egg hunt for April Fool's jokes.

--
Better known as 318230.
And Git Migrates to CVS... by Anonymous Coward · 2014-04-01 07:08 · Score: 2, Funny

and CVS migrates to RCS supported by front end in Gopher, a backend in TFTP with all discussions held over usenet using the pine news reader. If everyone would just remember to update the damn version numbers.
1. Re:And Git Migrates to CVS... by Areyoukiddingme · 2014-04-01 09:52 · Score: 1
  
  Somebody actually remembers that pine could read news, not just email. Talk about obscure...
Pixar by tokiko · 2014-04-01 08:17 · Score: 1

Apple already makes use of vast numbers of Linux workstations. That office, of course, goes by the name Pixar.
Disney by tepples · 2014-04-01 11:17 · Score: 1

I thought Pixar was part of Disney, though last time I checked, the Jobs estate was a huge shareholder in both Apple and Disney.
Re:Apple is BSD by tqk · 2014-04-01 11:56 · Score: 1

...
Not really. it kind of has some BSD relations.
Your grammar and spelling belie your ethnic claim.
Would you bigots please go get a room?
(0) infidel /home/keeling_ uname -a Linux infidel 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64 GNU/Linux (0) infidel /home/keeling_ apropos bsd bsd-from (1) - print names of those who have sent mail bsd-mailx (1) - send and receive mail bsd-write (1) - send a message to another user bsd_signal (3) - signal handling with BSD semantics File::Glob (3perl) - Perl extension for BSD glob routine finite (3) - BSD floating-point classification functions finitef (3) - BSD floating-point classification functions finitel (3) - BSD floating-point classification functions isinff (3) - BSD floating-point classification functions isinfl (3) - BSD floating-point classification functions isnanf (3) - BSD floating-point classification functions isnanl (3) - BSD floating-point classification functions perlfreebsd (1) - Perl version 5 on FreeBSD systems perlopenbsd (1) - Perl version 5 on OpenBSD systems re_comp (3) - BSD regex functions re_exec (3) - BSD regex functions sigblock (3) - BSD signal API siggetmask (3) - BSD signal API sigmask (3) - BSD signal API sigsetmask (3) - BSD signal API sigvec (3) - BSD signal API tetris-bsd (6) - the game of tetris wait3 (2) - wait for process to change state, BSD style wait4 (2) - wait for process to change state, BSD style
Linux was intended to be sloppy happy about communicating with anything any way it wanted to since someone first offered Linus networking code.

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
One big way in which Git is not SVN-compatible by Myria · 2014-04-01 13:19 · Score: 1

(Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)
git2svn has a problem that we ran into recently: because git does not support hierarchical branching, if you do not keep all your branches in a single Subversion directory, it will take an excessively long time for a local git repository to synchronize with a Subversion repository.
For example, let's say that you have the typical /branches directory in Subversion. Now user "myria" comes along, and she wants to make her own directory of branches so that her own branches don't pollute the /branches directory. She does an svn copy of /trunk to /branches/myria/new-crypto. Now git2svn tries to import this change from Subversion into a local git repository and takes three hours. Why?
Because git doesn't support hierarchical branch names, from git's naive perspective, what Myria has done is make a copy of the entire repository into a new directory named "new-crypto" inside of her "myria" branch. Git does not interpret her commit as a creation of a branch - it sees "myria" as the branch, and "new-crypto" as merely a directory within the branch. Subversion gives no special meaning to the directory named "branches", so git2svn is simply using a hack of assuming that the "branches" directory contains objects that it can convert into git's branch objects. Git thus sees her commit as one giant commit of 100,000 files, and consequently takes forever processing it.
The above was a recently-encountered real-life situation at the office from about two weeks ago.

--
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
1. Re:One big way in which Git is not SVN-compatible by JesseMcDonald · 2014-04-02 03:59 · Score: 1
  
  git does support hierarchical branches. You can have a branch named maria/new-crypto, and even pattern-match on the branch path in refspecs. The problem, as you alluded to, is that SVN doesn't have native branches at all, just copies. How is git-svn supposed to know that /branches/maria/new-crypto refers to a branch of /trunk and not to a directory within the "maria" branch? They look the same. For that matter, you could get that path by creating a branch named "maria" (copied from some version of /trunk) and then coping /trunk into it as a subdirectory—a branch within a branch.
  You can work around odd SVN layouts somewhat by manually configuring custom branch paths in .git/config:
  
  [svn-remote "origin"] url = http://server.org/svn fetch = trunk:refs/remotes/origin/trunk branches = branches/maria/*:refs/remotes/origin/maria/* branches = branches/fred/*:refs/remotes/origin/fred/* tags = tags/*:refs/remotes/origin/tags/*
  
  --
  "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Option (c) by gstein · 2014-04-01 18:01 · Score: 1

Everybody in that issue, except for three, .. were part of our coordinated effort. Two people threw in comments that we had to delete (and if you look closely, are in the history). The third was likely aware, and his several comments supported our ruse, so they remained.
Our various tweets, including the two from @TheASF were (of course) coordinated along with the movement on the issue.
It was about a dozen of us, spanning around 14 hours. Many April Fool's pranks are "fire and forget". Keeping it *live* was our key. Many people, many voices, and many hours.
Hope you enjoyed :-)
1. Re:Option (c) by Anrego · 2014-04-02 01:03 · Score: 1
  
  Thanks for the followup :)
  And let me say I was legitimately blown away by this. I was totally convinced this was an April fools joke in the morning, but as things progressed I was starting to have doubts. By the time the proverbial beans were finally spilled, I was honestly giving it 50/50 of being real with very poor timing. You guys totally sold it.
  Definitely the best prank I've seen in a long time. Much appreciated :)
Re:No by drolli · 2014-04-01 18:50 · Score: 1

git: stores and compares decentralized repositories extremly well. It's good if you have loose collaborations without a central insitution providing the repo service. Advantages are that people can quickly store their own versions during development
subversion: manages a single repository in cases where preventing multiple (uncontrolled) branches is mandated to the organization responsible (Yes, it is an advantage not to have too many different possible original sources of builds).
April 2 by StormReaver · 2014-04-01 23:19 · Score: 1

The best thing about April 2 is that all those fucking stupid joke stories start to scroll off of the site.
The worst thing about April 2 is that those fucking stupid joke stories haven't yet fully scrolled off of the site.
I would REALLY love for Slashdot to have a new option: hide April 1 joke stories.