18 ms·

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me w

by tasuki 7y ago

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

brylie 7y ago
The interface is arguably the most important part. I.e. it is a tool developed for humans to use, so would ideally have simple, consistent, and by extension intuitive ergonomics. Elegance of internal implementation is secondary.
- kortilla 7y ago
  The interface can be swapped out if the underlying storage is fine. There is nothing preventing you from writing a different front end where “checkout” doesn’t do all the things.
  - afiori 7y ago
    Yet no one is doing it.
  - baud147258 7y ago
    > There is nothing preventing you from writing a different front end Or you could just use a tool where the interface is fine out of the box
  - wyoung2 7y ago
    Which is why there are dozens of Git front-ends, fragmenting the market, reducing the benefit of cross-training within a team. "Oh, you can't do that in your TortoiseStudioCodeThingy? I just right-click and select Frobnicate File, and it fixes all that!" Thus editor wars, language wars... Alternative: a tool like Fossil where the CLI is sensible from jump so the whole team doesn't replace it with something better, uniquely per team member.
matsemann 7y ago
People have probably been happy with their tools for centuries. Just because one cannot imagine something better doesn't mean there's no possibility for it to exist. If anything, this defeatist attitude may prove the author right.
- tazjin 7y ago
  > defeatist attitude This implies that the parent's sentiment about git is negative. At least I personally feel very positively about git and am not missing much from it.
  - matsemann 7y ago
    > This implies that the parent's sentiment about git is negative. No, I meant defeatist as in "I have given up finding something better as it will never exist".
    - n0rbwah 7y ago
      If the tool you have works well for your use case, looking for and learning to use a "better tool" can be a waste of your time with little benefit.
      - matsemann 7y ago
        Maybe, but that has nothing to do with my point.
      - madmulita 7y ago
        And that's how you can get stuck in a local maximum.
        SketchySeaBeast 7y ago
        With the exception of very very singular people, isn't every maximum going to be local? Even then they'll be stuck in a bunch of other local maximum's outside their own area of expertise.
alkonaut 7y ago
I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, branches are references to commits, and what about a) a detatched head? b) what if you based it off an intermediate branch and that branch is deleted? c) what if... 5 more answers go on to say "just use this alias!" [answer continues with a 200 character zsh alias that anyone on windows, the most common desktop OS, has no idea what to do with]. I don't want to write aliases. I usually don't want to consider the edge cases. If I have 2 long lived branches version-1.0 and master. I want to know whether my feature branch is based on master or version-1.0 and it's an absolute shitshow. Yes it's possible, but is it simple? Is it elegant? No. The 80/20 (or 99/1) use case is - centralized workflow. - "blessed" branches like master and long lived feature branches that should ALWAYS show up as more important in hisory graphs. - short lived branches like feature branches that should always show up as side tracks in history graphs. Try to explain to an svn user why the git history for master looks like a zigzag spiderweb just because you merged a few times between master and a few feature branches. Not a single tool I know does a nice straight (svn style swimlane) history graph because it doesn't consider branch importance, when it should be pretty simple to implement simply by configuring what set of branches are "important".
- dragonwriter 7y ago
  > I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. That's what UIs (whether CLIs or otherwise) for standardized workflows like git-flow are, IMO.
  - alkonaut 7y ago
    It doesn't nearly go all the way there though. Why do people need to use a command line and a gui tool (usually) for git? Because it's fundamentally not written to be used with a GUI. That I think is one of its biggest flaws. Using a GUI with git always feels like you are missing vital information and just trying to poke a cli underneath to do what you want. Some design decisions also shine through like "no branch is more important than any other branch" which is completely mental considering how people actually use git.
yodsanklai 7y ago
I hope it's the last DVCS, if it can save me the hassle of learning a new one. There is some learning curve, but it works just fine once you know how to use it.
- javajosh 7y ago
  Over time you realize there are no transient states. You cannot neglect, for example, complex install just because it "happens once". Nothing ever happens just once. You will always have to reinstall, probably multiple times. So when people say the same thing about installation complexity, they are being naive. In the same way, learning is not a transient state either. You will always have to relearn. Those impossible barriers that you eventually got through will reduce to speedbumps - but they will always be there, slowing you down. And if you don't use it enough, you'll have to relearn. Also, be aware that once you've climbed a learning curve, at least unconsciously you are no longer incentivized to simplify it for those who come after. Why reduce the barrier-to-entry for others, after all? You got through it, so why can't they? And this is why generations of kids learn bad music theory, and generations of physicists learn bad particle names. It's important to be aware of this effect so you can counter-act it.
- mschaef 7y ago
  > I hope it's the last DVCS, The only reason I'd disagree is if the next source code control system were somehow as much an improvement over git as git was over its predecessors. > if it can save me the hassle of learning a new one. Not to mention the hassle of converting all those legacy repositories, converting CI/CD, etc.
tomesch1982 7y ago
Git is neither easy not is it really elegant. It is useful for projects like Linux™ but for the vast majority of projects way better tools like mercurial or fossil would be a much better fit.
- ehnto 7y ago
  It's been immensely useful in every software project I have ever partaken in. None of them were like linux.
  - mcv 7y ago
    It is immensely useful. That doesn't mean that some other tool might not be better for most cases. I love git, and don't know most other post-SVN version control systems, but I do recognise the complaints people have about git. There's clearly still room for improvement.
- peteretep 7y ago
  > way better tools I work with a group of people who all know enough git that we're productive, and a few of us know enough git to solve complicated problem. I've not seriously considered fossil or mercurial -- what are the top three tangible benefits I'd get from them getting our team to switch?
  - tomesch1982 7y ago
    That is exactly the point. For git you need the ecosystem to cope with it's shortcomings and in addition some experts to help you out of the pickles this software gets you into. I mainly use fossil for personal projects. Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management. The setup is ridiculously easy and everyone always has everything in the repository. In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on. And fossil has a sane command-line interface so that everyone in the team is expert enough to work with it. No need for heroes that save the day from git fricking everything up.
baq 7y ago
here's me sincerely hoping for pijul and/or darcs to deliver something much better. (obviously if it's only a little better then there isn't much point in switching.)
- supportlocal4h 7y ago
  I was hopeful for pijul. But the more time passes without any noticeable progress or traction the less hope I have.
baud147258 7y ago
If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.
- chiefalchemist 7y ago
  Agreed. If the applications we built using git were as awkward as git...our users and clients would scream, or worse.
  - P_I_Staker 7y ago
    I don't understand the relevance of git in all of that
- mschaef 7y ago
  > If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work with directories is a problem of the git approach. Having a nice offline story is a distinct advantage.) > And personally I prefer a VCS with less ways to shoot myself in the foot than git. Oddly, the thing I love about git is how easy it makes it to recover from mistakes. Even if there are more ways to shoot yourself in the foot, there are also more ways to put your foot back exactly the way it was before you shot it. (If only real life worked that way!) This is what the immutable content storage under the hood of a git repository gets you. If you know the commit hash (and there are a bunch of ways to easily keep track of these), you can get back to the state that's represented by that hash. Commands like merge/rebase/cherry-pick make this particularly easy by providing an '--abort' option that means "I've screwed this operation up beyond repair and need to bail out." And the abort works. As long as you had your target state committed, you can get back to it. (And if that's just a transient state that you don't want to persist, it's easy enough to squash it into something coherent.)
vnorilo 7y ago
After using darcs, I can never see Git as elegant, no matter how clearly it is a more pragmatic choice these days.
- matt-attack 7y ago
  I agree. I’m always embarrassed to say that I still use darcs but it’s just entirely obvious how to use it. There is no mystery. The choice to prompt the user for thing makes usability insanely high. Yes it’s slow for large projects but honestly I just deal with that.
  - cjallen88 7y ago
    Have you looked at Pijul? I understand it has resolved the major shortcomings of Darcs.
phkahler 7y ago
>> The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Agreed. Technology should converge on a best solution so we can stop chasing things and get work done. Stable open source standard solutions are what we need more of. Some anti-pattern examples are C++ and Vulcan.
- stcg 7y ago
  > Some anti-pattern examples are C++ and Vulcan. Are you referring to the Vulkan API? If so, why do you see it as an anti-pattern example? I like the API and I think it is a great and necessary improvement over OpenGL. I actually hope to see Vulkan become the ‘stable open source standard solution’ for graphics.
  - phkahler 7y ago
    Maybe I should have said OpenGL since it keeps getting new versions. Does Vulcan? It just seems like kronos keeps moving the target.
- anoncake 7y ago
  You want technology to converge without changing? That's impossible.
Tade0 7y ago
To me it's proof that we as an industry finally arrived at a consensus over something.
- richie_adler 7y ago
  Yeah, but it's like Betamax losing to VHS.
oswamano 7y ago
Honestly if we can reduce the tooling churn for development that sounds great
kick 7y ago
git is like a dozen Perl and shell scripts taped together with a tiny bit of Tcl on the side. It is nowhere near elegant. It's a monstrosity.
P_I_Staker 7y ago
Yup, doesn't sound like a negative to me. People will still try to build simpler ecosystems like GitLab/GitHub/Atlassian, with similarly mixed results.

by tasuki 7y ago

brylie 7y ago

The interface is arguably the most important part. I.e. it is a tool developed for humans to use, so would ideally have simple, consistent, and by extension intuitive ergonomics. Elegance of internal implementation is secondary.

kortilla 7y ago
The interface can be swapped out if the underlying storage is fine. There is nothing preventing you from writing a different front end where “checkout” doesn’t do all the things.
- afiori 7y ago
  Yet no one is doing it.
- baud147258 7y ago
  > There is nothing preventing you from writing a different front end Or you could just use a tool where the interface is fine out of the box
- wyoung2 7y ago
  Which is why there are dozens of Git front-ends, fragmenting the market, reducing the benefit of cross-training within a team. "Oh, you can't do that in your TortoiseStudioCodeThingy? I just right-click and select Frobnicate File, and it fixes all that!" Thus editor wars, language wars... Alternative: a tool like Fossil where the CLI is sensible from jump so the whole team doesn't replace it with something better, uniquely per team member.

matsemann 7y ago

People have probably been happy with their tools for centuries. Just because one cannot imagine something better doesn't mean there's no possibility for it to exist. If anything, this defeatist attitude may prove the author right.

tazjin 7y ago
> defeatist attitude This implies that the parent's sentiment about git is negative. At least I personally feel very positively about git and am not missing much from it.
- matsemann 7y ago
  > This implies that the parent's sentiment about git is negative. No, I meant defeatist as in "I have given up finding something better as it will never exist".
  - n0rbwah 7y ago
    If the tool you have works well for your use case, looking for and learning to use a "better tool" can be a waste of your time with little benefit.
    - matsemann 7y ago
      Maybe, but that has nothing to do with my point.
    - madmulita 7y ago
      And that's how you can get stuck in a local maximum.
      - SketchySeaBeast 7y ago
        With the exception of very very singular people, isn't every maximum going to be local? Even then they'll be stuck in a bunch of other local maximum's outside their own area of expertise.

alkonaut 7y ago

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, branches are references to commits, and what about a) a detatched head? b) what if you based it off an intermediate branch and that branch is deleted? c) what if... 5 more answers go on to say "just use this alias!" [answer continues with a 200 character zsh alias that anyone on windows, the most common desktop OS, has no idea what to do with]. I don't want to write aliases. I usually don't want to consider the edge cases. If I have 2 long lived branches version-1.0 and master. I want to know whether my feature branch is based on master or version-1.0 and it's an absolute shitshow. Yes it's possible, but is it simple? Is it elegant? No. The 80/20 (or 99/1) use case is - centralized workflow. - "blessed" branches like master and long lived feature branches that should ALWAYS show up as more important in hisory graphs. - short lived branches like feature branches that should always show up as side tracks in history graphs. Try to explain to an svn user why the git history for master looks like a zigzag spiderweb just because you merged a few times between master and a few feature branches. Not a single tool I know does a nice straight (svn style swimlane) history graph because it doesn't consider branch importance, when it should be pretty simple to implement simply by configuring what set of branches are "important".

dragonwriter 7y ago
> I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. That's what UIs (whether CLIs or otherwise) for standardized workflows like git-flow are, IMO.
- alkonaut 7y ago
  It doesn't nearly go all the way there though. Why do people need to use a command line and a gui tool (usually) for git? Because it's fundamentally not written to be used with a GUI. That I think is one of its biggest flaws. Using a GUI with git always feels like you are missing vital information and just trying to poke a cli underneath to do what you want. Some design decisions also shine through like "no branch is more important than any other branch" which is completely mental considering how people actually use git.

yodsanklai 7y ago

I hope it's the last DVCS, if it can save me the hassle of learning a new one. There is some learning curve, but it works just fine once you know how to use it.

javajosh 7y ago
Over time you realize there are no transient states. You cannot neglect, for example, complex install just because it "happens once". Nothing ever happens just once. You will always have to reinstall, probably multiple times. So when people say the same thing about installation complexity, they are being naive. In the same way, learning is not a transient state either. You will always have to relearn. Those impossible barriers that you eventually got through will reduce to speedbumps - but they will always be there, slowing you down. And if you don't use it enough, you'll have to relearn. Also, be aware that once you've climbed a learning curve, at least unconsciously you are no longer incentivized to simplify it for those who come after. Why reduce the barrier-to-entry for others, after all? You got through it, so why can't they? And this is why generations of kids learn bad music theory, and generations of physicists learn bad particle names. It's important to be aware of this effect so you can counter-act it.
mschaef 7y ago
> I hope it's the last DVCS, The only reason I'd disagree is if the next source code control system were somehow as much an improvement over git as git was over its predecessors. > if it can save me the hassle of learning a new one. Not to mention the hassle of converting all those legacy repositories, converting CI/CD, etc.

tomesch1982 7y ago

Git is neither easy not is it really elegant. It is useful for projects like Linux™ but for the vast majority of projects way better tools like mercurial or fossil would be a much better fit.

ehnto 7y ago
It's been immensely useful in every software project I have ever partaken in. None of them were like linux.
- mcv 7y ago
  It is immensely useful. That doesn't mean that some other tool might not be better for most cases. I love git, and don't know most other post-SVN version control systems, but I do recognise the complaints people have about git. There's clearly still room for improvement.
peteretep 7y ago
> way better tools I work with a group of people who all know enough git that we're productive, and a few of us know enough git to solve complicated problem. I've not seriously considered fossil or mercurial -- what are the top three tangible benefits I'd get from them getting our team to switch?
- tomesch1982 7y ago
  That is exactly the point. For git you need the ecosystem to cope with it's shortcomings and in addition some experts to help you out of the pickles this software gets you into. I mainly use fossil for personal projects. Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management. The setup is ridiculously easy and everyone always has everything in the repository. In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on. And fossil has a sane command-line interface so that everyone in the team is expert enough to work with it. No need for heroes that save the day from git fricking everything up.

baq 7y ago

here's me sincerely hoping for pijul and/or darcs to deliver something much better. (obviously if it's only a little better then there isn't much point in switching.)

supportlocal4h 7y ago
I was hopeful for pijul. But the more time passes without any noticeable progress or traction the less hope I have.

baud147258 7y ago

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

chiefalchemist 7y ago
Agreed. If the applications we built using git were as awkward as git...our users and clients would scream, or worse.
- P_I_Staker 7y ago
  I don't understand the relevance of git in all of that
mschaef 7y ago
> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work with directories is a problem of the git approach. Having a nice offline story is a distinct advantage.) > And personally I prefer a VCS with less ways to shoot myself in the foot than git. Oddly, the thing I love about git is how easy it makes it to recover from mistakes. Even if there are more ways to shoot yourself in the foot, there are also more ways to put your foot back exactly the way it was before you shot it. (If only real life worked that way!) This is what the immutable content storage under the hood of a git repository gets you. If you know the commit hash (and there are a bunch of ways to easily keep track of these), you can get back to the state that's represented by that hash. Commands like merge/rebase/cherry-pick make this particularly easy by providing an '--abort' option that means "I've screwed this operation up beyond repair and need to bail out." And the abort works. As long as you had your target state committed, you can get back to it. (And if that's just a transient state that you don't want to persist, it's easy enough to squash it into something coherent.)

vnorilo 7y ago

After using darcs, I can never see Git as elegant, no matter how clearly it is a more pragmatic choice these days.

matt-attack 7y ago
I agree. I’m always embarrassed to say that I still use darcs but it’s just entirely obvious how to use it. There is no mystery. The choice to prompt the user for thing makes usability insanely high. Yes it’s slow for large projects but honestly I just deal with that.
- cjallen88 7y ago
  Have you looked at Pijul? I understand it has resolved the major shortcomings of Darcs.

phkahler 7y ago

>> The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Agreed. Technology should converge on a best solution so we can stop chasing things and get work done. Stable open source standard solutions are what we need more of. Some anti-pattern examples are C++ and Vulcan.

stcg 7y ago
> Some anti-pattern examples are C++ and Vulcan. Are you referring to the Vulkan API? If so, why do you see it as an anti-pattern example? I like the API and I think it is a great and necessary improvement over OpenGL. I actually hope to see Vulkan become the ‘stable open source standard solution’ for graphics.
- phkahler 7y ago
  Maybe I should have said OpenGL since it keeps getting new versions. Does Vulcan? It just seems like kronos keeps moving the target.
anoncake 7y ago
You want technology to converge without changing? That's impossible.

Tade0 7y ago

To me it's proof that we as an industry finally arrived at a consensus over something.

richie_adler 7y ago
Yeah, but it's like Betamax losing to VHS.

oswamano 7y ago

Honestly if we can reduce the tooling churn for development that sounds great

kick 7y ago

git is like a dozen Perl and shell scripts taped together with a tiny bit of Tcl on the side. It is nowhere near elegant. It's a monstrosity.

P_I_Staker 7y ago

Yup, doesn't sound like a negative to me. People will still try to build simpler ecosystems like GitLab/GitHub/Atlassian, with similarly mixed results.