Git 2.8 Officially Released (softpedia.com)

prisoninmate quotes a report from Softpedia: Git 2.8 has been released on March 28, and we have to admit that it comes as a huge surprise to us all. Prominent features of Git 2.8 include parallel fetches of submodules, which allows for the inclusion of other Git repositories in a single Git repo when using the "git submodules" command, support for turning off Git's smudge and clean filters, and support for cloning repos through the rsync protocol. The Git for Windows build received a lot of attention in Git 2.8 and it looks like it's now as comfortable to use as it is on the GNU/Linux and Mac OS X platforms. Also, it is now possible to tell Git not to guess your identity, which, instead, forces you to add a user.name and user.email before doing any commits. Check out the the full release notes for the complete list.

Comments

Eliminate git, move back to cvs

[Anonymous Coward]

Git is a pretty awful solution to project management. If you want to check out source, you have to download the entire tree, with all releases and branches. It's much simpler to work with cvs. Additionally, cvs is more user friendly and more secure than git. I don't understand the appeal of git. I hope git is a passing fad and that we'll all move back to cvs, which is far superior.

Re: Eliminate git, move back to cvs

[jeremyp]

I'd rather remove my testicles with a rusty hacksaw than ever use CVS again.

Re:Eliminate git, move back to cvs

[Anonymous Coward]

you have to download the entire tree, with all releases and branches

If that's an issue for you then subversion might be the way to go. Anything but cvs.

Re:Eliminate git, move back to cvs

[mrvan]

I hope that you are being facetious, but I'll bite.

I've worked with cvs, subservsion, mercurial/hg, and git, and git is by far the most powerful tool and the easiest one to work with after the initial learning curve. You might have massively larger projects than me, but checking out the whole tree has never been a problem for me, and I really like being able to commit (and more rarely: check version history) when working offline.

Branching, tagging, cherry-picking, and rebasing are very easy to do and make it possible to manage a largish project with multiple release and feature branches relatively painlessly. In my daily workflow there are only a few commands I use regulary, and a couple more than I use occasionally (e.g. when releasing a stable version). Moreover, I've never found that there was anything I couldn't do, from rewriting history when needed (e.g. after checking in passwords or copyrighted code), to undoing stupid stuff (e.g. a force push from a branch that wasn't pulled or a merge with a wrong branch).

Although the commands can be a bit arcane (e.g. the three levels of git reset or the exact rebase syntax) the community support, tooling, and documentation is excellent.

As another poster above said:

I'd rather remove my testicles with a rusty hacksaw than ever use CVS again.

Sounds painful, but: yes :)

Re:Eliminate git, move back to cvs

[Ed Avis]

The parent comment might be a troll but CVS still has its fans. OpenBSD development uses it and they are working on their own reimplementation, OpenCVS.

Re:Eliminate git, move back to cvs

[gardner]

Which of course will be confused with NetCVS and FreeCVS

Re: Eliminate git, move back to cvs

[Anonymous Coward]

How about Source Safe? :p

Re:Eliminate git, move back to cvs

[Dutch Gun]

Is there actually much practical difference between Mercurial and Git? As far as I can see, the two products are very similar in general concept and execution, although I'd characterize Mercurial as being more user-friendly with better cross-platform compatibility, and Git as being more powerful/flexible, and a bit more arcane to use.

Git is certainly the clear "winner" in terms of popular support, and honestly, that does come with some real advantages. Even so, I use Mercurial at home since I do cross-platform work. Maybe Git cross-platform support has improved recently, but four years ago when I was choosing my repository, it looked like Mercurial was the best choice for me.

I've also used Perforce in commercial environments (specifically, game development) where, interestingly enough, it has some distinct advantage over Git and Mercurial. In game development, we're working with huge numbers of very large binary assets that must be managed with the source, and Perforce is much better at managing those, doing partial syncs, limited histories, permissions, etc.

Re: Eliminate git, move back to cvs

[jeremyp]

Source Safe was the only ironically named source code control system.

Re:Eliminate git, move back to cvs

[TheRaven64]

Is there actually much practical difference between Mercurial and Git?

Yes, the mercurial CLI is just about good enough, so people use it. The git CLI is an abomination that is so bad that people are willing to invest time avoiding using it. As a result, there are a lot of nice GUI tools for working with git.

Re:Eliminate git, move back to cvs

[Antique Geekmeister]

There are very, very good reasons for that. Subversion suffered profoundly from the inability to delete disastrous commits with binaries, mistaken directories, and completely obsolete and deleted projects. This made re-organization of content, even into another repository, very awkward and error prone. Even CVS and professional tools like Perforce were able to completely discard idle directories. The insistence on preserving deleted content also made sanitization of repositories to clear out passwords and password history, or clearing out accidental commits of bulky binaries, very difficult.

If you need a "reference" git repository with all history, certainly create one. But few projects actually need this.

Re:Eliminate git, move back to cvs

[Anonymous Coward]

Your comment is funny. I'm pretty sure that you confuse CVS with SVN. :)
There is no reason to be using CVS nowadays when you have an option to migrate to SVN without any headache. Migration to SVN is an easy and straightforward task that brings only benefits and has no downsides.

On the contrary, migration to Git can become a disaster because it is not just about migrating a version-control database to another system, but adopting vague and unclear techniques that don't make your experience using VCS better or anything. Git just makes version-control a different kind of beast you are not used to with SVN or CVS. Migrating to Git involves brain damage, and a can bring more downsides than benefits.

The one real advantage of Git is its distributed nature and fast speed. But this comes with disadvantages such as no locking and no real support for storing binary assets, no access control, unsafe version-history and one of the main disadvantages -- poor support for concurrent work in larger teams.

Still thinking that Git is the one and only version control system that should be used by everyone? Think twice! Git is only one of many VCSes and it has its own disadvantages compared to Subversion or Mercurial. And finally, don't forget that Git is just "a stupid content tracker", a single-purposed tool for hackers designed to be used as a VCS for Linux Kernel. It's not an universal version-control system.

Re:Eliminate git, move back to cvs

[PincushionMan]

RCS?! Bah!

You young whippersnappers and your newfangled toys! SCCS is the true Source Code Control System. Everything else is just a 'wanna be'. Just ask Jörg, he still maintains a fork. I bet he keeps a copy of the code on , if you'd like a look at it.

Now get off my ... uhh ... square patch of green stuff, there.

Re:Eliminate git, move back to cvs

[tibit]

Git has actually more useful features than Mercurial. I tried Mercurial after using git for a while, and found it deficient. Git has native support for stashes, and the concept of the index is great when you're carving off individual commits from your single larger body of work. Mercurial, through its lack of good stashing (with log support!) and index, favors larger, monolithic commits. That's a bad thing to have by design.

So yeah, there's very much a practical difference between hg and git, to a point where I consider hg feature incomplete and not usable for what I use source control for.

I don't quite know what permissions are good for: presumably everyone working on a project can access anything in the project, that's like the whole point of it all. Once they do, the version control is there to make sure that all changes are undoable and, other than perhaps taking up some room in the repository, have no lasting impact. Even better: with git, you can forget some history you find inconvenient: just drop the reference and garbage-collect it.

rsync

[Anonymous Coward]

From the second link:

> Support for cloning via the rsync protocol [...] has been dropped.

rsync got dropped, not added

[beshr]

https://github.com/git/git/com...

Re:rsync got dropped, not added

[utahjazz]

I like how they have a bullet point leading with "support for rsync", only to state and the end of the sentence that it's a removal. It's like if the founding fathers had written :

"A well regulated militia, being necessary to a free state, the right of the people to keep and bear arms, shall not be infringed, is something that we've decided not to include in this bill or rights because it turned out it's totally broken and nobody ever noticed or complained."

Its AI self learning capabilities are impressive t

[Anonymous Coward]

From the release notes:
  * "push" learned that its "--delete" option can be shortened to
      "-d", just like "branch --delete" and "branch -d" are the same
      thing.

  * "git blame" learned to produce the progress eye-candy when it takes
      too much time before emitting the first line of the result.

Softpedia Shill

[Anonymous Coward]

Take a look at prisoninmate's posting history. Every single thing he's submitted is only to generate traffic for Softpedia.