Git 2.8 Officially Released (softpedia.com)

← Back to Stories (view on slashdot.org)

Git 2.8 Officially Released (softpedia.com)

Posted by BeauHD on Monday March 28, 2016 @07:32PM from the what-a-surprise dept.

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.

87 comments

Min score:

Reason:

Sort:

Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 19:35 · 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.
1. Re: Eliminate git, move back to cvs by jeremyp · 2016-03-28 20:00 · Score: 4, Funny
  
  I'd rather remove my testicles with a rusty hacksaw than ever use CVS again.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
2. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 20:09 · Score: 1
  
  If project management is the solution, I want my problem back.
3. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 20:12 · 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.
4. Re:Eliminate git, move back to cvs by mrvan · 2016-03-28 21:04 · Score: 2
  
  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 :)
5. Re:Eliminate git, move back to cvs by Ed+Avis · 2016-03-28 21:09 · Score: 3, Interesting
  
  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.
  
  --
  -- Ed Avis ed@membled.com
6. Re:Eliminate git, move back to cvs by gardner · 2016-03-28 21:12 · Score: 5, Funny
  
  Which of course will be confused with NetCVS and FreeCVS
7. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 21:54 · Score: 0
  
  mandatory: https://xkcd.com/1597/
8. Re: Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 22:08 · Score: 4, Funny
  
  How about Source Safe? :p
9. Re:Eliminate git, move back to cvs by Dutch+Gun · 2016-03-28 22:27 · Score: 2
  
  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.
  
  --
  Irony: Agile development has too much intertia to be abandoned now.
10. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 22:54 · Score: 0
  
  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.
  Which platforms do you refer to? As a wild guess, I'd say Windows, and yes, Git for Windows works just fine these days. Also Microsoft Visual Studio 2013 Update 1 added integrated Git support.
11. Re: Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 23:21 · 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.
12. Re:Eliminate git, move back to cvs by jeremyp · 2016-03-28 23:27 · Score: 1
  
  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.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
13. Re: Eliminate git, move back to cvs by jeremyp · 2016-03-28 23:33 · Score: 3, Insightful
  
  Source Safe was the only ironically named source code control system.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
14. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 23:38 · Score: 0
  
  Screw all of that. Just tarball it with a date and time in the filename. Tracking changes is overrated.
15. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-28 23:52 · Score: 0
  
  Git does do the merge by itself. Type "git mergetool" and install the merge tool that suites you. I've found kdiff3 to be quite good for the only tough merge I've ever had to do a couple of weeks ago.
16. Re:Eliminate git, move back to cvs by petermgreen · 2016-03-28 23:57 · Score: 1
  
  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) .
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
17. Re:Eliminate git, move back to cvs by TheRaven64 · 2016-03-29 00:19 · 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.
  
  --
  I am TheRaven on Soylent News
18. Re:Eliminate git, move back to cvs by Paco103 · 2016-03-29 00:38 · Score: 1
  
  That's kinda what Git does. It stores full snapshots rather than diffs.
19. Re:Eliminate git, move back to cvs by turbidostato · 2016-03-29 00:48 · Score: 1
  
  CVS!!!???
  That's a fad from new boys. RCS rulez!
20. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 01:32 · Score: 0
  
  CVS is really, really, really olde and it's based on RCS (not that anything's wrong with RCS as a simple single file control system).
  I've used CVS; branching is ad-hoc at best and there are some operations that are completely NOT supported (removing "things"
  comes to mind and is especially lacking in any serious development environment).
  My only gripe with git is that versioning was an after-thought and is not well integrated. I don't care that it's not with the current
  paradigm of 1.0, 1.1, etc., but it's not automatic. You have to remove the file then checkout the file to get the $Id expansion to happen.
  I'm not a git expert, but there doesn't seem to be a way to relate a particular $Id hast to a commit hash - so it's almost a cosmetic
  feature at this point.
  If Linus had decided it was important to the kernel community, it'd be kick-ass (yeah, I know "tags"). But, I digress.
  git solves a lot of problems, and quite elegantly.
  CAP === 'concept'
21. Re:Eliminate git, move back to cvs by Antique+Geekmeister · 2016-03-29 01:38 · Score: 3, 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.
22. Re: Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 01:39 · Score: 0
  
  mmmm, you're turning me on...
23. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 01:52 · 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 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.
24. Re: Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 01:53 · Score: 1
  
  Not true -- "Concurrent" Versions System is reaching a bit.
25. Re:Eliminate git, move back to cvs by PincushionMan · 2016-03-29 02:19 · Score: 2
  
  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.
26. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 03:03 · Score: 0
  
  Yep, Git loses history. Your cooking recipes or source code are not safe in Git.
27. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 03:12 · 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 complete source code time machine capabilities with efficient storage and immutable revision history.
  [*]: BTW, there is a bug tracker entry on this topic and "obliterate" feature should become available in the upcoming SVN updates, AFAIK: https://issues.apache.org/jira/browse/SVN-516
28. Re: Eliminate git, move back to cvs by 0100010001010011 · 2016-03-29 03:20 · Score: 1
  
  ClearCase for life. (No really. We can't seem to get rid of it)
29. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 03:22 · 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.
30. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 04:00 · Score: 0
  
  Which of course will be confused with NetCVS and FreeCVS
  DragonflyCVS FTW!
31. Re:Eliminate git, move back to cvs by ClickOnThis · 2016-03-29 05:21 · Score: 1
  
  CVSDOS FTW!
  FTFY.
  
  --
  If it weren't for deadlines, nothing would be late.
32. Re:Eliminate git, move back to cvs by ClickOnThis · 2016-03-29 05:27 · Score: 1
  
  Eh? Speak up, sonny. My source-code control system is making me deaf.
  
  --
  If it weren't for deadlines, nothing would be late.
33. Re:Eliminate git, move back to cvs by tibit · 2016-03-29 05:28 · Score: 2
  
  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.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
34. Re:Eliminate git, move back to cvs by tibit · 2016-03-29 05:29 · Score: 1
  
  I should also add that if you're not using git/hg with smartgit, you're probably doing it wrong :)
  
  --
  A successful API design takes a mixture of software design and pedagogy.
35. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 06:25 · Score: 0
  
  Darcs, Bazaar, Git, Mercurial, Monotone, and Fossil are all good enough, and you can pick a satisfactory option by a roll of a d6.
  (Fossil has problems with large repositories though. Blame it on the SQLite-based file storage.)
36. Re:Eliminate git, move back to cvs by Zontar+The+Mindless · 2016-03-29 07:33 · Score: 1
  
  PC-CVS provides a nice KDE desktop to help you along while you're getting used to the FreeCVS userland.
  
  --
  Il n'y a pas de Planet B.
37. Re: Eliminate git, move back to cvs by tdelaney · 2016-03-29 08:58 · Score: 1
  
  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.
38. Re: Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 09:03 · Score: 0
  
  Perforce is a POS kind of software, you know? The fact that Perforce now offers some P4+Git solution proves that Perforce itself is worthless piece of VCS.
  And that Perforce integration with UE4 is useless if not painful to use.
39. Re:Eliminate git, move back to cvs by Dutch+Gun · 2016-03-29 12:36 · Score: 1
  
  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 MMO. There's no reason for an artist or designer to have access to the authentication server source code, for example, even though everyone needs access to the same repository. Security-wise, it's best to keep things segmented and only grant permissions on an as-needed basis. That way, if one of your artist's machines gets compromised, your source code isn't compromised as well.
  From a more pragmatic standpoint, it's also infeasible for very large projects to store a full history of all binary art assets - you'd need an absurd amount of storage on each client machine, especially if you've got several branches. It just wouldn't work. A lot of devs also tended to exclude types of binary files that they don't work with directly, as it just fills up their local client machine's drives. It's really only important to have a few weeks of history in order to be able to do emergency rollbacks as needed.
  Game developers tend to have some oddball use cases like this. Nothing against Git or Mercurial, but those would have been a terrible fit at my last job.
  
  --
  Irony: Agile development has too much intertia to be abandoned now.
40. Re:Eliminate git, move back to cvs by shuying · 2016-03-29 13:45 · 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.
41. Re: Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 18:08 · Score: 0
  
  ClearCase? ClearCase?!
  We're using RTC at office, I'm telling you, this diamond needs some crashing.
  In comparison, CVS, ClearCase and TFS look like heaven.
  I miss git :-(
42. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 23:21 · Score: 0
  
  Git is wonderful for developers who work with source code. Not so useful for other users who just want a place to safely stash things like images, binary document files, archives, build artifacts.
  - They're rarely doing branching, usually just tagged releases
  - They never need to merge (since they are working with binary files)
  - Having to bring down an entire repo to their desktop would eat up way too much space
  - Git doesn't deal well with large binary files, nor does it diff them well across the wire
  For regular users with binary files, a centralized VCS (such as SVN) is perfectly acceptable. It has a simpler model and you can teach them that once a file is committed to the server that it is safe forever. You can bring down just part of a repo-tree instead of the whole thing. Sending files to the server is very efficient if the file format doesn't change much between saves (SVN only sends the diff over the wire). Conflicts are immediately obvious, rather then deferred until a later merge.
  The downside, of course, is that nobody gets anything done when the centralized VCS is down, unless they had the foresight to bring things down locally ahead of time.
43. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-29 23:25 · Score: 0
  
  Some of us, OTOH, consider the fact that SVN does not have an obliterate command a feature and not a bug.
  It means that no matter how much users screw up, they can't ever get the repository to the point where we need to restore from backups. For small shops with an overworked IT staff and users that do stupid things, that's a very valuable feature to have in a VCS.
  Sensitive data commits, OTOH, are a problem and can only be solved via a dump/reload. But that's a people-problem, that doesn't have to be solved via technical means.
44. Re:Eliminate git, move back to cvs by tibit · 2016-03-30 01:16 · Score: 1
  
  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.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
45. Re:Eliminate git, move back to cvs by tdelaney · 2016-03-30 01:29 · Score: 1
  
  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 concept to learn. There are various extensions that people like to use, but I find that just the base rebase + the Facebook-developed commit --amend --rebase extension gives me all the power I need.
  If you enable changeset evolution then you don't even need to worry about putting commits into the secret phase - you can push, pull and modify history as you like and let changeset evolution propagate obsolescence markers to other repos. However I'm still not 100% ready to change over to evolution yet - I still see too much churn on it on the mercurial-devel list for my taste.
46. Re:Eliminate git, move back to cvs by tibit · 2016-03-30 01:38 · Score: 1
  
  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 changes you want to go into a given carved-out change/commit.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
47. Re:Eliminate git, move back to cvs by Anonymous Coward · 2016-03-30 03:04 · Score: 0
  
  Did you write that website? Because it looks like it's mostly bullshit, and the writer just seems to have a giant chip on their shoulder. E.g.
  
  4.There is an auxiliary .svn directory in each folder of Subversion working copy
  False. An outdated myth.
  Starting with Subversion 1.7 (released in Oct 2011), working copies have centralized metadata storage and there is a single .svn directory in the root of working copy.
  First, I don't know why anyone would care, and you're not giving me a reason. Fixing bugs/inefficiencies in your back-end is not something you should trumpet as if you've just won an argument. Secondly, if anyone was ever arguing that this was a serious deficiency of SVN, it was probably back when the Linux kernel was changing its source management, and that would have been a valid complaint.
  Also,
  
  2.Branches are expensive in Subversion
  False. A myth.
  Performance or space was never the reason branches were considered to be "expensive". They were expensive because merging was a huge pain in the ass. The last SVN-based workplace I saw still had regularly scheduled merge days. Maybe they weren't using up-to-date software or procedures, but I'm willing to bet that this still continues to be an issue.
  
  Distributed version control systems are inherently superior to centralized ones such as Subversion
  False. There is a parity.
  I'm rolling my eyes at this, but if you're willing to say that there are pros and cons to each, then it's clearly a matter of opinion and circumstance, so claiming parity is just as wrong as saying one is better.
  #11 again, misunderstands the issue and mischaracterizes it. For one thing, tracking content and not files is a deliberate design decision. Doing things this way is a tradeoff, not an inherently bad idea. Claiming otherwise is disingenuous. Also, git mv is just syntactic sugar. Personally I didn't know it existed. Apparently, it's equivalent to
  mv oldname newname git add newname git rm oldname
  It moves the file, and updates the index. If you then replace the file with entirely new content, then it's not the same file, now is it? As a human looking at that repository before and after the change, I would say you deleted file A and created a new file B. If you wanted to record the move, why wouldn't you commit after moving the file? Is it really that important to record every little detail that happens at the filesystem level? And if that's really your complaint, [a] why not have a versioning filesystem with that feature, and [b] you're complaining that git has very little idea of what a filesystem even is, which is true, and could be considered to be an issue, but you don't understand what that means, so you're just going to parrot something about losing history.
  There may be a good argument for using SVN vs git, but this is not it.
rsync by Anonymous Coward · 2016-03-28 19:47 · Score: 2, Informative

From the second link:
> Support for cloning via the rsync protocol [...] has been dropped.
rsync got dropped, not added by beshr · 2016-03-28 19:50 · Score: 5, Informative

https://github.com/git/git/com...
1. Re:rsync got dropped, not added by utahjazz · 2016-03-29 08:43 · Score: 2
  
  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."
Git usage? by Neo-Rio-101 · 2016-03-28 20:08 · Score: 1

Just curious as to who is using git as version control for not only documentation, but configuration management - such as with puppet and the like

--
READY.
PRINT ""+-0
1. Re:Git usage? by Anonymous Coward · 2016-03-28 20:53 · Score: 0
  
  I am. Makes puppet-crap way easier to control. I have git-hooks in place that detect when stuff is pushed to 'production' branch so that puppet does it's job automagically. The problem with that is that puppt is not orchestration stuff and relating services one to another is a pain. I'm so much inclined to use juju for that, but as my stuff is not openstack/amazon deployed I'm not sure how that would work.
2. Re:Git usage? by Anonymous Coward · 2016-03-28 23:43 · Score: 0
  
  Using Ansible, but, yeah, all in git.
3. Re:Git usage? by Anonymous Coward · 2016-03-29 00:45 · Score: 0
  
  The supercomputing centers are ;-)
4. Re:Git usage? by Anonymous Coward · 2016-03-29 01:07 · Score: 0
  
  I use it for "chef-solo", and thus avoid the need for a chef server, or the risk of a modified role or cookbook on one host screwing up the entire environment for other hosts. You do have to make sure the code stays synchronized with the upstream repository, and remember to push changes back, but it's been precisely.
  Github has also been my priceseless friend for maintaining a 100% available upstream repository. I just wish more of the chef authors would stop writing LightWeight Resource Protocols, or LWRP's, so you can "use it however you want!!!", and actually finish writing the cookbook so I don't have to destabilize my cookbook by writing wrappers for theirs. Especially, I wish they'd *stop putting passphrases in cleartext* in their cookbooks. Just because the passphrase is normally in a chef server's recipes or databags does not mean it is secure, by any means. That stupid "users" cookbook stores the private SSH keys in plain text and has no hooks for data bags. apache2 publishes private SSL keys, and they can *all* be yanked straight out of the upstream git repository or from the chef server if you use one.
  It's why I'm giving up on chef. Their insistence on writing cookbooks that edit one line or one part of a config, *insist* on doing it, but refuse to take responsibility for the rest of the configuration "because an admin might want something else" leaves a lot of admins grinding out horrible tools that cannot be kept compatible with upstream's randomized changes.
5. Re:Git usage? by Anonymous Coward · 2016-03-29 01:24 · Score: 0
  
  with salt v 2015.8.8, but yeah, using git to manage formulae and states on a couple of thousand boxes.
6. Re:Git usage? by ljb2of3 · 2016-03-29 01:29 · Score: 1
  
  I store my SaltStack configs in it. In fact, that's my most active repository. Using git for that was what really got me using git in the first place. Now I put my code into git too, but those projects are much less active.
  
  --
  // TODO: Witty Signature
bugfixed gitk angle brackets yet? by Anonymous Coward · 2016-03-28 21:29 · Score: 0

The only thing I care about: Have they fixed the bug that causes gitk to display patches incorrectly in word-diff mode? They've ignored my repeated attempts to report this on the mailing list. (Search the mailing list archive, and you will find my bugreport.)
pet hate by MancunianMaskMan · 2016-03-28 22:06 · Score: 1

..comfortable to use ...
"Convenient" is the word. "Comfortable" is a germanism in this context. Lennart is that you?
1. Re:pet hate by Anonymous Coward · 2016-03-29 00:17 · Score: 0
  
  It could also be a Chinese-ism - (shufu) is very common in this context. I would also make a distinction between "comfortable" and "convenient" here, both of which are valid, but with different nuances. I would say that once you know the handful of command syntax quirks (e.g. checkout's multiple modes), Git is both comfortable to use and convenient.
2. Re:pet hate by turbidostato · 2016-03-29 01:00 · Score: 1
  
  "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.
3. Re:pet hate by Anonymous Coward · 2016-03-29 01:33 · Score: 0
  
  In French it's "convivial", which I would translate to "user-friendly" rather than "convenient", although both are probably close enough in the blurb at the top of the page. Actually "inconvénient" exists, but it's a noun; it would be "drawback" in many contexts, but not all.
4. Re:pet hate by jareth-0205 · 2016-03-29 01:47 · Score: 1
  
  ..comfortable to use ...
  "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...
5. Re:pet hate by Anonymous Coward · 2016-03-29 01:56 · Score: 0
  
  Comfortable :: reasonable, intuitive. Built on a familiar elegant setting. Consider git mv vs. the CVS way for the same operation.
  Convenient :: esoteric commands that are difficult to remember, but are effective (convenient).
  CAP === 'predict'
Its AI self learning capabilities are impressive t by Anonymous Coward · 2016-03-28 23:04 · 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 by jez9999 · 2016-03-28 23:37 · Score: 1

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...

--
== Jez ==
Do you miss Firefox? Try Pale Moon.
1. Re:The one feature I'd love by Anonymous Coward · 2016-03-29 00:12 · Score: 0
  
  This is trivial with a commit hook. In the same way that git-review uses a hook to add Gerrit change IDs, you can easily write a hook to add a trailer for the current branch name.
2. Re:The one feature I'd love by jez9999 · 2016-03-29 01:54 · Score: 1
  
  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.
  
  --
  == Jez ==
  Do you miss Firefox? Try Pale Moon.
Identity guessing by Anonymous Coward · 2016-03-28 23:40 · 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?
1. Re:Identity guessing by Anonymous Coward · 2016-03-29 11:08 · Score: 0
  
  I think you are thinking of Github, which is not related to the Git project (though it is highly dependent on the technology), but is indeed infested with SJWs.
What is with the GNU Logo by Anonymous Coward · 2016-03-29 00:07 · Score: 0

Since when is GIT a GNU project? A penguin would be more relevant. GIT is a Linux project and free as in beer using the deprecated LGPL/GPL v 2 and not free as in FREEDOM (TM) all your patents belong to us GPL v 3 as required for basically all GNU projects .
1. Re:What is with the GNU Logo by fisted · 2016-03-29 01:32 · Score: 1
  
  While I agree about not being a GNU Project, "Linux project" makes no sense at all.
  
  --
  CLI paste? paste.pr0.tips!
2. Re:What is with the GNU Logo by Anonymous Coward · 2016-03-29 05:21 · Score: 0
  
  It was written by Linus as a replacement revision control system for the kernel. Just thought that makes it closer to Linux than to GNU. ( That said my thought process tends to jump corners )
3. Re:What is with the GNU Logo by TangoMargarine · 2016-03-29 05:46 · Score: 1
  
  Git isn't an acronym either.
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
git is the C++ of VCS.. by xTantrum · 2016-03-29 00:49 · Score: 0

...nuff said

--
$action = empty(PHP) ? backToC() : unset(PHP) ; "when the concrete cases are understood, the abstractions are readily
Softpedia Shill by Anonymous Coward · 2016-03-29 00:53 · 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 by Antique+Geekmeister · 2016-03-29 00:57 · 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.
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 or blame for it has been awkward. That has been the _only_ feature from the Subversion based clients that I've genuinely missed.
Re:Uhhhhh by Anonymous Coward · 2016-03-29 03:03 · Score: 0

Or send it to Personnel along with your birth certificate in the hopes that you might get hired.
submodules still not that useful by Anonymous Coward · 2016-03-29 04:04 · Score: 0

the android 'repo' tool exists primarily because git submodules not quite useful. I wonder if if submodules would be replaced at some point.
Wake me up when they fix the UI by Foresto · 2016-03-29 08:36 · Score: 1

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 for so long with such glaring (but fixable) flaws, I found archived messages from Git maintainers who were not only too stubborn to learn from other projects, but also such obstructionists that they actually discouraged improvements. Nobody wants to donate their time in an environment like that. So much for, "it's open source; contribute a fix yourself." How very sad.
Benefit of Git: Branches! by Keybounce · 2016-03-30 17:34 · 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 :-)