5 ms·

Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague"

Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. It will likely come as part of an integrated work environment (some collaborative cloud workflow thing) in order to bypass git's role as gatekeeper/rite of passage for developers.

Slackwise 6y ago
That's more a case of UI rather than implementation, yeah? What's stopping us from just using those words to describe operations with Git? I mean, what Git is, is a data structure with a set of operations on it, and the design of that is pretty fundamental at this point. We'd need to see something more novel[1]. (Sidenote: Git almost seemed an obvious trajectory for version control given how problematic file-based approaches have been. I've used far too many version control systems, including "ancient" awful ones like Harvest[2], and it just felt inevitable that we'd one day rely on an "always-branching" model.) [1]: I did think of something more novel: semantic version control (https://news.ycombinator.com/item?id=25537455 https://news.ycombinator.com/item?id=25537455) [2]: https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Manager https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Man...
- UncleMeat 6y ago
  UX matters. Databases aren’t just data structures and their operations. They do compete based on interaction patterns and metaphors. VC can do the same.
  - Slackwise 6y ago
    I don't know a single database that is identical to another in implementation and just has a different UI/UX for it. Every single database has something specific for it in terms of implementation. (Unless I guess we're talking forks of MySQL.) I don't know if maybe you have a good example...?
    - GoblinSlayer 6y ago
      Git changed its implementation with time too.
      - alblue 6y ago
        Not really. Under the covers, it has always been an object database where the objects key is the hash of that object, and other than blob, tree, commit and signed tag they haven’t really changed since then. The protocol has become a bit smarter, by allowing there to be additional options passed for different communications options, and there is a slow but steady progress of moving from sha1 to sha256 for the hash function, but that isn’t rolled out yet completely. Different tools have been added over time but the internals are pretty much the same as they’ve always been.
  - rualca 6y ago
    >>UX matters. Of that was the case then how come Git reigns supreme in spite of the lack of a polished UI/UX?
    - UncleMeat 6y ago
      It isn't the only thing that matters.
    - orev 6y ago
      Git won because it was created by Linus and Linux moved to it, and that brought it a huge amount of publicity. Then GitHub came along and cemented its place.
  - inshadows 6y ago
    Why don't you create your own wrapper that replaces names you don't like with pretty names you like? You can as well promote it, get lots of stars on GitHub and ultimately create official Git wrapper for your kind of people. It doesn't seem too difficult. I think it could be a single shell file.
- IshKebab 6y ago
  > What's stopping us from just using those words to describe operations with Git? The huge existing body of documentation, tutorials, StackOverflow questions, etc. that use the confusing standard Git terminology.
gct 6y ago
lol no
dividedbyzero 6y ago
I feel like not having a git for human consumption is a huge missed opportunity, and I do hope something like that will arrive soon-ish. People in software development seem to not realize at all just how abysmally awful git's UX really is. Explaining git to a non-developer person who just wants me to assist with a python issue always feels a lot like explaing thermodynamics to someone who just wants to boil a kettle of water; yeah, sure, not interested, I've just sent you the file by email, please have a look. I feel like making collaboration less painful has been the greatest innovation driver in the last few decades, and has paid off absolutely enormously. Imagine where a git/Github for other disciplines could take us. Given software developers build such tools, and given software developers overwhelmingly know how neat git really is, it's actually kinda strange that there's still such a dearth of good solutions in this space.
- 6510 6y ago
  I'm like that. My own way of working involves files in folders and old versions of anything are overwritten or deleted. If they still exist it indicate an unfinished job. I don't keep draft versions of letters and emails either. I would love to collaborate but when I start looking into git the amount of stuff I don't fully understand keeps growing. I should want something in my work flow that I don't understand? If it stops working just like that, the way everything seems to, I'm suppose to fix something that I don't understand? When trying to figure out how it worked I read discussions from truly experienced users who decades into the process apparently still had to learn now to unstuck themselves. I'm not saying its bad at what it does. Its much worse, I have no idea what the point is. It seems tailored to manage top of the developer pyramid issues that I imagine to be hard enough to justify its existence. In applications I've seen copies of data get modified in different places then merged back together again. Its a horror movie!
  - ptx 6y ago
    > I have no idea what the point is. As a lone developer, it lets you easily snapshot the state of your code at appropriate points and then compare those to the current state to find out what you broke. Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file. The real benefit is when you have more than one developer working on the program. If you make some changes on your machine, and I make some changes on my machine, and when we're done we want a single unified version of the program (with both your changes and mine) in order to deploy it, what should that look like? If all we can see is that line 123 in some file is different in your version and my version, how do we know which version of that line we want? Git keeps track of (in the form of a graph structure) the fact than your version 1 is a descendant of our original version, your version 2 descends from your version 1, my version 1 descends from the original version, and so on ... and when we merge our versions, we get a final version that descends both from your latest version and mine. You could do all this bookkeeping manually and figure out what to diff against what, but git gives you tools to work with.
u801e 6y ago
> Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. If that were actually the case, then the dominant programming language today would be COBOL, rather than anything we have now.
- bird_monster 6y ago
  Given how much COBOL is still in production, I suppose it depends entirely on your definition of "dominant" ?
  - renox 6y ago
    Given that if you are starting a new project now, you'd almost never even consider using Cobol, that would be a very weird definition of 'dominant'..
    - bird_monster 6y ago
      To me, dominant is defined by lines of code currently in production. The difference between my example vs. what you defined, is that hype and/or popularity determine what people use for _new_ projects. But that doesn't really assess how dominant a language has been in the past (or even in production currently). Java is another dominant language that you might not use for a new project. Same with C.
      - tatersolid 6y ago
        > To me, dominant is defined by lines of code currently in production. That definition biases towards verbose languages with lots of headers and boilerplate code (e.g. C++, Java)
      - renox 6y ago
        > Java is another dominant language that you might not use for a new project. Same with C I would very much consider using Java for a new project, same with C(1) if the project is in "real time" (I think that C++ hides too much things under the rug which can create latency issue). 1: Zig isn't ready yet to be a replacement
rualca 6y ago
> Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Those are the usecases that Git already handles. Each and every single one of them. Somehow you conspicuously left branching out of it, which is the main value added by any version control system along with merging. Thus I really don't see the point of arguing that Git will be replaced by a tool that does exactly what Git has been doing by design since it was released.
Gibbon1 6y ago
I think what will kill git is integration with language servers and IDE's. The reason is git and everything before it doesn't capture high level change/refactoring information. You really want to record, mapped X to Y. Not 500 files changed in 4218 places.
- matt-attack 6y ago
  Darcs supports “replace” semantics where you can rename a variable say across the whole project with just as you suggest, a single meaningful commit.
  - Gibbon1 6y ago
    That's interesting I'll check that out.
knighthack 6y ago
Hasn't there been many attempts of that sort over the years? I recall some similar efforts being made to simplify Git for use with writers, etc.

Slackwise 6y ago

That's more a case of UI rather than implementation, yeah? What's stopping us from just using those words to describe operations with Git? I mean, what Git is, is a data structure with a set of operations on it, and the design of that is pretty fundamental at this point. We'd need to see something more novel[1]. (Sidenote: Git almost seemed an obvious trajectory for version control given how problematic file-based approaches have been. I've used far too many version control systems, including "ancient" awful ones like Harvest[2], and it just felt inevitable that we'd one day rely on an "always-branching" model.) [1]: I did think of something more novel: semantic version control (https://news.ycombinator.com/item?id=25537455 https://news.ycombinator.com/item?id=25537455) [2]: https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Manager https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Man...

UncleMeat 6y ago
UX matters. Databases aren’t just data structures and their operations. They do compete based on interaction patterns and metaphors. VC can do the same.
- Slackwise 6y ago
  I don't know a single database that is identical to another in implementation and just has a different UI/UX for it. Every single database has something specific for it in terms of implementation. (Unless I guess we're talking forks of MySQL.) I don't know if maybe you have a good example...?
  - GoblinSlayer 6y ago
    Git changed its implementation with time too.
    - alblue 6y ago
      Not really. Under the covers, it has always been an object database where the objects key is the hash of that object, and other than blob, tree, commit and signed tag they haven’t really changed since then. The protocol has become a bit smarter, by allowing there to be additional options passed for different communications options, and there is a slow but steady progress of moving from sha1 to sha256 for the hash function, but that isn’t rolled out yet completely. Different tools have been added over time but the internals are pretty much the same as they’ve always been.
- rualca 6y ago
  >>UX matters. Of that was the case then how come Git reigns supreme in spite of the lack of a polished UI/UX?
  - UncleMeat 6y ago
    It isn't the only thing that matters.
  - orev 6y ago
    Git won because it was created by Linus and Linux moved to it, and that brought it a huge amount of publicity. Then GitHub came along and cemented its place.
- inshadows 6y ago
  Why don't you create your own wrapper that replaces names you don't like with pretty names you like? You can as well promote it, get lots of stars on GitHub and ultimately create official Git wrapper for your kind of people. It doesn't seem too difficult. I think it could be a single shell file.
IshKebab 6y ago
> What's stopping us from just using those words to describe operations with Git? The huge existing body of documentation, tutorials, StackOverflow questions, etc. that use the confusing standard Git terminology.

gct 6y ago

lol no

dividedbyzero 6y ago

I feel like not having a git for human consumption is a huge missed opportunity, and I do hope something like that will arrive soon-ish. People in software development seem to not realize at all just how abysmally awful git's UX really is. Explaining git to a non-developer person who just wants me to assist with a python issue always feels a lot like explaing thermodynamics to someone who just wants to boil a kettle of water; yeah, sure, not interested, I've just sent you the file by email, please have a look. I feel like making collaboration less painful has been the greatest innovation driver in the last few decades, and has paid off absolutely enormously. Imagine where a git/Github for other disciplines could take us. Given software developers build such tools, and given software developers overwhelmingly know how neat git really is, it's actually kinda strange that there's still such a dearth of good solutions in this space.

6510 6y ago
I'm like that. My own way of working involves files in folders and old versions of anything are overwritten or deleted. If they still exist it indicate an unfinished job. I don't keep draft versions of letters and emails either. I would love to collaborate but when I start looking into git the amount of stuff I don't fully understand keeps growing. I should want something in my work flow that I don't understand? If it stops working just like that, the way everything seems to, I'm suppose to fix something that I don't understand? When trying to figure out how it worked I read discussions from truly experienced users who decades into the process apparently still had to learn now to unstuck themselves. I'm not saying its bad at what it does. Its much worse, I have no idea what the point is. It seems tailored to manage top of the developer pyramid issues that I imagine to be hard enough to justify its existence. In applications I've seen copies of data get modified in different places then merged back together again. Its a horror movie!
- ptx 6y ago
  > I have no idea what the point is. As a lone developer, it lets you easily snapshot the state of your code at appropriate points and then compare those to the current state to find out what you broke. Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file. The real benefit is when you have more than one developer working on the program. If you make some changes on your machine, and I make some changes on my machine, and when we're done we want a single unified version of the program (with both your changes and mine) in order to deploy it, what should that look like? If all we can see is that line 123 in some file is different in your version and my version, how do we know which version of that line we want? Git keeps track of (in the form of a graph structure) the fact than your version 1 is a descendant of our original version, your version 2 descends from your version 1, my version 1 descends from the original version, and so on ... and when we merge our versions, we get a final version that descends both from your latest version and mine. You could do all this bookkeeping manually and figure out what to diff against what, but git gives you tools to work with.

u801e 6y ago

> Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. If that were actually the case, then the dominant programming language today would be COBOL, rather than anything we have now.

bird_monster 6y ago
Given how much COBOL is still in production, I suppose it depends entirely on your definition of "dominant" ?
- renox 6y ago
  Given that if you are starting a new project now, you'd almost never even consider using Cobol, that would be a very weird definition of 'dominant'..
  - bird_monster 6y ago
    To me, dominant is defined by lines of code currently in production. The difference between my example vs. what you defined, is that hype and/or popularity determine what people use for _new_ projects. But that doesn't really assess how dominant a language has been in the past (or even in production currently). Java is another dominant language that you might not use for a new project. Same with C.
    - tatersolid 6y ago
      > To me, dominant is defined by lines of code currently in production. That definition biases towards verbose languages with lots of headers and boilerplate code (e.g. C++, Java)
    - renox 6y ago
      > Java is another dominant language that you might not use for a new project. Same with C I would very much consider using Java for a new project, same with C(1) if the project is in "real time" (I think that C++ hides too much things under the rug which can create latency issue). 1: Zig isn't ready yet to be a replacement

rualca 6y ago

> Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Those are the usecases that Git already handles. Each and every single one of them. Somehow you conspicuously left branching out of it, which is the main value added by any version control system along with merging. Thus I really don't see the point of arguing that Git will be replaced by a tool that does exactly what Git has been doing by design since it was released.

Gibbon1 6y ago

I think what will kill git is integration with language servers and IDE's. The reason is git and everything before it doesn't capture high level change/refactoring information. You really want to record, mapped X to Y. Not 500 files changed in 4218 places.

matt-attack 6y ago
Darcs supports “replace” semantics where you can rename a variable say across the whole project with just as you suggest, a single meaningful commit.
- Gibbon1 6y ago
  That's interesting I'll check that out.

knighthack 6y ago

Hasn't there been many attempts of that sort over the years? I recall some similar efforts being made to simplify Git for use with writers, etc.