7 ms·

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973

by anon35 3y ago

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange memory to them, they look at me funny. It's a wonderful tool and earned its success, but I'll be sad if it's our final take on the problem.

deleted 3y ago
[deleted]
test1235 3y ago
So it looks like you're ready for a change ... What's next on the horizon?
- Zacharias030 3y ago
  Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. I have introduced a stacked PR workflow to our team a while ago and a few months later half of the team had migrated to some kind of stacked PR workflow tool (on top of github and git, even though support is sub-optimal). It seems like this is an idea that is really sticky. [0] https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack
  - eru 3y ago
    > I also wonder, how much better git could be if it was based on DAGs not trees [...] Git generally supports DAGs. > [...] corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. Rebasing is something you do to the commit graph, which is a DAG. Branches only come in incidentally. Branches in git are really just mutable pointer to immutable commits. What you are describing is probably some useful workflow, I guess?
    - seba_dos1 3y ago
      Not only it's useful, it's as easy to do in git as typing `git rebase -r`. Recently it even gained support for rewriting branch pointers in the process.
      - marcandre 3y ago
        Do you mean it can rewrite branch pointers that pointed to intermediate commits? How?
        seba_dos1 3y ago
        --update-refs
      - eru 3y ago
        In general, it's almost always better to use long options. So that would be `git rebase --rebase-merges` in this case. Almost always means: it's better eg when communicating with other humans, whether that's on a forum like HN or in code or scripts. Long options are easier for humans to understand and to 'google'. They also provide some redundancy against typos. The sole exception, where short options can be useful, is when you are actually using a command line interactively. Use short options to your heart's content there.
    - lloeki 3y ago
      I seem to understand GP wants to move a whole DAG potentially having multiple leaves, not just a DAG ending at a single leaf. IOW git rebase --onto shaX shaY shaZ ends at shaZ, git walks backwards from it until the commit whose parent is shaY to produce the list of commits to cherry-pick onto shaX So presumably this would be useful: git rebase --onto shaX shaY [shaZ1 shaZ2 shaZ3 ...] with shaZn being optional and consisting of all leaves down from shaY This is achievable with git but it's not just doing n rebases like so: git rebase --onto shaX shaY shaZ1 git rebase --onto shaX shaY shaZ2 git rebase --onto shaX shaY shaZ3 ... because each rebase would produce different commits for parts that are common to shaZ n1 and shaZn2 ancestry, so one would have to first find all the branching points and do partial rebases onto the rebased parent commits in order. It definitely can be done (manually or automatically) but is not as trivial as one might think.
  - seba_dos1 3y ago
    > (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) Not sure if you realize, but a commit is a state of all files in the repository, not a patch. Patches are calculated for you at display time (and can be calculated against any other commit, not just a parent). Sounds like you may be confused because of trying to apply a wrong mental model of how the repository represents things. I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard.
    - tempay 3y ago
      > I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard. I agree that the model does but I’m not aware of any good way of using such a workflow with the CLI either. Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?
      - pravus 3y ago
        > Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches? This is the problem. You cannot rebase with a stacked PR flow. The correct way to do this is use the merge command as intended. One of the most powerful features of git is the ability to understand a common history between multiple parties and everyone throws this away entirely with a rebase and causes non-stop conflicts. I simply do not understand the preference for it, especially in shared repos. Do not use a rebase workflow with any work that is shared with others unless you are communicating regularly and understand how obliterating your commit history will change how git views what is changed between two repositories. Rebase only works well if you are in a leaf branch you control and even then I prefer a single squash merge back into upstream rather than multiple rebases if possible. I can't even tell you how much of my life has been lost correcting merge conflicts caused by bad rebasing of my commits by others.
    - kps 3y ago
      > Not sure if you realize, but a commit is a state of all files in the repository, not a patch. I think that's a core problem. It's not just that git calculates a patch to show you, it's that — in every git-using project I've seen — a developer writes a patch, and writes a commit message describing that patch. It's not just github. And then developers make the incorrect assumption that git's later presentation of the commit as a patch matches the original patch and is accurately described by the commit message.
quietbritishjim 3y ago
In fairness, the rate of change of any type of tool slows down over time as the problem domain becomes well understood. It's like the Joel on Software article (which annoyingly I can't find at the moment) about how software is always pretty much done by about version 4. His example was office software, especially Excel, and sure enough if you loaded Excel 4 today you'd see it does fundamentally all the main things. I suspect we'll see git last at least double the length of time as those other VCS tools.
- paulddraper 3y ago
  > software is always pretty much done by about version 4 IPv4 has entered the chat
- eru 3y ago
  I think mostly it will depend on what we will call the replacement to git. We might end up calling it 'git', too. Less weirdly: ethernet has been replaced a few times already, but they always just end up branding the replacement as a new version of 'ethernet'.
  - bombcar 3y ago
    Many of those variations of ethernet remain compatible, 10g switches can often negotiate down to 10/100.
    - eru 3y ago
      Yes. And the replacement to git might also stay compatible. (In an extreme case, git can talk svn via git-svn. In a weird alternative history, you could imagine git being treated as a new version of svn; but apart from the names, nothing much else would change compared to our universe.)
    - yardie 3y ago
      I’ve worked with many switches. I have not encountered a 10g switch that will negotiate to 10m. 100m is not automatic in most cases. These very old protocols are very different from modern 10g-100g. So much so that the transceivers may need to load a completely different firmware to even understand it.
brmgb 3y ago
I migrated a project from clearcase to git at my first company and for all the hate I have for clearcase even I agree there was little point in switching to something else before. We had a bit of svn on other part of the company but that was it. VCS don’t change that fast. All the tools you list before the advent of DVCS actually have a lot in common. I think git will be there for some time.
bonzini 3y ago
Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs. Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs. There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.
- FLT8 3y ago
  > Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs. I wouldn't be surprised if some of the work and rigour being invested in OTs and CRDTs, and multi-user collaborative editing in general leads to some breakthrough improvements in the source control space too.
  - llwu 3y ago
    Aren't CRDTs the logical conclusion of automatic merging? I feel like with source control you want to be more intentional about what gets merged, right? Maybe CRDT can be good for trunk-based development with a merge queue. Definitely has a spot in pair programming.
- GabrielTFS 3y ago
  > I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout. Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.
mattbillenstein 3y ago
Point could be made people don't really use git anymore - they use github as the primary interface. Branching, merging, review, etc.
- paulddraper 3y ago
  I've never seen as the primary workflow. It's handy, especially if you're using Git as a CMS or something like that.
- medstrom 3y ago
  How many people know GitHub can do that? Your comment was the first I'd heard about it.
  - gumby 3y ago
    I suspect it’s the opposite way around: most people, when they hear “git”, macroexpand it to “github” and don’t even know that there is a (more powerful) command-line interface. The peer-peer distributed nature is barely known — these days it’s a centralized client/server system. I remember the Internet connection going out at work a few years ago and developers saying they couldn’t coordinate bc github was not accessible when they could easily have synced, merged etc with each other directly.
    - 8n4vidtmkvmk 3y ago
      My partner definitely does not know the difference between Git and GitHub. He's not much of a programmer but yeah.. maybe this is like Java vs JS all over again. Or jQuery vs JS. That one makes me extra sad.
- datavirtue 3y ago
  The only git GUI I use is GitLens. I have always found the command line much easier to understand...and the GUIs make me nervous.
sbochins 3y ago
I don’t know what we’ll be using 15 years from now. But the thing that is really sad in your list is that you stopped using mercurial in 2015, but still use git to this day.
amadeuspagel 3y ago
The internet tends to lock things in. There were many languages dominant in history at some point or another, english will be the final one. There were many scripting languages, javascript will be the final one. Many networking protocols, TCP/IP the final one. Same for git. I think the only thing that might displace git is some environment for new programmers with its own version control system like glitch[1]. [1]: https://medium.com/glitch/reinventing-version-control-with-glitch-rewind-914c350da442 https://medium.com/glitch/reinventing-version-control-with-g...
- p-e-w 3y ago
  > The internet tends to lock things in. More generally, a globally connected civilization locks things in, once they are sufficiently widespread. Barring an apocalypse, our present is eternity. I'm always amused when I read science fiction that assumes in the future, Chinese will be the lingua franca, or that we'll have political offices modeled after Ancient Rome, or that there's a world government, or similar nonsense. To paraphrase O'Brien from 1984: "If you want a picture of the future, imagine a crony-capitalist, meme- and outrage-driven society that always seems on the brink of collapse but never actually does collapse – forever."
  - sidpatil 3y ago
    > More generally, a globally connected civilization locks things in, once they are sufficiently widespread. This idea is known as the end of history. https://en.m.wikipedia.org/wiki/End_of_history https://en.m.wikipedia.org/wiki/End_of_history
- qsantos 3y ago
  > There were many scripting languages, javascript will be the final one If, by “scripting languages”, you mean “browser-native languages”, WebAssembly might become a serious contender as the lingua franca for the Web in the long term.

by anon35 3y ago

deleted 3y ago

[deleted]

test1235 3y ago

So it looks like you're ready for a change ... What's next on the horizon?

Zacharias030 3y ago
Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. I have introduced a stacked PR workflow to our team a while ago and a few months later half of the team had migrated to some kind of stacked PR workflow tool (on top of github and git, even though support is sub-optimal). It seems like this is an idea that is really sticky. [0] https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack
- eru 3y ago
  > I also wonder, how much better git could be if it was based on DAGs not trees [...] Git generally supports DAGs. > [...] corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. Rebasing is something you do to the commit graph, which is a DAG. Branches only come in incidentally. Branches in git are really just mutable pointer to immutable commits. What you are describing is probably some useful workflow, I guess?
  - seba_dos1 3y ago
    Not only it's useful, it's as easy to do in git as typing `git rebase -r`. Recently it even gained support for rewriting branch pointers in the process.
    - marcandre 3y ago
      Do you mean it can rewrite branch pointers that pointed to intermediate commits? How?
      - seba_dos1 3y ago
        --update-refs
    - eru 3y ago
      In general, it's almost always better to use long options. So that would be `git rebase --rebase-merges` in this case. Almost always means: it's better eg when communicating with other humans, whether that's on a forum like HN or in code or scripts. Long options are easier for humans to understand and to 'google'. They also provide some redundancy against typos. The sole exception, where short options can be useful, is when you are actually using a command line interactively. Use short options to your heart's content there.
  - lloeki 3y ago
    I seem to understand GP wants to move a whole DAG potentially having multiple leaves, not just a DAG ending at a single leaf. IOW git rebase --onto shaX shaY shaZ ends at shaZ, git walks backwards from it until the commit whose parent is shaY to produce the list of commits to cherry-pick onto shaX So presumably this would be useful: git rebase --onto shaX shaY [shaZ1 shaZ2 shaZ3 ...] with shaZn being optional and consisting of all leaves down from shaY This is achievable with git but it's not just doing n rebases like so: git rebase --onto shaX shaY shaZ1 git rebase --onto shaX shaY shaZ2 git rebase --onto shaX shaY shaZ3 ... because each rebase would produce different commits for parts that are common to shaZ n1 and shaZn2 ancestry, so one would have to first find all the branching points and do partial rebases onto the rebased parent commits in order. It definitely can be done (manually or automatically) but is not as trivial as one might think.
- seba_dos1 3y ago
  > (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) Not sure if you realize, but a commit is a state of all files in the repository, not a patch. Patches are calculated for you at display time (and can be calculated against any other commit, not just a parent). Sounds like you may be confused because of trying to apply a wrong mental model of how the repository represents things. I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard.
  - tempay 3y ago
    > I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard. I agree that the model does but I’m not aware of any good way of using such a workflow with the CLI either. Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?
    - pravus 3y ago
      > Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches? This is the problem. You cannot rebase with a stacked PR flow. The correct way to do this is use the merge command as intended. One of the most powerful features of git is the ability to understand a common history between multiple parties and everyone throws this away entirely with a rebase and causes non-stop conflicts. I simply do not understand the preference for it, especially in shared repos. Do not use a rebase workflow with any work that is shared with others unless you are communicating regularly and understand how obliterating your commit history will change how git views what is changed between two repositories. Rebase only works well if you are in a leaf branch you control and even then I prefer a single squash merge back into upstream rather than multiple rebases if possible. I can't even tell you how much of my life has been lost correcting merge conflicts caused by bad rebasing of my commits by others.
  - kps 3y ago
    > Not sure if you realize, but a commit is a state of all files in the repository, not a patch. I think that's a core problem. It's not just that git calculates a patch to show you, it's that — in every git-using project I've seen — a developer writes a patch, and writes a commit message describing that patch. It's not just github. And then developers make the incorrect assumption that git's later presentation of the commit as a patch matches the original patch and is accurately described by the commit message.

quietbritishjim 3y ago

In fairness, the rate of change of any type of tool slows down over time as the problem domain becomes well understood. It's like the Joel on Software article (which annoyingly I can't find at the moment) about how software is always pretty much done by about version 4. His example was office software, especially Excel, and sure enough if you loaded Excel 4 today you'd see it does fundamentally all the main things. I suspect we'll see git last at least double the length of time as those other VCS tools.

paulddraper 3y ago
> software is always pretty much done by about version 4 IPv4 has entered the chat
eru 3y ago
I think mostly it will depend on what we will call the replacement to git. We might end up calling it 'git', too. Less weirdly: ethernet has been replaced a few times already, but they always just end up branding the replacement as a new version of 'ethernet'.
- bombcar 3y ago
  Many of those variations of ethernet remain compatible, 10g switches can often negotiate down to 10/100.
  - eru 3y ago
    Yes. And the replacement to git might also stay compatible. (In an extreme case, git can talk svn via git-svn. In a weird alternative history, you could imagine git being treated as a new version of svn; but apart from the names, nothing much else would change compared to our universe.)
  - yardie 3y ago
    I’ve worked with many switches. I have not encountered a 10g switch that will negotiate to 10m. 100m is not automatic in most cases. These very old protocols are very different from modern 10g-100g. So much so that the transceivers may need to load a completely different firmware to even understand it.

brmgb 3y ago

I migrated a project from clearcase to git at my first company and for all the hate I have for clearcase even I agree there was little point in switching to something else before. We had a bit of svn on other part of the company but that was it. VCS don’t change that fast. All the tools you list before the advent of DVCS actually have a lot in common. I think git will be there for some time.

bonzini 3y ago

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs. Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs. There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.

FLT8 3y ago
> Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs. I wouldn't be surprised if some of the work and rigour being invested in OTs and CRDTs, and multi-user collaborative editing in general leads to some breakthrough improvements in the source control space too.
- llwu 3y ago
  Aren't CRDTs the logical conclusion of automatic merging? I feel like with source control you want to be more intentional about what gets merged, right? Maybe CRDT can be good for trunk-based development with a merge queue. Definitely has a spot in pair programming.
GabrielTFS 3y ago
> I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout. Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.

mattbillenstein 3y ago

Point could be made people don't really use git anymore - they use github as the primary interface. Branching, merging, review, etc.

paulddraper 3y ago
I've never seen as the primary workflow. It's handy, especially if you're using Git as a CMS or something like that.
medstrom 3y ago
How many people know GitHub can do that? Your comment was the first I'd heard about it.
- gumby 3y ago
  I suspect it’s the opposite way around: most people, when they hear “git”, macroexpand it to “github” and don’t even know that there is a (more powerful) command-line interface. The peer-peer distributed nature is barely known — these days it’s a centralized client/server system. I remember the Internet connection going out at work a few years ago and developers saying they couldn’t coordinate bc github was not accessible when they could easily have synced, merged etc with each other directly.
  - 8n4vidtmkvmk 3y ago
    My partner definitely does not know the difference between Git and GitHub. He's not much of a programmer but yeah.. maybe this is like Java vs JS all over again. Or jQuery vs JS. That one makes me extra sad.
datavirtue 3y ago
The only git GUI I use is GitLens. I have always found the command line much easier to understand...and the GUIs make me nervous.

sbochins 3y ago

I don’t know what we’ll be using 15 years from now. But the thing that is really sad in your list is that you stopped using mercurial in 2015, but still use git to this day.

amadeuspagel 3y ago

The internet tends to lock things in. There were many languages dominant in history at some point or another, english will be the final one. There were many scripting languages, javascript will be the final one. Many networking protocols, TCP/IP the final one. Same for git. I think the only thing that might displace git is some environment for new programmers with its own version control system like glitch[1]. [1]: https://medium.com/glitch/reinventing-version-control-with-glitch-rewind-914c350da442 https://medium.com/glitch/reinventing-version-control-with-g...

p-e-w 3y ago
> The internet tends to lock things in. More generally, a globally connected civilization locks things in, once they are sufficiently widespread. Barring an apocalypse, our present is eternity. I'm always amused when I read science fiction that assumes in the future, Chinese will be the lingua franca, or that we'll have political offices modeled after Ancient Rome, or that there's a world government, or similar nonsense. To paraphrase O'Brien from 1984: "If you want a picture of the future, imagine a crony-capitalist, meme- and outrage-driven society that always seems on the brink of collapse but never actually does collapse – forever."
- sidpatil 3y ago
  > More generally, a globally connected civilization locks things in, once they are sufficiently widespread. This idea is known as the end of history. https://en.m.wikipedia.org/wiki/End_of_history https://en.m.wikipedia.org/wiki/End_of_history
qsantos 3y ago
> There were many scripting languages, javascript will be the final one If, by “scripting languages”, you mean “browser-native languages”, WebAssembly might become a serious contender as the lingua franca for the Web in the long term.