38 ms·

> For its part, Git was designed specifically to make software development distributed without a centralized site. Just yesterday I had to explain the basic pr

> For its part, Git was designed specifically to make software development distributed without a centralized site. Just yesterday I had to explain the basic premise/history of Git to a young intern. I had asked him if he was using Git to manage his little pet project the company gave him to play with. “No”, he replied, he didn’t know what the company’s policy was to posting code in public on GitHub. As I explained to him that “git init” was all he needed, no GitHub or even no repository on our local GitLab was necessary, his eyes grew wide: “But how does that work??” I’ve had to explain this same thing to multiple novice devs of various ages. It baffles me. I consider it one of the greatest ironies of software development today. It’s like explaining to people that they could just talk to each other using a thousand means, instead of having to communicate by netcasting at each other through some shared social media platform.

pabs3 4y ago
Are you saying they use GitHub (via the web editor?) but have never heard of Git? or don't know how Git works? or just don't know the Git CLI? or something else?
- lvncelot 4y ago
  I think many a junior just never initialized a repository, and 'git clone' is what they've used to "get a repository". So I would forgive them for thinking that a remote is needed for having a repository on their drive.
  - kertoip_1 4y ago
    IMO the issue here is just that people think of git as it was something like SVN where you need to have some kind of external server to host project. Which isn't surprising as most of the time (when you cooperate with others) you do exactly that: push changes to one server. Idea of decentralization and independent copies of repositories may not be easy to grasp for newbe, because it's really technical concept.
    - bmacho 4y ago
      IMO the "issue" that the concept of a free remote storage/backup makes sense, while doing random things on your own computer doesn't have much value for a lot of people. ".. you don't have to keep the previous versions, so it saves space? OK... No, I was talking about the real git."
    - cratermoon 4y ago
      How many people know that you can just run `git daemon`[1] to share your local repo (very insecurely, mind you) to anyone that can reach your machine? No central server needed. https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
- Kon-Peki 4y ago
  I have seen the same phenomenon where I work. However, I disagree with the implication that this is limited to young people. I know of a few people that are 50 and 60 years old, that have been using source control for 30+ years, that didn't have any idea that git and GitHub were different things. Now, they were easy to set right; the concepts are all familiar to them. My experience with younger folks that have never been outside the Windows world has been that it was a lot harder to make them understand. Young folks with a unix-y background were much easier.
apocalyptic0n3 4y ago
That scenario plays itself out time and time again. 1. Base technology arrives and is adopted en masse 2. Some entity wraps it in an easier-to-use interface 3. After some time, that interface becomes the de facto standard 4. Developers who started developing after #2 and especially #3 don't understand how the underlying technology works or even that the wrapper is just a wrapper I'm reminded of how many Juniors I trained that didn't know jQuery was itself just a Javascript library and not a language in and of itself. None of them knew much of any of the underlying Javascript it was wrapping. I'm seeing the same scenario play out with React and Vue right now as well.
- doliveira 4y ago
  I find this so weird, I always feel like I have to at least a bird's eye view of how bits and bytes are flowing through the system. Not that a lot of boxes I don't just label as "magic", but at least I need to know the box exists
  - colonelpopcorn 4y ago
    I'm having a difficult time picturing how these hypothetical juniors will fare without that underlying curiosity driving them forward. Likely they'll wash out of the industry or see enough success to be promoted to a management position.
- kitsunesoba 4y ago
  Is the takeaway here, then, to beat third parties to the punch when creating a new technology and include a first-party easy-to-use interface right out of the gate?
  - CRConrad 4y ago
    Yes and no, IMO. Yes, sure, that could be one useful strategy. But no, you can't demand it as some kind of mandatory component for a project to "count as a real FOSS project". And for git, especially... It's not as if an easy-to-use interface had ever been a priority there. ;-) What one could ask for from them, though, IMO, would be a website of their own where they at least explain what it is. Because if such a thing exists, I must have missed it. I mean, git-scm.whatever isn't that, is it? That feels more like... Idunno, it's actually Atlassian in a thin disguise, isn't it?
chrisan 4y ago
What is so baffling about explaining git to a novice? I'm more baffled that you are baffled about this. Git wasn't even invented yet when I was in school and I did not learn about SVN until my first programming job in 2001 where a senior explained it to me.
- dreamcompiler 4y ago
  I think the parent's point was that the intern knew about github and assumed git was github.
  - shrimp_emoji 4y ago
    I used to be confused by this. It's because "git" is in the name and GitHub is the first thing you encounter, so I was like, "oh, is git some command line extension of GitHub?" rather than the reverse. :D
    - cybrox 4y ago
      Well GitHub is just a hub for git projects, a git hub. Most people will get that.
    - leethargo 4y ago
      Similarly, as a youngling, I often confused GNU and Gnome, in particular because several popular (often GTK-based) applications from either started with `g`, eg GIMP, gedit, gparted.
joeyh 4y ago
Github has carefully nurtured this culture of centralization. It's a marvel of our times.
digitallyfree 4y ago
I actually (almost) got in trouble once for this because people thought I was posting code publicly on Github when I was merely creating a local repository in my home directory. I had to explain what Git was and how it was not Github.
- skeeter2020 4y ago
  The same thing happens with people who should know better that google or even the www is not "the internet"
  - CRConrad 4y ago
    How many of us have parents (or, OK, for all you youngsters: grandparents) that assume not only that the Web is the Internet, but that Facebook is the Web?
- jvanderbot 4y ago
  We had an intern push code that shall never be released publicly to a public repository after we asked him to "push it to our gitlab server". He just assumed there was only one gitlab server and it was the public one, I guess. That was a bit shocking to me. I started with local VCS only all the way up through school and work.
  - sreevisakh 4y ago
    You should assume that developers, especially interns know nothing about any technology until they had a thorough introduction. And you should anticipate any confusion they may have in the process. Once, I had to introduce most of the employees of a company to git and git hosting. They were trained from scratch to use git reasonably on the first day. Use of code hosts were taught only on the second day. They were taught hands-on on our internal host and on public server. None of them had any confusion over differences among git and different git hosts. While they did make some mistakes afterwards, none of those were based on total misconceptions.
    - 4y ago
throwk8s 4y ago
Why is it baffling? GitHub and GitLab have embraced and extended git so much that it is no longer independently visible to most users. If you didn't already know git was independent of the SaaS products, you'd have no reason to suspect it was independent.
- GTP 4y ago
  IMO the reason to suspect that git is independent from the SaaS products, is that you can create and commit (and merge and most other things) to a local repo without ever pushing it to GitHub or any other site.
- sreevisakh 4y ago
  It's baffling because practically all learning resources on git emphasize its decentralized nature. Even the online free book explains that several times. They never left me with any confusion regarding the difference between git and github, even though my first version control was the centralized subversion. I don't understand how any developer can learn git without this idea being drilled in constantly.
BeetleB 4y ago
2 years ago, while interviewing internally, I asked the team what VC they use. It was Team Foundation's proprietary VC (and not a DVCS). I mentioned to them that even MS recommends Git for Team Foundation's usage. "Well of course, MS invented Git!" Wrong on so many levels: 1. Conflating Github with Git. 2. They bought it, not invented/founded it. 3. Most importantly, MS's recommendation to use Git for TF existed long before they bought Github. Needless to say, I didn't join that team. Unfortunately, misconceptions like these, and a refusal to use Git[1] due to its complexity are quite common at the company - and it is one of the larger SW companies[2] in the country. [1] I'm OK with any DVCS. Even I prefer Mercurial to Git. But most of the company prefers SVN or TF's version control. In 2015, many teams had to be dragged kicking and screaming by IT from CVS to SVN. In 2015, when Git already dominated the world. [2] By number of employees with "SW <something>" in their title. Not by revenue, etc.
- prepend 4y ago
  > refusal to use Git[1] due to its complexity I kind of like this friction. If a software developer finds git too complex, that’s an important signal that I should minimize my exposure to them. I’d never work in a team that dumb, and I wouldn’t want any dependencies on their code. Of course there are other reasons not to use git, but complexity is not one.
  - cybrox 4y ago
    Working with git can become extremely complex if your workflow is bad. Not git's fault, though.
    - remram 4y ago
      Git is a very malleable tool, you can use branches for many purposes, do all kinds of complex merges (e.g. subtree, etc). I think it can be made to fit most workflows. The main issue is repository size, which is hard to get from bad workflows alone, with the exception of insistence on tracking large binary files in Git (rather than LFS, DVC, etc).
  - 4y ago
briffle 4y ago
I have had to have the same conversation with co-workers who have been developing for many years, but using tools like SVN, or similar Microsoft code repos that require a centralized repo.
itslennysfault 4y ago
I used to teach a coding bootcamp. I had over 100 students over about 2 years, and ran into this constantly despite my best effort to explain that git != github from day one. We even did an exercise where we just used git locally first and then later (on a different day) showed how you can push to github. It didn't seem to matter. People just decided that git = github and couldn't let go of that.
- spencerchubb 4y ago
  git --> github porn --> pornhub best explanation of github for noobs
  - GTP 4y ago
    Lol
  - sigg3 4y ago
    bat --> bathub
    - tcmart14 4y ago
      Wow, I didn't know that, that thing is supposed to be a hub for bats.... Learn something new every day!
  - dijit 4y ago
    That's actually an excellent way of explaining it. Though it's frustrating that it's pornhub specifically, because referencing pornography can be awkward or impractical in workplace contexts.
    - beardedetim 4y ago
      GrubHub?
      - mgkimsal 4y ago
brundolf 4y ago
I don't think it's fair to frame this as specific to GitHub, or even as a thing to wring hands over. New devs - especially those coming from bootcamps (I say this without judgement) - mostly start with practical skills. Industry-standard ways to just get things done. That's how you get a job, that's how you get off the ground. This goes beyond source-control; languages/frameworks, tooling, etc. You enter the territory - with your finite bandwidth for learning - where it's most immediately useful. And then over the years you move out from there, incorporating more and more nuance and detail and auxiliary knowledge. There's no need for moral panic. "Where it's most useful to start" has shifted, sure. But that's natural; I don't think it's a new phenomenon or in a fundamentally worse place than before. GitHub is a higher-level tool that makes you dramatically more productive than raw git on its own. The details will be filled in as they work their first job.
- masklinn 4y ago
  > New devs - especially those coming from bootcamps (I say this without judgement) - mostly start with practical skills. I wouldn't say that it's "especially those coming from bootcamps". Those coming from uni are no better IME.
  - brundolf 4y ago
    Depends on the uni. Mine focused on fundamentals, almost to a fault; we learned algorithmic complexity and relational normal-forms but never touched eg. JavaScript, Python, or - ironically - git. Practical skills were very much not the entrypoint; I had to learn most of that myself.
    - ryanmcbride 4y ago
      Yeah I had to learn Assembly in college. We also had to physically print out our C++ code and turn it in to the professor. Did it make me a better programmer? Maybe but to this day I still haven't had to use it. Most of my practical skills I picked up on the job. P.S. I've seen the professor grading the printed out programs and he'd do it by flipping to the last page which was supposed to have the result output, and then fold the corner of the papers so it looked like he read the whole thing and then put a grade on the top. It was pretty funny.
mrits 4y ago
git isn't easy to understand. I think the real irony is I spent the first decade of my career teaching senior engineers how to use distributive version control. So many older guys decided to just use the SVN shim instead of learn something new and useful.
rzwitserloot 4y ago
Going through security certification procedure, I was asked to list all the third party SAAS things we use. I didn't include github, gitlab, or anything else, because we don't use it. The auditor was going off on a tirade about how lack of version control is not okay at all, so convinced they were that 'no github or gitlab' must therefore mean 'no version control'. The mind boggles. He barely believed me when I showed how git just syncs with other git repos and that's really the start and end of it. This has actually gotten me into thinking about a few things. What a web site 'backed' by your git repo seems to get you is: * Some insights to those who don't have a full git dump. Mostly irrelevant. * CI stuff and hook processing, but this does not need to be done by the system that hosts git, or even a dedicated system in the first place. * An issue tracker that nicely links together and that auto-updates when you commit with messages like 'fixes #1234'. * Code signoff/review coordination. And all of that should be possible __with git__, no? If you have a policy that all code must be signed off otherwise it isn't allowed to be in the commit tree of your `main`, `deploy` or whatever you prefer to call it branch, then why not just say that a reviewer makes a commit that has no changes (git allows this with the right switches), _JUST_ a commit message that includes 'I vouch for this', signed by the reviewer? And that _IS_ the review? What if issue tickets are text files that show up in git, to close a ticket you make a commit that deletes it. Or even: Not text files at all, but branches where the commit messages forms the conversation about the issue, and the changes in the commits are what you're doing to address it (write a test case that reproduces the issue, then fix it, for example), and you close a ticket by removing the branch from that git repo that everybody uses as origin? Then all you really need is some lightweight read only web frontend so that the non-technically-savvy folks can observe progress on tickets in a nice web thingie perhaps, if that. But it's just a stateless web frontend that reads git commit trees and turns them into pretty HTML, really. Commit hooks to ensure policies such as 'at least 2 sign-off reviews needed before the CI server is supposed to deploy it to production'. Does something like that exist?
- jacobr1 4y ago
  maybe this? https://www.gerritcodereview.com/ https://www.gerritcodereview.com/
- WorldMaker 4y ago
sneak 4y ago
This isn't a git-specific issue. People generally conflate local software and network services that are similarly named. A good example is the f/oss community confusing the terms for the Signal.org API and the GPL-published Signal client software.
gonzo41 4y ago
So the only downside to local repo's is that a central site acts as a point of redundancy. Other than that I totally agree.
ryanmcbride 4y ago
The finer parts of git and other day-to-day tools seem to almost always be picked up on the job. I've seen this confusion of git/github before, but the one I always notice is when I'm interviewing someone and they say they have node on their resume but don't know that node isn't just a webserver, they really only used it as an express server and many didn't even know that it could touch the filesystem. It's usually not a problem since they tend to already know javascript and can get things working by referencing the node api docs, but it's still really funny to me every time it happens. There's lots of stuff people don't know until they know.
mhh__ 4y ago
It can be disheartening to see but personally as a young developer it also provides proof I have skills beyond them.
shreyshnaccount 4y ago
well, they were novices, they gotta learn somewhere right? while I admit git being different from Github is pretty basic knowledge and it might be expected that they know that, but this seems rather harsh considering that using git isn't a skill cs degrees cover.
deleted 4y ago
[deleted]

pabs3 4y ago

Are you saying they use GitHub (via the web editor?) but have never heard of Git? or don't know how Git works? or just don't know the Git CLI? or something else?

lvncelot 4y ago
I think many a junior just never initialized a repository, and 'git clone' is what they've used to "get a repository". So I would forgive them for thinking that a remote is needed for having a repository on their drive.
- kertoip_1 4y ago
  IMO the issue here is just that people think of git as it was something like SVN where you need to have some kind of external server to host project. Which isn't surprising as most of the time (when you cooperate with others) you do exactly that: push changes to one server. Idea of decentralization and independent copies of repositories may not be easy to grasp for newbe, because it's really technical concept.
  - bmacho 4y ago
    IMO the "issue" that the concept of a free remote storage/backup makes sense, while doing random things on your own computer doesn't have much value for a lot of people. ".. you don't have to keep the previous versions, so it saves space? OK... No, I was talking about the real git."
  - cratermoon 4y ago
    How many people know that you can just run `git daemon`[1] to share your local repo (very insecurely, mind you) to anyone that can reach your machine? No central server needed. https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
Kon-Peki 4y ago
I have seen the same phenomenon where I work. However, I disagree with the implication that this is limited to young people. I know of a few people that are 50 and 60 years old, that have been using source control for 30+ years, that didn't have any idea that git and GitHub were different things. Now, they were easy to set right; the concepts are all familiar to them. My experience with younger folks that have never been outside the Windows world has been that it was a lot harder to make them understand. Young folks with a unix-y background were much easier.

apocalyptic0n3 4y ago

That scenario plays itself out time and time again. 1. Base technology arrives and is adopted en masse 2. Some entity wraps it in an easier-to-use interface 3. After some time, that interface becomes the de facto standard 4. Developers who started developing after #2 and especially #3 don't understand how the underlying technology works or even that the wrapper is just a wrapper I'm reminded of how many Juniors I trained that didn't know jQuery was itself just a Javascript library and not a language in and of itself. None of them knew much of any of the underlying Javascript it was wrapping. I'm seeing the same scenario play out with React and Vue right now as well.

doliveira 4y ago
I find this so weird, I always feel like I have to at least a bird's eye view of how bits and bytes are flowing through the system. Not that a lot of boxes I don't just label as "magic", but at least I need to know the box exists
- colonelpopcorn 4y ago
  I'm having a difficult time picturing how these hypothetical juniors will fare without that underlying curiosity driving them forward. Likely they'll wash out of the industry or see enough success to be promoted to a management position.
kitsunesoba 4y ago
Is the takeaway here, then, to beat third parties to the punch when creating a new technology and include a first-party easy-to-use interface right out of the gate?
- CRConrad 4y ago
  Yes and no, IMO. Yes, sure, that could be one useful strategy. But no, you can't demand it as some kind of mandatory component for a project to "count as a real FOSS project". And for git, especially... It's not as if an easy-to-use interface had ever been a priority there. ;-) What one could ask for from them, though, IMO, would be a website of their own where they at least explain what it is. Because if such a thing exists, I must have missed it. I mean, git-scm.whatever isn't that, is it? That feels more like... Idunno, it's actually Atlassian in a thin disguise, isn't it?

chrisan 4y ago

What is so baffling about explaining git to a novice? I'm more baffled that you are baffled about this. Git wasn't even invented yet when I was in school and I did not learn about SVN until my first programming job in 2001 where a senior explained it to me.

dreamcompiler 4y ago
I think the parent's point was that the intern knew about github and assumed git was github.
- shrimp_emoji 4y ago
  I used to be confused by this. It's because "git" is in the name and GitHub is the first thing you encounter, so I was like, "oh, is git some command line extension of GitHub?" rather than the reverse. :D
  - cybrox 4y ago
    Well GitHub is just a hub for git projects, a git hub. Most people will get that.
  - leethargo 4y ago
    Similarly, as a youngling, I often confused GNU and Gnome, in particular because several popular (often GTK-based) applications from either started with `g`, eg GIMP, gedit, gparted.

joeyh 4y ago

Github has carefully nurtured this culture of centralization. It's a marvel of our times.

digitallyfree 4y ago

I actually (almost) got in trouble once for this because people thought I was posting code publicly on Github when I was merely creating a local repository in my home directory. I had to explain what Git was and how it was not Github.

skeeter2020 4y ago
The same thing happens with people who should know better that google or even the www is not "the internet"
- CRConrad 4y ago
  How many of us have parents (or, OK, for all you youngsters: grandparents) that assume not only that the Web is the Internet, but that Facebook is the Web?
jvanderbot 4y ago
We had an intern push code that shall never be released publicly to a public repository after we asked him to "push it to our gitlab server". He just assumed there was only one gitlab server and it was the public one, I guess. That was a bit shocking to me. I started with local VCS only all the way up through school and work.
- sreevisakh 4y ago
  You should assume that developers, especially interns know nothing about any technology until they had a thorough introduction. And you should anticipate any confusion they may have in the process. Once, I had to introduce most of the employees of a company to git and git hosting. They were trained from scratch to use git reasonably on the first day. Use of code hosts were taught only on the second day. They were taught hands-on on our internal host and on public server. None of them had any confusion over differences among git and different git hosts. While they did make some mistakes afterwards, none of those were based on total misconceptions.
  - 4y ago

throwk8s 4y ago

Why is it baffling? GitHub and GitLab have embraced and extended git so much that it is no longer independently visible to most users. If you didn't already know git was independent of the SaaS products, you'd have no reason to suspect it was independent.

GTP 4y ago
IMO the reason to suspect that git is independent from the SaaS products, is that you can create and commit (and merge and most other things) to a local repo without ever pushing it to GitHub or any other site.
sreevisakh 4y ago
It's baffling because practically all learning resources on git emphasize its decentralized nature. Even the online free book explains that several times. They never left me with any confusion regarding the difference between git and github, even though my first version control was the centralized subversion. I don't understand how any developer can learn git without this idea being drilled in constantly.

BeetleB 4y ago

2 years ago, while interviewing internally, I asked the team what VC they use. It was Team Foundation's proprietary VC (and not a DVCS). I mentioned to them that even MS recommends Git for Team Foundation's usage. "Well of course, MS invented Git!" Wrong on so many levels: 1. Conflating Github with Git. 2. They bought it, not invented/founded it. 3. Most importantly, MS's recommendation to use Git for TF existed long before they bought Github. Needless to say, I didn't join that team. Unfortunately, misconceptions like these, and a refusal to use Git[1] due to its complexity are quite common at the company - and it is one of the larger SW companies[2] in the country. [1] I'm OK with any DVCS. Even I prefer Mercurial to Git. But most of the company prefers SVN or TF's version control. In 2015, many teams had to be dragged kicking and screaming by IT from CVS to SVN. In 2015, when Git already dominated the world. [2] By number of employees with "SW <something>" in their title. Not by revenue, etc.

prepend 4y ago
> refusal to use Git[1] due to its complexity I kind of like this friction. If a software developer finds git too complex, that’s an important signal that I should minimize my exposure to them. I’d never work in a team that dumb, and I wouldn’t want any dependencies on their code. Of course there are other reasons not to use git, but complexity is not one.
- cybrox 4y ago
  Working with git can become extremely complex if your workflow is bad. Not git's fault, though.
  - remram 4y ago
    Git is a very malleable tool, you can use branches for many purposes, do all kinds of complex merges (e.g. subtree, etc). I think it can be made to fit most workflows. The main issue is repository size, which is hard to get from bad workflows alone, with the exception of insistence on tracking large binary files in Git (rather than LFS, DVC, etc).
- 4y ago

briffle 4y ago

I have had to have the same conversation with co-workers who have been developing for many years, but using tools like SVN, or similar Microsoft code repos that require a centralized repo.

itslennysfault 4y ago

I used to teach a coding bootcamp. I had over 100 students over about 2 years, and ran into this constantly despite my best effort to explain that git != github from day one. We even did an exercise where we just used git locally first and then later (on a different day) showed how you can push to github. It didn't seem to matter. People just decided that git = github and couldn't let go of that.

spencerchubb 4y ago
git --> github porn --> pornhub best explanation of github for noobs
- GTP 4y ago
  Lol
- sigg3 4y ago
  bat --> bathub
  - tcmart14 4y ago
    Wow, I didn't know that, that thing is supposed to be a hub for bats.... Learn something new every day!
- dijit 4y ago
  That's actually an excellent way of explaining it. Though it's frustrating that it's pornhub specifically, because referencing pornography can be awkward or impractical in workplace contexts.
  - beardedetim 4y ago
    GrubHub?
    - mgkimsal 4y ago

brundolf 4y ago

I don't think it's fair to frame this as specific to GitHub, or even as a thing to wring hands over. New devs - especially those coming from bootcamps (I say this without judgement) - mostly start with practical skills. Industry-standard ways to just get things done. That's how you get a job, that's how you get off the ground. This goes beyond source-control; languages/frameworks, tooling, etc. You enter the territory - with your finite bandwidth for learning - where it's most immediately useful. And then over the years you move out from there, incorporating more and more nuance and detail and auxiliary knowledge. There's no need for moral panic. "Where it's most useful to start" has shifted, sure. But that's natural; I don't think it's a new phenomenon or in a fundamentally worse place than before. GitHub is a higher-level tool that makes you dramatically more productive than raw git on its own. The details will be filled in as they work their first job.

masklinn 4y ago
> New devs - especially those coming from bootcamps (I say this without judgement) - mostly start with practical skills. I wouldn't say that it's "especially those coming from bootcamps". Those coming from uni are no better IME.
- brundolf 4y ago
  Depends on the uni. Mine focused on fundamentals, almost to a fault; we learned algorithmic complexity and relational normal-forms but never touched eg. JavaScript, Python, or - ironically - git. Practical skills were very much not the entrypoint; I had to learn most of that myself.
  - ryanmcbride 4y ago
    Yeah I had to learn Assembly in college. We also had to physically print out our C++ code and turn it in to the professor. Did it make me a better programmer? Maybe but to this day I still haven't had to use it. Most of my practical skills I picked up on the job. P.S. I've seen the professor grading the printed out programs and he'd do it by flipping to the last page which was supposed to have the result output, and then fold the corner of the papers so it looked like he read the whole thing and then put a grade on the top. It was pretty funny.

mrits 4y ago

git isn't easy to understand. I think the real irony is I spent the first decade of my career teaching senior engineers how to use distributive version control. So many older guys decided to just use the SVN shim instead of learn something new and useful.

rzwitserloot 4y ago

Going through security certification procedure, I was asked to list all the third party SAAS things we use. I didn't include github, gitlab, or anything else, because we don't use it. The auditor was going off on a tirade about how lack of version control is not okay at all, so convinced they were that 'no github or gitlab' must therefore mean 'no version control'. The mind boggles. He barely believed me when I showed how git just syncs with other git repos and that's really the start and end of it. This has actually gotten me into thinking about a few things. What a web site 'backed' by your git repo seems to get you is: * Some insights to those who don't have a full git dump. Mostly irrelevant. * CI stuff and hook processing, but this does not need to be done by the system that hosts git, or even a dedicated system in the first place. * An issue tracker that nicely links together and that auto-updates when you commit with messages like 'fixes #1234'. * Code signoff/review coordination. And all of that should be possible __with git__, no? If you have a policy that all code must be signed off otherwise it isn't allowed to be in the commit tree of your `main`, `deploy` or whatever you prefer to call it branch, then why not just say that a reviewer makes a commit that has no changes (git allows this with the right switches), _JUST_ a commit message that includes 'I vouch for this', signed by the reviewer? And that _IS_ the review? What if issue tickets are text files that show up in git, to close a ticket you make a commit that deletes it. Or even: Not text files at all, but branches where the commit messages forms the conversation about the issue, and the changes in the commits are what you're doing to address it (write a test case that reproduces the issue, then fix it, for example), and you close a ticket by removing the branch from that git repo that everybody uses as origin? Then all you really need is some lightweight read only web frontend so that the non-technically-savvy folks can observe progress on tickets in a nice web thingie perhaps, if that. But it's just a stateless web frontend that reads git commit trees and turns them into pretty HTML, really. Commit hooks to ensure policies such as 'at least 2 sign-off reviews needed before the CI server is supposed to deploy it to production'. Does something like that exist?

jacobr1 4y ago
maybe this? https://www.gerritcodereview.com/ https://www.gerritcodereview.com/
WorldMaker 4y ago

sneak 4y ago

This isn't a git-specific issue. People generally conflate local software and network services that are similarly named. A good example is the f/oss community confusing the terms for the Signal.org API and the GPL-published Signal client software.

gonzo41 4y ago

So the only downside to local repo's is that a central site acts as a point of redundancy. Other than that I totally agree.

ryanmcbride 4y ago

The finer parts of git and other day-to-day tools seem to almost always be picked up on the job. I've seen this confusion of git/github before, but the one I always notice is when I'm interviewing someone and they say they have node on their resume but don't know that node isn't just a webserver, they really only used it as an express server and many didn't even know that it could touch the filesystem. It's usually not a problem since they tend to already know javascript and can get things working by referencing the node api docs, but it's still really funny to me every time it happens. There's lots of stuff people don't know until they know.

mhh__ 4y ago

It can be disheartening to see but personally as a young developer it also provides proof I have skills beyond them.

shreyshnaccount 4y ago

well, they were novices, they gotta learn somewhere right? while I admit git being different from Github is pretty basic knowledge and it might be expected that they know that, but this seems rather harsh considering that using git isn't a skill cs degrees cover.

deleted 4y ago

[deleted]