Git 2.8 Officially Released (softpedia.com) 87
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.
Eliminate git, move back to cvs (Score:4, Funny)
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 (Score:5, Funny)
I'd rather remove my testicles with a rusty hacksaw than ever use CVS again.
Re: Eliminate git, move back to cvs (Score:4, Funny)
How about Source Safe? :p
Re: (Score:1)
SourceSafe actually has a warning dialog in the lines of "trying to update over X files, this may fail, continue?", which is bad enough, until you realize that someone actually spent time writing code for that warning dialog.
Re: Eliminate git, move back to cvs (Score:4, Insightful)
Source Safe was the only ironically named source code control system.
Re: (Score:1)
Not true -- "Concurrent" Versions System is reaching a bit.
Re: (Score:2)
ClearCase for life. (No really. We can't seem to get rid of it)
Re: (Score:2)
I feel your pain. With a bit of work, it is possible to use Mercurial for your day-to-day work, and then ClearCase Remote Client (or whatever it's called now) to sync to ClearCase. I know - I've done it.
The biggest issue is ensuring that the timestamps are as CCRC expects - the .ccrc files (I think that's right - it's been about 5 years) hold the timestamps in a somewhat obfuscated format.
Re: (Score:1)
If project management is the solution, I want my problem back.
Re: (Score:2, Informative)
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: (Score:3)
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 i
Re: (Score:3)
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-pla
Re: (Score:2)
I think Mercurial is superior to git. However, the Apple Xcode tool chain doesn't support it, so I've been forced reluctantly to use git.
We also use git at work on a project where we share code with a large customer. I have to say, the much hyped merging abilities of git are actually pretty poor.
Re:Eliminate git, move back to cvs (Score:5, Insightful)
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: (Score:1)
You must have never heard of TortoiseHg.
If Git for Windows has been improved in this release I'll have to take a look. But in the past TortoiseHg has been vastly better than any Git tool on Windows.
Re: (Score:3)
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 whe
Re: (Score:2)
I should also add that if you're not using git/hg with smartgit, you're probably doing it wrong :)
Re: (Score:2)
Git stash (just looked it up) sounds similar to Mercurial/Perforce shelve feature. I don't necessarily understand why you'd want that to be logged, as by definition it's a temporary operation. I agree that I'd like Mercurial to be able to drop unneeded history more easily. Making history immutable sounds good in theory, but it seems a little inflexible in actual practice.
Permissions comes in handy when you've got large cross-discipline teams in a commercial environment, like when I worked on a very large
Re: (Score:1)
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.
I don't know how you got this impression of Mercurial. My experience is the exact opposite. Mercurial encourages small, frequent commits. With "hg rebase" and "hg histedit", a revision history can be edited very easily. Git only makes things unnecessarily complicated by having an index.
Re: (Score:2)
When I edit code, I usually can't know a priori how to cut it up into smaller commits. So I make a large change that has often went through many iterations, that I save as stashes/large commits, and only when it's done I can figure out how to slice and dice it into changes that make sense in the history. That's what index is very handy for, and hg makes it much, much harder to do.
Re: (Score:2)
In Mercurial I just create a new named branch (an optional step, but I prefer it), do in-progress commits and change the phase to secret (so they can't be pushed to another repository until the phase is changed back to draft).
Once I've got things to the desired code I modify and rebase the changesets until I have the series I want. Basically exactly the same process - secret commits provide essentially the same functionality as the git stash, but since they're just changesets in the graph it's one fewer con
Re: (Score:2)
The thing is: I usually have one large change commit that I eventually split up by selecting code fragments interactively using smartgit. I don't need to retype any code or change anything, I simply select the changes I want in a carved-out smaller change, move these to index, stash the working copy changes, test the index, the commit, restore working copy - now with a bit less changes in it - and rinse/repeat. There's no way that I know of doing it in mercurial that way, essentially clicking on what change
Re: (Score:2)
What bothers me about git is that they don't seem to consider the history of the repository (that is what was on branch "x" of repository "y" on date "z") important. There is the reflog but that seems more geared towards short term disaster recovery than long term history documentation (it's easy to delete entries and afaict there is no way to retrive it for a remote repo) .
Re:Eliminate git, move back to cvs (Score:4, Informative)
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: (Score:1)
Subversion provides tools to filter out (i.e. delete) "disastrous" commits from the repository. But the task is not easy and one can prove that this task should not be easy or completed as one-line operation[*]. Committing "binaries, mistaken directories, obsolete projects" is not a problem for SVN, it efficiently handles repository storage space. The problem could be only if you commit a large number of ISOs or sensitive data.
Subversion promises to be an enterprise version-control system and delivers compl
Re: (Score:3, Interesting)
Re:Eliminate git, move back to cvs (Score:5, Funny)
Which of course will be confused with NetCVS and FreeCVS
Re: (Score:2)
CVSDOS FTW!
FTFY.
Re: (Score:2)
PC-CVS provides a nice KDE desktop to help you along while you're getting used to the FreeCVS userland.
Re: (Score:2)
That's kinda what Git does. It stores full snapshots rather than diffs.
Re: (Score:2)
CVS!!!???
That's a fad from new boys. RCS rulez!
Re: (Score:3)
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. [sourceforge.net]
Now get off my
Re: (Score:2)
Eh? Speak up, sonny. My source-code control system is making me deaf. [columbia.edu]
Re: (Score:2, Informative)
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
Benefit of Git: Branches! (Score:1)
Git has one big benefit over other source code control systems that I have used: Branch support.
Oh, and a command-line syntax that is probably turing complete :-)
rsync (Score:2, Informative)
From the second link:
> Support for cloning via the rsync protocol [...] has been dropped.
rsync got dropped, not added (Score:5, Informative)
Re: (Score:3)
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."
Re: (Score:2)
Re: (Score:1)
pet hate (Score:2)
"Convenient" is the word. "Comfortable" is a germanism in this context. Lennart is that you?
Re: (Score:2)
"It could also be a Chinese-ism"
It could also be a Spanish false-friend. And given Spanish roots, I bet that's the case for any other Romance language.
Re: (Score:2)
"Convenient" is the word. "Comfortable" is a germanism in this context. Lennart is that you?
Depends - 'convenient' implies 'easy'. 'Comfortable' implies that 'I already know it'. I'd say that's more appropriate than trying to say that git is easy...
Its AI self learning capabilities are impressive t (Score:2, Funny)
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.
The one feature I'd love (Score:2)
So the one feature I'd love to see implemented is running interpret-trailers automatically on each commit. Git is nearly perfect for me but I would really love to be able to auto-tag the commit with trailers on each commit using settings in my global config. That way I could set it up to automatically tag the commit with the current branch name. It will probably get implemented some day...
Re: (Score:2)
But commit hooks can only be done on a repository level. I'd like to do them on a global level.
Also I just think doing it in the global config is neater than setting up a hook. The hook is more code.
Identity guessing (Score:1)
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
Whew, that's a relief! Is there also a space to enter my pronouns? Xi would be very triggered if Git doesn't let xe tell it how Xi identify. Surely this has been worked out by the Code of Conduct?
Re: (Score:2)
While I agree about not being a GNU Project, "Linux project" makes no sense at all.
Re: (Score:2)
Git isn't an acronym either.
Softpedia Shill (Score:4, Interesting)
Take a look at prisoninmate's posting history. Every single thing he's submitted is only to generate traffic for Softpedia.
No identity guessing for shared repsitories (Score:2)
> 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.
This is invaluable. I occasionally want to source control configuration directories, with branches and merges among them for different environments. But when the working local repository is owned by "root" or "apache" and multiple administrators may need to configure the host, the need to reset the log associated with a commit to take individual credit o
Wake me up when they fix the UI (Score:2)
Git's user interface is the biggest counterproductive, nonintuitive, inconsistent, needlessly complex, user-hostile, pile of garbage that I can remember ever haunting my terminal, and I say this after having worked with sendmail config files. Sadly, Linus' name and GitHub's early momentum have propelled this blight on the face of modern software development into entrenchment.
Meanwhile, Mercurial has all the same power with practically none of the pain.
When I wondered how a tool as important as Git could go