5 ms·

Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with

Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point. I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out professionally. Obviously now that I have over a decade of professional experience I think it's a no brainer, but I don't think it's natural to understand it as it's suggested to you. I at least kind of had to go along with it and trust that it's good. It felt frustrating at first as many other things are. Git as a thing was FAR more difficult for me to understand in my 20s than PHP and how to do anything with it was for me at teens. Coding is raw logic, Git is about imagining teamwork at scale, which is a whole other thing. The funny thing is that I feel like I was overall still more productive when I was at my teens building stuff solo with FileZilla and PHP, compared to a corporate environment now with all the processes and 1000s of engineers.

acchow 2y ago
> Git is not a natural development at all. Obviously, it is a standard right now. Most standard tools we use today are not obvious to beginners nor would they be the first thing that beginners reach for. But senior developers can understand the problems that they claim to address, and why they are important and common problems.
- cubano 2y ago
  You wouldn't believe the amount of crap I take whenever I introduce very basic version control at the various 3 to 6 man shops I find work at these days. I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git.
  - wink 2y ago
    This could have been written and 2014 and 2004 (hi, it's me). There will always be people who don't use it and others who won't remember a time when they hadn't used it :P
    - pasc1878 2y ago
      Add 1984 to that list of dates. We used PVCS on MSDOS By 1994 I had moved to other companies and a NeXT equivalent to svn with a good GUI - and then ClearCase.
      - buddhu 2y ago
        Hello, fellow old person. I was just remembering PVCS (Polytron Version Control System) since it was the first I worked with back in the 80s. Now I see that it's still out there, with the latest release in 2021. Which is insane.
  - throw0101c 2y ago
    > I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git. Have you considered introducing Mercurial or even Subversion? While Git may be a kind of an industry 'standard', if you're starting from zero, some of its concepts may be a bit mind-bending for folks, and it has often been commented that Hg seems to have a more beginner-friendly interface. And if branching isn't going to be used (a large strength of git/hg), then Subversion may have an even simpler mental model (svn of course does branching, but the others are more optimized for it). If folks are doing FTP-push deployment, then moving to 'just' SVN-push (commit) deployment can be an improvement.
  - ahazred8ta 2y ago
    There was a new hire who was told to make a small change in a piece of server software, found the repo, read the docs, made the change, ran it in testing, and pushed to prod. Cue the 'senior engineer' screaming bloody blue murder because he'd been directly monkeypatching the servers for 3 years with no vc and no backups.
    - Calamitous 2y ago
      That’s… not a senior engineer. Whatever his title may have been.
- coldtea 2y ago
  >But senior developers can understand the problems that they claim to address, and why they are important and common problems. Senior developers have simply grown accustomed to the warts, and accepted their fate - some even celebrating their mastery of the warts as necessary knowledge. The only pragmatic reason not to change things is the compatibility chaos that will ensue and the resources required - not that problems don't exist.
  - fijiaarone 2y ago
    > some even celebrating their mastery of the warts as necessary knowledge. Hi git fans!
bsder 2y ago
> Git is not a natural development at all. Obviously, it is a standard right now. Git is actually an unnatural development. Its UI is atrocious. And it worked like crap on Windows for forever. Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got out of their way and was generally fine. Then Github won due to VC cash dumping and foisted Git on all of us. Source control was no longer fine. Thankfully, there is now Jujutsu(jj) which works on top of the Git storage layer so you can forget about the craptastic UI of Git. Source control is now fine again.
- chris_wot 2y ago
  git didn't win because of GitHub. Sure, GitHub helped a lot. But actually, it's because its a DVCS, and it does branching and merging way better than anything I've seen so far. You can thank BitKeeper for all of this, and Andrew Tridgwell for forcing Linus Torvalds into creating git.
  - jsmeaton 2y ago
    You don’t think if the company behind GitHub went all-in on mercurial that might have emerged as the winner? There were plenty of companies using either. Git wasn’t the only distributed game in town. I definitely think GitHub had a lot to do with it.
    - oooyay 2y ago
      Before there was GitHub there was Sourceforge. Sourceforge supported several different protocols and git still won. Gits internals can be confusing at first, but once you understand them there's really nothing you can't do. Being distributed by design also helps.
      - fragmede 2y ago
        yeah, git is just the right layer of indirection to support everyone's weird take on how the workflow should go, so you can just use it however you want.
gumby 2y ago
> Why is it astonishingly? Git is still a baby as these things go. Software version control systems go back to the early 1960s and descended from manual processes used to manage documents in large organizations, blueprints, and such from the early 20th century. Don’t imagine the Manhattan Project functioned by just passing around bundles of paper! There were staffs of people whose job was to manage document control! And I don’t mean “control” in the sense of secrecy, but making sure everybody was on the the same revision at the same time. And for a field so steeped in building its own tools and automating human effort in development it is indeed astonishing revision control took so long to be accepted.
treflop 2y ago
I don’t know if I agree that it’s unnatural. It only takes doing index73.php and index_old3.php for a few months and then eventually screwing up (unless you’re perfect) to realize how dumb putting numbers and _old4 at the end of names is. Then at that point, you naturally go look if there’s a better way.
- medstrom 2y ago
  Yes, so you invent CVS, not git.
  - actionfromafar 2y ago
    You invent VMS versioned files, and RCS. :)
    - gumby 2y ago
      BTW file versioning in the filesystem predated the development of VMS by about 15 years, RCS by about 20.
      - amszmidt 2y ago
        (indirect reference ITS and TENEX ... :-))
- cruffle_duffle 2y ago
  > Then at that point, you naturally go look if there’s a better way. That might be true now but it wasn’t always. Plenty of shops didn’t have any version control at all. And the build was whatever came off your local dev box. And “local dev box” wasn’t even a term…
tomjen3 2y ago
Git is pretty unnatural, but CVS? That is much closer to the "copy a shared file back and forth between people", except with nice things such as "keep track of who is editing what", "know what the latest edition is", and "keep track of the history". That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files.
- llm_trw 2y ago
  >That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files. Oh no, we're in a different time zone. >We'll put the timezone in. Oh no, it's daylight savings time.
  - mewpmewp2 2y ago
    To be fair that's easy, just always use UTC for everyone. Or just the unix timestamp in seconds or millis if you want to be safer.
  - phatskat 2y ago
    But someone works in Arizona!
  - tomjen3 2y ago
    Entirely besides the point I was trying to make. I wasn’t trying to say that it’s a good idea for a team, but that git is complicated. Too complicated for beginners.
- necovek 2y ago
  Ouch, please don't. Anything else like bzr or hg or svn will be easier to grasp than git, can work locally too (IIRC for Subversion) and not much harder than zip files — don't get them used to the wrong mental model and bad habits.
mardifoufs 2y ago
Well yeah for hobby use you're right that it is "normal" that it took a long time to get there. But professional use is completely different. That's the part they are referring to I'd say.
protomolecule 2y ago
>Git is not a natural development at all. It's a false dichotomy. Before git there were other version managements systems which would've fit your use case much better than git. Subversion is the easiest perhaps.

acchow 2y ago

> Git is not a natural development at all. Obviously, it is a standard right now. Most standard tools we use today are not obvious to beginners nor would they be the first thing that beginners reach for. But senior developers can understand the problems that they claim to address, and why they are important and common problems.

cubano 2y ago
You wouldn't believe the amount of crap I take whenever I introduce very basic version control at the various 3 to 6 man shops I find work at these days. I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git.
- wink 2y ago
  This could have been written and 2014 and 2004 (hi, it's me). There will always be people who don't use it and others who won't remember a time when they hadn't used it :P
  - pasc1878 2y ago
    Add 1984 to that list of dates. We used PVCS on MSDOS By 1994 I had moved to other companies and a NeXT equivalent to svn with a good GUI - and then ClearCase.
    - buddhu 2y ago
      Hello, fellow old person. I was just remembering PVCS (Polytron Version Control System) since it was the first I worked with back in the 80s. Now I see that it's still out there, with the latest release in 2021. Which is insane.
- throw0101c 2y ago
  > I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git. Have you considered introducing Mercurial or even Subversion? While Git may be a kind of an industry 'standard', if you're starting from zero, some of its concepts may be a bit mind-bending for folks, and it has often been commented that Hg seems to have a more beginner-friendly interface. And if branching isn't going to be used (a large strength of git/hg), then Subversion may have an even simpler mental model (svn of course does branching, but the others are more optimized for it). If folks are doing FTP-push deployment, then moving to 'just' SVN-push (commit) deployment can be an improvement.
- ahazred8ta 2y ago
  There was a new hire who was told to make a small change in a piece of server software, found the repo, read the docs, made the change, ran it in testing, and pushed to prod. Cue the 'senior engineer' screaming bloody blue murder because he'd been directly monkeypatching the servers for 3 years with no vc and no backups.
  - Calamitous 2y ago
    That’s… not a senior engineer. Whatever his title may have been.
coldtea 2y ago
>But senior developers can understand the problems that they claim to address, and why they are important and common problems. Senior developers have simply grown accustomed to the warts, and accepted their fate - some even celebrating their mastery of the warts as necessary knowledge. The only pragmatic reason not to change things is the compatibility chaos that will ensue and the resources required - not that problems don't exist.
- fijiaarone 2y ago
  > some even celebrating their mastery of the warts as necessary knowledge. Hi git fans!

bsder 2y ago

> Git is not a natural development at all. Obviously, it is a standard right now. Git is actually an unnatural development. Its UI is atrocious. And it worked like crap on Windows for forever. Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got out of their way and was generally fine. Then Github won due to VC cash dumping and foisted Git on all of us. Source control was no longer fine. Thankfully, there is now Jujutsu(jj) which works on top of the Git storage layer so you can forget about the craptastic UI of Git. Source control is now fine again.

chris_wot 2y ago
git didn't win because of GitHub. Sure, GitHub helped a lot. But actually, it's because its a DVCS, and it does branching and merging way better than anything I've seen so far. You can thank BitKeeper for all of this, and Andrew Tridgwell for forcing Linus Torvalds into creating git.
- jsmeaton 2y ago
  You don’t think if the company behind GitHub went all-in on mercurial that might have emerged as the winner? There were plenty of companies using either. Git wasn’t the only distributed game in town. I definitely think GitHub had a lot to do with it.
  - oooyay 2y ago
    Before there was GitHub there was Sourceforge. Sourceforge supported several different protocols and git still won. Gits internals can be confusing at first, but once you understand them there's really nothing you can't do. Being distributed by design also helps.
    - fragmede 2y ago
      yeah, git is just the right layer of indirection to support everyone's weird take on how the workflow should go, so you can just use it however you want.

gumby 2y ago

> Why is it astonishingly? Git is still a baby as these things go. Software version control systems go back to the early 1960s and descended from manual processes used to manage documents in large organizations, blueprints, and such from the early 20th century. Don’t imagine the Manhattan Project functioned by just passing around bundles of paper! There were staffs of people whose job was to manage document control! And I don’t mean “control” in the sense of secrecy, but making sure everybody was on the the same revision at the same time. And for a field so steeped in building its own tools and automating human effort in development it is indeed astonishing revision control took so long to be accepted.

treflop 2y ago

I don’t know if I agree that it’s unnatural. It only takes doing index73.php and index_old3.php for a few months and then eventually screwing up (unless you’re perfect) to realize how dumb putting numbers and _old4 at the end of names is. Then at that point, you naturally go look if there’s a better way.

medstrom 2y ago
Yes, so you invent CVS, not git.
- actionfromafar 2y ago
  You invent VMS versioned files, and RCS. :)
  - gumby 2y ago
    BTW file versioning in the filesystem predated the development of VMS by about 15 years, RCS by about 20.
    - amszmidt 2y ago
      (indirect reference ITS and TENEX ... :-))
cruffle_duffle 2y ago
> Then at that point, you naturally go look if there’s a better way. That might be true now but it wasn’t always. Plenty of shops didn’t have any version control at all. And the build was whatever came off your local dev box. And “local dev box” wasn’t even a term…

tomjen3 2y ago

Git is pretty unnatural, but CVS? That is much closer to the "copy a shared file back and forth between people", except with nice things such as "keep track of who is editing what", "know what the latest edition is", and "keep track of the history". That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files.

llm_trw 2y ago
>That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files. Oh no, we're in a different time zone. >We'll put the timezone in. Oh no, it's daylight savings time.
- mewpmewp2 2y ago
  To be fair that's easy, just always use UTC for everyone. Or just the unix timestamp in seconds or millis if you want to be safer.
- phatskat 2y ago
  But someone works in Arizona!
- tomjen3 2y ago
  Entirely besides the point I was trying to make. I wasn’t trying to say that it’s a good idea for a team, but that git is complicated. Too complicated for beginners.
necovek 2y ago
Ouch, please don't. Anything else like bzr or hg or svn will be easier to grasp than git, can work locally too (IIRC for Subversion) and not much harder than zip files — don't get them used to the wrong mental model and bad habits.

mardifoufs 2y ago

Well yeah for hobby use you're right that it is "normal" that it took a long time to get there. But professional use is completely different. That's the part they are referring to I'd say.

protomolecule 2y ago

>Git is not a natural development at all. It's a false dichotomy. Before git there were other version managements systems which would've fit your use case much better than git. Subversion is the easiest perhaps.