Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
GNU is Not Unix Software Microsoft Open Source Operating Systems Windows Linux Apple Build Technology

Git 2.8 Officially Released ( 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 and before doing any commits. Check out the the full release notes for the complete list.
This discussion has been archived. No new comments can be posted.

Git 2.8 Officially Released

Comments Filter:
  • by Anonymous Coward on Tuesday March 29, 2016 @03:35AM (#51798239)

    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.

    • by jeremyp ( 130771 ) on Tuesday March 29, 2016 @04:00AM (#51798309) Homepage Journal

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

    • by Anonymous Coward

      If project management is the solution, I want my problem back.

    • Re: (Score:2, Informative)

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

    • by mrvan ( 973822 )

      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

      • 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

        • by jeremyp ( 130771 )

          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.

        • by TheRaven64 ( 641858 ) on Tuesday March 29, 2016 @08:19AM (#51798971) Journal

          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.

          • by Anonymous Coward

            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.

        • by tibit ( 1762298 )

          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

          • by tibit ( 1762298 )

            I should also add that if you're not using git/hg with smartgit, you're probably doing it wrong :)

          • 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

          • by shuying ( 752029 )

            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.

            • by tibit ( 1762298 )

              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.

              • 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

                • by tibit ( 1762298 )

                  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

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

        • by Antique Geekmeister ( 740220 ) on Tuesday March 29, 2016 @09:38AM (#51799335)

          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.

          • by Anonymous Coward

            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)

      by Ed Avis ( 5917 )
      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 [].
    • CVS!!!???

      That's a fad from new boys. RCS rulez!

    • Re: (Score:2, Informative)

      by 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

    • 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)

    by Anonymous Coward

    From the second link:

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

  • by beshr ( 3972083 ) on Tuesday March 29, 2016 @03:50AM (#51798287)
    • 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."

  • 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

    • by ljb2of3 ( 967196 )
      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.
  • ..comfortable to use ...

    "Convenient" is the word. "Comfortable" is a germanism in this context. Lennart is that you?

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

  • by 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

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

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

  • by Anonymous Coward

    Also, it is now possible to tell Git not to guess your identity, which, instead, forces you to add a and 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?

  • Softpedia Shill (Score:4, Interesting)

    by Anonymous Coward on Tuesday March 29, 2016 @08:53AM (#51799137)

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

  • > Also, it is now possible to tell Git not to guess your identity, which, instead, forces you to add a and 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

  • 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

In seeking the unattainable, simplicity only gets in the way. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982