5 ms·

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only b

by trashb 6mo ago

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much focused on supporting alternatives to "one person, one branch, one terminal, one linear flow". > the problem that Git has solved for the last 20 years is overdue for a redesign. To me it's not clear what the problem is that would require a redesign.

MidnightRider39 6mo ago
The problem is how to make money from something that is more or less solved.
- mervz 6mo ago
  Yep, something that is sadly becoming more and more common. People with solutions spending insane money trying to convince others that a problem exists.
  - luqtas 6mo ago
    have you heard startups
  - BobbyTables2 6mo ago
    The beauty of it all is one doesn’t even have to invent a solution… they only have to invent a “problem” to be pitched for VC funding.
  - bloppe 6mo ago
    I'm gonna go out on a limb and say these guys would never have raised if they didn't have "GitHub co-founder" on the first slide of the pitch deck
    - siva7 6mo ago
      Ok, that explains everything. Who you know in the Valley is everything. Literally.
      - jschrf 6mo ago
        It's why fail fast is a thing
  - easterncalculus 6mo ago
    It's basically the entire context of this website.
- MagicMoonlight 6mo ago
  It’s not solved because it’s trash. There’s no good interface for it and people find it difficult to use.
  - 000ooo000 6mo ago
    Skill issue. It's the most popular VCS in the world by a huge margin, millions of devs use it every day just fine, countless forges have been built around it, and there's only one semi-compelling alternative frontend (jj). If you honestly find Git challenging, how are you coping with software engineering? Git is the easy part.
    - feelamee 6mo ago
      sure, but solving conflicts is still hard in git. This can be simplified.
    - Cpoll 6mo ago
      Millions of dev use it in the most rudimentary way, occasionally lose their stash, rm their local repo and start over, ask the office expert for help every time they need to figure out where-the-foxtrot that commit came from, don't even attempt to use reflog or bisect or interactive staging, etc.
      - 000ooo000 6mo ago
        [flagged]
  - trashb 6mo ago
    I didn't think Github is that bad but if you think that is the case, why would you give the same guys 17M to try again instead of fix the existing?
    - brigandish 6mo ago
      Because experience is valuable.
- MikeNotThePope 6mo ago
  As a spoon designer, I have had some difficulty finding work lately.
- bcrl 6mo ago
  BitKeeper tried to do that. Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community. "Those who cannot remember the past are condemned to repeat it".
  - fsckboy 6mo ago
    >Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community. BitKeeper was free to linux kernel developers with a "but no reverse engineering" clause, but Tridgell went exploring of his own volition because he wanted to and kinda sorta violated that, so the license was cancelled by BitKeeper. I'm not taking sides or upset about any part of this, I just wouldn't call that "becoming unworkable for the linux kernel community"; that would be like "the fence around your yard became unworkable for me in my desire to trespass on your property so I climbed over it" what Tridgell discovered was pretty dumb and could be considered a distinct lack of a fence, but he connected to a socket and typed "help" and it dutifully printed out a bunch of undocumented useful commands.
sethev 6mo ago
More power to them for re-visiting this, but agree with you: > The old model assumed one person, one branch, one terminal, one linear flow. That sounds exactly like the pre-git model that git solved..
convolvatron 6mo ago
I've always wanted a kind of broader and more integrated approach that isn't just about text diffs. the ability to link in substantial comments that would be displayed optionally and not piss off linear readers. links to design and reference documents. bugs and prs that were persistent and linked to the versioned code instead of being ephemeral. think about all of the discussion we have around the code that gets lost. we certainly have the ability to keep and link all that stuff now. we don't really need to have arguments about squashing or not, we can just keep the fine grained commits if you really want to dig into them and maybe ask that people write a comprehensive summary of the changes in a patch set -in addition-. but I guess none of that has anythig to do with AI
da_chicken 6mo ago
> To me it's not clear what the problem is that would require a redesign. The interface is still bad. Teaching people to use git is still obnoxious because it's arcane. It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke. It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in the repository? Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else. It's also taken over 10 years to address the SHA-1 limitation, and it's still not complete. It's a little astonishing that it was written so focused on SHA-1 never being a problem that it's taken this long to keep the same basic design and just allow a different hashing algorithm.
- redsocksfan45 6mo ago
  [dead]
- chipsrafferty 6mo ago
  > Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else. I'm not a git expert but I cant image that's true
  - _3u10 6mo ago
    It’s not you just need to force push or generate a new key…
    - chipsrafferty 6mo ago
      Yeah it doesn't seem hard to rewrite the commit history
    - dgellow 6mo ago
      You also need to clear the caches of the remote
yomartin 6mo ago
[dead]
seanhunter 6mo ago
This is juicero for source control. The problem that requires a redesign is that vcs are unable to extract a subscription rent from some of the people who use git.
ChrisRR 6mo ago
If the interface isn't intuitive then it's not a solved problem

by trashb 6mo ago

MidnightRider39 6mo ago

The problem is how to make money from something that is more or less solved.

mervz 6mo ago
Yep, something that is sadly becoming more and more common. People with solutions spending insane money trying to convince others that a problem exists.
- luqtas 6mo ago
  have you heard startups
- BobbyTables2 6mo ago
  The beauty of it all is one doesn’t even have to invent a solution… they only have to invent a “problem” to be pitched for VC funding.
- bloppe 6mo ago
  I'm gonna go out on a limb and say these guys would never have raised if they didn't have "GitHub co-founder" on the first slide of the pitch deck
  - siva7 6mo ago
    Ok, that explains everything. Who you know in the Valley is everything. Literally.
    - jschrf 6mo ago
      It's why fail fast is a thing
- easterncalculus 6mo ago
  It's basically the entire context of this website.
MagicMoonlight 6mo ago
It’s not solved because it’s trash. There’s no good interface for it and people find it difficult to use.
- 000ooo000 6mo ago
  Skill issue. It's the most popular VCS in the world by a huge margin, millions of devs use it every day just fine, countless forges have been built around it, and there's only one semi-compelling alternative frontend (jj). If you honestly find Git challenging, how are you coping with software engineering? Git is the easy part.
  - feelamee 6mo ago
    sure, but solving conflicts is still hard in git. This can be simplified.
  - Cpoll 6mo ago
    Millions of dev use it in the most rudimentary way, occasionally lose their stash, rm their local repo and start over, ask the office expert for help every time they need to figure out where-the-foxtrot that commit came from, don't even attempt to use reflog or bisect or interactive staging, etc.
    - 000ooo000 6mo ago
      [flagged]
- trashb 6mo ago
  I didn't think Github is that bad but if you think that is the case, why would you give the same guys 17M to try again instead of fix the existing?
  - brigandish 6mo ago
    Because experience is valuable.
MikeNotThePope 6mo ago
As a spoon designer, I have had some difficulty finding work lately.
bcrl 6mo ago
BitKeeper tried to do that. Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community. "Those who cannot remember the past are condemned to repeat it".
- fsckboy 6mo ago
  >Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community. BitKeeper was free to linux kernel developers with a "but no reverse engineering" clause, but Tridgell went exploring of his own volition because he wanted to and kinda sorta violated that, so the license was cancelled by BitKeeper. I'm not taking sides or upset about any part of this, I just wouldn't call that "becoming unworkable for the linux kernel community"; that would be like "the fence around your yard became unworkable for me in my desire to trespass on your property so I climbed over it" what Tridgell discovered was pretty dumb and could be considered a distinct lack of a fence, but he connected to a socket and typed "help" and it dutifully printed out a bunch of undocumented useful commands.

sethev 6mo ago

More power to them for re-visiting this, but agree with you: > The old model assumed one person, one branch, one terminal, one linear flow. That sounds exactly like the pre-git model that git solved..

convolvatron 6mo ago

I've always wanted a kind of broader and more integrated approach that isn't just about text diffs. the ability to link in substantial comments that would be displayed optionally and not piss off linear readers. links to design and reference documents. bugs and prs that were persistent and linked to the versioned code instead of being ephemeral. think about all of the discussion we have around the code that gets lost. we certainly have the ability to keep and link all that stuff now. we don't really need to have arguments about squashing or not, we can just keep the fine grained commits if you really want to dig into them and maybe ask that people write a comprehensive summary of the changes in a patch set -in addition-. but I guess none of that has anythig to do with AI

da_chicken 6mo ago

> To me it's not clear what the problem is that would require a redesign. The interface is still bad. Teaching people to use git is still obnoxious because it's arcane. It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke. It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in the repository? Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else. It's also taken over 10 years to address the SHA-1 limitation, and it's still not complete. It's a little astonishing that it was written so focused on SHA-1 never being a problem that it's taken this long to keep the same basic design and just allow a different hashing algorithm.

redsocksfan45 6mo ago
[dead]
chipsrafferty 6mo ago
> Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else. I'm not a git expert but I cant image that's true
- _3u10 6mo ago
  It’s not you just need to force push or generate a new key…
  - chipsrafferty 6mo ago
    Yeah it doesn't seem hard to rewrite the commit history
  - dgellow 6mo ago
    You also need to clear the caches of the remote

yomartin 6mo ago

[dead]

seanhunter 6mo ago

This is juicero for source control. The problem that requires a redesign is that vcs are unable to extract a subscription rent from some of the people who use git.

ChrisRR 6mo ago

If the interface isn't intuitive then it's not a solved problem