15 ms·

Vim is moving to git, GCC is moving to git. What's with all the change?

by phragg 11y ago

Zikes 11y ago
Google Code shutdown?
- amyjess 11y ago
  GCC didn't use Google Code. Like all GNU projects, they're hosted on Savannah, and that's not changing.
  - Zikes 11y ago
    But Vim did, didn't it? Google Code shutting down may still have contributed to the sea change.
    - carlosdp 11y ago
      I think this is coincidental timing more than anything.
    - amyjess 11y ago
      Eh, so many projects have been moving to DVCS for the last few years. Google Code shutting down is more recent than the trend towards DVCS.
belorn 11y ago
git has more or less completly taken over the mindshare from all other version control system.
- nailer 11y ago
  I think sometimes we forget that network effects outweigh most normal values of technical superiority. Let's say, for the purposes of the argument, that "hg/Mercurial is 20% better than git". This doesn't matter: hg/Mercurial has to be 500% better than git to be able to replace it. Look at the past changes: they've all been huge shifts in how we do version control, not minor improvements The DVCSs were 500% better than Subversion (wow, distributed!) Subversion was 500% better than CVS (wow, renames work! Branching is easy! http support!) CVS was 500% better than RCS (wow, we can check out files concurrently)
  - octo_t 11y ago
    > Branching is easy when svn first came out (and up until a few years ago) branching was definitely not easy!
    - lfowles 11y ago
      What changed a few years ago?
      - anonydsfsfs 11y ago
        Subversion 1.5 added support for tracking merges: https://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking https://subversion.apache.org/docs/release-notes/1.5.html#me... Before this, merging branches was a huge pain, because you had to manually keep track of the commits that needed to be merged.
  - threeseed 11y ago
    You are right. But it is often referred to as the 10x rule. http://www.minidisc.org/econ113-paper.htm http://www.minidisc.org/econ113-paper.htm A technology needs to be 10x better than a previous one for widespread adoption. It has successfully explained many failed technologies and products.
    - kazinator 11y ago
      > A technology needs to be 10x better than a previous one for widespread adoption. It has successfully explained many failed technologies and products. A hypothesis about failure, on the other hand, has to account for the failures and successes. This one doesn't. While it can plausibly explain failed technologies and products, it doesn't explain the historic success of junk that is worse than its predecessors. A technology can be hyped into widespread adoption. It can be dumped on the market for widespread adoption. It can ride on top of cheap hardware for widespread adoption. It can be bundled with something else, achieving widespread adoption. A technology can be falsely evaluated as 10X better by a large number of complete idiots, resulting in widespread adoption among idiots, resulting in pressure for non-idiots to adopt. All these effects can overcome the barrier of having to be actually, objectively 10X better. The "10X better adoption barrier" is only faced by honestly promoted technologies whose campaign consists of "try this because it's better for these objective reasons".
lfowles 11y ago
irssi moved to git (github even) to encourage contributions.
- davidgerard 11y ago
  LMMS http://lmms.io http://lmms.io was on svn on Sourceforge. It was more or less moribund. Moved to git on github, immediate influx of contributors and a buggy 0.4.13 was advanced to a really very nice 1.0 in about six months :-) Unless your project is weighty enough to have its own gravitational pull, github is a ridiculously easy place to contribute and make life easy for contributors.
deleted 11y ago
[deleted]
kazinator 11y ago
> Vim is moving to git, GCC is moving to git. What's with all the change? Git does something very well: it has great support for rewriting version histories. It nearly flawlessly supports almost every conceivable scenario of slicing, dicing, mixing and combining. It also has great support for working at the sub-file granularity. For instance, this morning I moved a fix from an experimental branch to stable. The fix was part of a huge commit, and consisted of just a few "hunks" out of many in one file. It was obvious that the particular fix, though needed by the experimental changes, could be promoted to stable (it was a change of the kind where some code is altered in such a way that it no longer interacts with the experimental changes, and is improved at the same time.) With git I easily rewrote that big commit such that just those specific changes in the specific file were removed from that commit. This was done without touching anything in the working copy not so much as altering any modification timestamp! ("make" didn't even see that anything needed to be rebuilt after the commit rewrite.) In git we can do "keep my working copy as it is, but alter the history behind it, so those alterations then appear as staged, uncommitted changes". Then we can easily migrate the changes somewhere, like turning it into its own commit, perhaps on another branch. After I migrated those changes to master, I then went back to that branch and did a "git rebase". Lo and behold, that branch picked up the changes, and now it looks as if those changes were written on master all along, before the experimental changes were developed. Programmers need this kind of thing because we are obsessed about making the perfect set of changes. Since the history of a code base is a digital artifact, we want to be able to hack that artifact to perfection too, not just the instantaneous/current view of the code itself. Git is also like an adventure game in which you solve quests and acquire higher and higher status. This creates allure. The Novice Adventurer cannot understand all the reasons why the Grandmaster Wizards of GCC have switched to Git, but is mystified and fascinated.
- nephyrin 11y ago
  Rewriting public branch history is not generally used by any major project except in extreme circumstances. This reads like an attempt at satire by someone who doesn't understand the actual utility of history rewriting in git, which is generally for extending version control to your development changes (e.g. what is more formally codified in Mercurial as the draft phase).
spiralpolitik 11y ago
In the case of the Gnu projects it was pointed out the futility of continuing to maintain GNU Bazaar when there were at least two more widely used DVCS (git and hg).
jahewson 11y ago
Bazaar is dead, it's no longer maintained and hasn't had a release in 3 years.
- kazinator 11y ago
  So are you saying it doesn't work? What issues are you having with Bazaar that require a new release? I couldn't care less if Git stopped making releases; what I'm using isn't the latest anyway and does everything I want. (Though I'd like any newly discovered security holes to be fixed in any pieces of Git that face the Internet; e.g. via embedding in CGIT).

Vim is moving to git, GCC is moving to git. What's with all the change?

by phragg 11y ago

Vim is moving to git, GCC is moving to git. What's with all the change?

Zikes 11y ago

Google Code shutdown?

amyjess 11y ago
GCC didn't use Google Code. Like all GNU projects, they're hosted on Savannah, and that's not changing.
- Zikes 11y ago
  But Vim did, didn't it? Google Code shutting down may still have contributed to the sea change.
  - carlosdp 11y ago
    I think this is coincidental timing more than anything.
  - amyjess 11y ago
    Eh, so many projects have been moving to DVCS for the last few years. Google Code shutting down is more recent than the trend towards DVCS.

belorn 11y ago

git has more or less completly taken over the mindshare from all other version control system.

nailer 11y ago
I think sometimes we forget that network effects outweigh most normal values of technical superiority. Let's say, for the purposes of the argument, that "hg/Mercurial is 20% better than git". This doesn't matter: hg/Mercurial has to be 500% better than git to be able to replace it. Look at the past changes: they've all been huge shifts in how we do version control, not minor improvements The DVCSs were 500% better than Subversion (wow, distributed!) Subversion was 500% better than CVS (wow, renames work! Branching is easy! http support!) CVS was 500% better than RCS (wow, we can check out files concurrently)
- octo_t 11y ago
  > Branching is easy when svn first came out (and up until a few years ago) branching was definitely not easy!
  - lfowles 11y ago
    What changed a few years ago?
    - anonydsfsfs 11y ago
      Subversion 1.5 added support for tracking merges: https://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking https://subversion.apache.org/docs/release-notes/1.5.html#me... Before this, merging branches was a huge pain, because you had to manually keep track of the commits that needed to be merged.
- threeseed 11y ago
  You are right. But it is often referred to as the 10x rule. http://www.minidisc.org/econ113-paper.htm http://www.minidisc.org/econ113-paper.htm A technology needs to be 10x better than a previous one for widespread adoption. It has successfully explained many failed technologies and products.
  - kazinator 11y ago
    > A technology needs to be 10x better than a previous one for widespread adoption. It has successfully explained many failed technologies and products. A hypothesis about failure, on the other hand, has to account for the failures and successes. This one doesn't. While it can plausibly explain failed technologies and products, it doesn't explain the historic success of junk that is worse than its predecessors. A technology can be hyped into widespread adoption. It can be dumped on the market for widespread adoption. It can ride on top of cheap hardware for widespread adoption. It can be bundled with something else, achieving widespread adoption. A technology can be falsely evaluated as 10X better by a large number of complete idiots, resulting in widespread adoption among idiots, resulting in pressure for non-idiots to adopt. All these effects can overcome the barrier of having to be actually, objectively 10X better. The "10X better adoption barrier" is only faced by honestly promoted technologies whose campaign consists of "try this because it's better for these objective reasons".

lfowles 11y ago

irssi moved to git (github even) to encourage contributions.

davidgerard 11y ago
LMMS http://lmms.io http://lmms.io was on svn on Sourceforge. It was more or less moribund. Moved to git on github, immediate influx of contributors and a buggy 0.4.13 was advanced to a really very nice 1.0 in about six months :-) Unless your project is weighty enough to have its own gravitational pull, github is a ridiculously easy place to contribute and make life easy for contributors.

deleted 11y ago

[deleted]

kazinator 11y ago

> Vim is moving to git, GCC is moving to git. What's with all the change? Git does something very well: it has great support for rewriting version histories. It nearly flawlessly supports almost every conceivable scenario of slicing, dicing, mixing and combining. It also has great support for working at the sub-file granularity. For instance, this morning I moved a fix from an experimental branch to stable. The fix was part of a huge commit, and consisted of just a few "hunks" out of many in one file. It was obvious that the particular fix, though needed by the experimental changes, could be promoted to stable (it was a change of the kind where some code is altered in such a way that it no longer interacts with the experimental changes, and is improved at the same time.) With git I easily rewrote that big commit such that just those specific changes in the specific file were removed from that commit. This was done without touching anything in the working copy not so much as altering any modification timestamp! ("make" didn't even see that anything needed to be rebuilt after the commit rewrite.) In git we can do "keep my working copy as it is, but alter the history behind it, so those alterations then appear as staged, uncommitted changes". Then we can easily migrate the changes somewhere, like turning it into its own commit, perhaps on another branch. After I migrated those changes to master, I then went back to that branch and did a "git rebase". Lo and behold, that branch picked up the changes, and now it looks as if those changes were written on master all along, before the experimental changes were developed. Programmers need this kind of thing because we are obsessed about making the perfect set of changes. Since the history of a code base is a digital artifact, we want to be able to hack that artifact to perfection too, not just the instantaneous/current view of the code itself. Git is also like an adventure game in which you solve quests and acquire higher and higher status. This creates allure. The Novice Adventurer cannot understand all the reasons why the Grandmaster Wizards of GCC have switched to Git, but is mystified and fascinated.

nephyrin 11y ago
Rewriting public branch history is not generally used by any major project except in extreme circumstances. This reads like an attempt at satire by someone who doesn't understand the actual utility of history rewriting in git, which is generally for extending version control to your development changes (e.g. what is more formally codified in Mercurial as the draft phase).

spiralpolitik 11y ago

In the case of the Gnu projects it was pointed out the futility of continuing to maintain GNU Bazaar when there were at least two more widely used DVCS (git and hg).

jahewson 11y ago

Bazaar is dead, it's no longer maintained and hasn't had a release in 3 years.

kazinator 11y ago
So are you saying it doesn't work? What issues are you having with Bazaar that require a new release? I couldn't care less if Git stopped making releases; what I'm using isn't the latest anyway and does everything I want. (Though I'd like any newly discovered security holes to be fixed in any pieces of Git that face the Internet; e.g. via embedding in CGIT).