Hacker News Reader

Comment by travisgriggs | Hacker News Reader

> 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.

View on HN

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.

There is absolutely a need for moral panic if, like me, you believe that code and industry quality of product is more important than onboarding more people into the profession.

I can't think of a worse idea than subconsciously letting the idea "By default, the way we are supposed store and write code is by putting it in the hands of a deeply centralized third party that will exploit you and owes you nothing" just sort of be the default deal.

> you believe that code and industry quality of product is more important than onboarding more people into the profession

Perhaps a bit of a stretch?

Does the fact that new devs don't know Git fully necessarily mean the quality of code will decrease? I mean, compared with the new devs knowing Git fully...

I mean something broader than that here; I mean to say that "a generation of new devs who grow up in a world that sees git and Github as equivalent is perhaps likely to be something like a not-useful generation of mindless code drones doing little more than working for the proverbial 'man'" -- which, especially for CODING (in which hours doesn't mean accomplishment, unlike, say dentistry) simply isn't good for the world.

There's some conflating of correlation and causation here, of course.

> Does the fact that new devs don't know Git fully...

That's not the problem. The problem is that they don't know what git IS; they think that GitHub is git.

> I can't think of a worse idea

There are lots of worse ideas. Things get abstracted from us over time. 99% of the code in active development today probably lives in a source control repo that's in the cloud.

At one point, decades ago, I looked with amusement on devs that couldn't do C/C++. But the reality was that it wasn't really needed anymore for most tasks.

This is different from what you're saying though. This isn't about "what basic knowledge is needed generally." This is about us frog-boiling ourselves into a world where we end up accepting the mentality that code is owned and controlled by the big company/entity in the center. For now it's "convenience," but if it continues it absolutely will turn into a center of power to be policed. "Dangerous code" will be censored, etc.

In other words, yes, Stallman was right.

like we (atleast people my age) by default are expected to have Instagram Snapchat WhatsApp YouTube Discord Reddit Spotify Twitter accounts and when I left some of these sources my friends actually questioned me about why I'd do that and some people even told me it was weird and I'll end up giving up material possessions and becoming a "sanyasi". fascinating that becoming a sanyasi is considered bad it actually sounds rather nice to me

The ins and outs of version control solves a problem that has not yet existed for an intern. It’s not that big a deal to train them on the job, industry practices probably don’t map well to academic settings anyhow.

Not to mention that git is plagued with, as a general rule, utterly confusing defaults for a newbie (and for me, when setting up a machine without my config files!)

> 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.

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.

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.

My C class had weekly written programming tests.

Not multiple choice tests. We had to write a program by hand and hope to god it would compile without any errors.

Horrible way to teach C imho.

If they also made you do all the calculations the program would, by hand, and record the output, then penalized you if you made any errors on that... it'd be math class.

When I had it it was primarily for logical problems. So it was more boolean logic than true math

this was my high school curriculum. did python without classes, matplotlib without numpy and django without understanding mvc. Just memorise it xD

thats how they teach programming in a lot of places where I am

Same here, only if you wrote in pencil, you were not allowed to appeal grading. So you had to write C from memory _in pen only_ while learning the language. There were students who pointed out the grading was wrong on their code, the TA and professor agreed, and the mark was not changed. Had to take it to the dean, don't think I learned if it was ever fixed. It wasn't even a CS degree...

Hey we had that too! Good ol pen and paper. It was thankfully generally for simple algorithms

Did we go to the same school? Halfway through the semester he gave up on even that pretense and started throwing them out in front of us and giving everyone a C-

Never saw him do that but given his personality I wouldn't put it past him lol. He also cemented in me that there would be virtually no collaboration at a company and that we'd be given problems to solve/features to build and if we had trouble we'd get the can. I think most of his work experience might have been in a pretty hostile work environment. Or at least a good while before pair programming became the hot ticket item.

Not sure I'd agree, every CS student at my school had to take a class where one of the projects was implementing a mini version of git from scratch. And even before that class there was at least one lecture dedicated to git in the intro class.

In my experience, bootcamps and uni produce polar opposites. You either end up with devs who can do several practical things, but have no clue about fundamentals, or devs who know all the academic terms but have no idea how to apply them practically.

the only significant difference I've seen in brand-new devs from bootcamps vs CS programs is the devs from bootcamps are somewhat aware that they have a lot of learning to do

Not my experience. I found a lot of hubris in the few last batches of bootcamp devs I interviewed or worked with.

I suppose it depends on what one considers practical.

How difficult is it to teach “Git runs on everyone’s own machine. GitHub and GitLab run their own Git for their users to connect to and push code.”

Apparently overwhelmingly.

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.

> 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.

My take is completely opposite from yours. I think it's great when someone "gets" that git is an extremely powerful and capable tool with a horribly unintuitive user interface. Whether you call that "complexity" or just "terrible UX", to me that's a sign that someone has good instincts regarding the risks associated with this kind of "complexity". Whether I agree that a decision to shun git for that reason is justified depends on the specific situation.

> ... that I should minimize my exposure to them. I’d never work in a team that dumb ...

That sort of arrogance is an important signal to me that I should limit my exposure to the people displaying it. I personally see this sort of attitude as a sign that there may be a dangerous lack of empathy on their side, and I've seen that go south too often.

^ this. The comment's arrogance and narrow-mindedness is preposterous, and would be a strong signal to me to stay away.

I find Git's CLI and workflow model complex because I had the "misfortune" of using other DVCS products (Mercurial, Bitkeeper, Bazaar NG, Darcs, etc) before it. All did a far superior job of presenting roughly the same conceptual model in their command-line tools. Git's is a step backwards.

Git didn't invent distributed version control, it didn't perfect it, it wasn't particularly superior to the others [it does have some benefits in terms of performance tho, yes], it was merely at the right place (the Linux kernel when Linus got sick of Bitkeeper's business model) at the right time (when people finally got sick of CVS and SVN garbage.)

And the rise of GitHub was certainly part of the rise of Git's prominence.

Slightly different circumstances and it could have been any of the other open source distributed revision control systems instead.

> That sort of arrogance is an important signal to me that I should limit my exposure to the people displaying it.

Different strokes for different folks and not everyone is capable of working together. Comically, people like you would find your comment also arrogant and stay away from both of us.

For what it’s worth, I work on empathy quite a bit and my filter is based on the idea that it saves both me and the other party pain. I don’t want to work in a team where developers are tolerated giving up on super basic technologies like git (what else isn’t tolerated “oh, tcp/ip is just too complex for developers, I give up”) and they probably don’t want me to work with them.

I think one of the best things about technology is that people have great capability to solve problems. Giving up is a bad characteristic. Asking for help is important. Having teams of various skill sets is important. But giving up on basic things instead of getting help and figuring it out is bad as a permanent state for a team.

I say this as a senior dev with 8+ years of experience working with git: git is nightmarishly complex. Highly stateful, insanely large CLI surface, huge amounts of terminology/concepts relative to the complexity of what you're actually trying to do with it. I've learned to navigate its waters over the years, fully appreciate the difference between git and GitHub, etc etc, and I don't blame anybody for being scared away by its complexity.

Git is super complex, yet it can be used successfully with just a few commands.

I blame developers and even most users for being too scared to use it. I think it’s perfectly normal to be scared of it while using it.

I think all users of technology should have some basic competence. Like every human should be able to be a basic Unix user, every human is capable of using git. And every developer should be capable.

Original commenter here.

Every one should be able to use Git. However, Git really isn't the best tool for everyone - or even most developers.

As a whole, you are absolutely correct. But 99% of your daily interactions with Git come down to a handful of commands. Hell, print out a cheat sheet and tape it to your desk for the first few months of using it and you will be more than fine.

Until you make the slightest mistake and your work area gets into a state not covered by the cheat sheet. But of course, the standard recommendation seems to be just to remove the work area and check it out again :p

I’ve used git for 15 years or so. I use the same 5 commands. I haven’t run into a situation like you describe where I lose everything.

Worst case scenario is that I lose a check in, but even that is rare as I can just copy over, start with a fresh clone, and reapply. I don’t think there’s a significant danger of messing up a project. And again, this is just basic developer capabilities and developers should be familiar with a vcs enough.

Well you can always for help from a co-worker more experienced with Git, or just search the internet for help. That could be a teaching moment.

Well, that proves the point that just having a cheat sheet isn't a complete solution. And unfortunately, I am the co-worker more experienced with Git :p. Well not quite, I have a co-worker who is roughly on my level and we keep helping each other and of course trying to google ourselves out of every corner we got us into.

The practical approach was to write a simple GUI which supports the operations "Pull" "Stage" "Commit" "Push", which makes live quite easy. And otherwise, try to keep out of anything more complex, until really neede. Works quite well, but I cannot say I am entirely happy. There are some benefits though, due to our company using a GitHub Enterprise installation for all version control. Ironically, our group recommended that some years ago, but because GitHub comes with a lot of neat features, less so because our love of git :)

And yes, over time, I am picking up more of it, but I try to do that on a slow pace, because I consider VC a tool which is important for work, but which shouldn't take time away from work. And Git definitely takes a lot of time to learn, there are far too many mechanics exposed to the end user.

Well, be fair, grandparent argued that a cheat sheet would help "for the first few months", not that it is a "complete solution", so I don't see how my suggestion "proves" anything.

Also, without knowing which issues you're having with git it's impossible to know if it's lack of baseline knowledge or if you're running into real complicated problems.

If you have a GUI with "Pull" "Stage" "Commit" "Push" buttons, I strongly suspect you're not in the complicated end.

> That could be a teaching moment.

Given the context of this thread, comments like these are part of the reasons teams don't use Git.

One probably needs 10x such teaching moments with Git compared to other VCs - including good DVCS.

Considering the popularity of git itself and the fact it is successfully taught at bootcamps and university at a satisfactory level, I would disagree that being a “deep tool” is part of the reason it’s not 100% ubiquitous. The easy parts are still very accessible to newcomers and the existence of deep part doesn’t negate that.

And I also take issue with calling its “non-100% ubiquity” a problem. There is plenty of space for other tools. If anything, there’s almost a “git monopoly”.

Sure it could improve in parts, but the general discussion here doesn’t seem to be focused on improvements at all…

The more relevant point is: do you refuse to work on some code or use a VCS on your code because of this complexity?

That was the GP's point. He acknowledged it's complex. But it's a very clear and very large amount of value left on the table, so people that gets scared away by it will probably practice other kinds of harmful behavior.

(Of course, the option of just using a simpler VCS doesn't tell anything bad about people. Why did we standardize on git again?)

> Of course, the option of just using a simpler VCS doesn't tell anything bad about people. Why did we standardize on git again?

My issue wasn't with their refusal to use Git per se. It was their refusal to find something better than SVN.

Given the choice, I too would pick something other than Git. But still better than SVN.

It might be hugely complex, but at the same time, I'd posit that 90 percent of devs use only 1 percent of its functionality, 95 percent of the time they use it, and get work done.

To be fair, most people who find it complex do so because Git has a very crappy UI. You don't need to understand the internals to use Mercurial, and I would imagine that's true for most other DVCS's. In that sense, I sympathize with them.

I'm pretty sure half of the teams that find Git too complex wouldn't find Mercurial to be complex. But they haven't heard of Mercurial.

I'm the guy people at $work call to do git submodule reorganization, troubleshoot lfs or recover disasters. I'm certainly comfortable with git. It gets the job done. The same can be said of svn.

However my own projects always start with hg init. In addition to the UI being less insane it also feels consistent and nice to use.

At one point I was on a team using Darcs, which was another level of beautiful but clunky in many ways. It is why I'm rooting for the Pijul team. [1]

1: https://pijul.org/

Same here. I use Git at work, but anything I control I use hg. The only factor making me more likely to use Git is Magit, and no good equivalent for hg in Emacs.

You could miss out on some good junior developers if you pick one thing they are ignorant about and reject them because of it. There are plenty of bright junior developers who don't know everything, have opinions on things that they think they know, but will work hard and pick things up once they get some time at it. Of course, if they outright refuse to use something then that's another story.

Not knowing git doesn’t have to be a permanent state. I am grateful for being taught git and tons of other stuff. I’ve thought many people many things and still have a lot of debt.

To clarify, I’m not criticizing not knowing git. Lots of people don’t know git. I’m criticizing the decision not to learn git and being unwilling to learn it due to its “complexity.”

I would say "friction" is the right word and "dumb" is not the right word here. Centuries ago (in Internet time) there was a culture among server devs that anyone who could not or would not, learn and correctly execute 100 things in the shell that today are obscure and obsolete, was "too dumb" and "not professional" . Evolution and intelligence have moved along since then, and others crusted over and embedded the minimal practices needed.

Does a typical enterprise need a distributed source control system? It makes a lot of sense for open source.

Doesn't the uptake in Github which centralizes this distributed system kind of invalidate its main tenant?

I haven't been a hundred percent sure the overhead was ever worth it at most other types of paid gigs over the years. Adding complexity without value is a mistake imo. Maybe it's my own fault I haven't seen the value...

The (side?) benefit of a DVCS is that you commit locally. So I can do all my fun experiments on my team's codebase on my laptop - it doesn't pollute the number of branches on the server, etc.

Indeed, even when forced to use SVN, I would simply check out the SVN trunk, create a Mercurial repository in that "working" directory, and then clone from their whenever I did any development (one clone per feature). I would then push back to the main Mercurial repository, and push that to the SVN server.

Other than that - true. No real DVCS benefit compared to SVN. I would imagine most of the nicer Git features that people use have, or could have, analogs in SVN.

> Indeed, even when forced to use SVN, I would simply check out the SVN trunk, create a Mercurial repository in that "working" directory, and then clone from their whenever I did any development (one clone per feature). I would then push back to the main Mercurial repository, and push that to the SVN server.

Once did something similar with Git, the one time I was at a place that used SVN. I didn't trust any of the git-to-SVN tools so I just did all my work in a local git repo, then copied my working directory to an SVN-controlled directory and committed maybe once or twice a day, when I had something worth preserving.

The ~week before I switched to this workflow was nerve-wracking. Not being able to make all the branches I want for any purpose at all without it showing up for anyone else, or to make shitty commit messages for my own local junk-commits before it was ready for consumption by anyone else, was awful. Having to worry that every little vcs operation might mess up someone else's stuff was the worst.

Luckily I was working on an isolated part of a larger system on my own, so this worked OK. No incoming code to worry about, so SVN was write-only from my perspective.

> Does a typical enterprise need a distributed source control system?

Yes, unless you are working on a tiny number of source files. The value is that you can work on entire copies of a code base at a time instead of single files. Git does a much better job than making lots of local copies of source code, passing around big diff files and is a lot less hassle than older centralized source control systems.

> Doesn't the uptake in Github which centralizes this distributed system kind of invalidate its main tenant?

No. Not at all. Github is actually a peer with an a few integrated extras for managing tickets and requesting your code be merged into github's repo branches. Most of the centralization is around access control and automation (i.e. continuous delivery, unit tests, etc...).

> Adding complexity without value is a mistake imo.

The main value of GitHub is reducing some operational complexity. For a small 1-4 person team, it may be of little value, but for larger teams, access control, issues, and automation can have a lot of value. For really small teams, fossil is actually quite nice. That said, there are a lot of great alternatives to GitHub that give you similar features.

> Maybe it's my own fault I haven't seen the value...

Probably not. I did the first 20 years of my career without source control and was able to build some pretty big applications. I do think dvcs was a big improvement, and I'm glad it exists now.

I think I've only worked on projects a couple of times in twenty years larger than a handful of devs so your comment really makes sense.

Do I need to run `log` without hitting the server? Yes. :(

https://news.ycombinator.com/item?id=31794779

I find distributed version control super useful for the enterprise. I have way more private repos than public.

It’s useful because it makes it easy to have multiple copies of a repo and merges and branches are trivial. Just for my own project I might have clones on multiple machines. When I mess up and make a change, it’s not a big problem and merging is easy.

For team collaboration, I find it better than centralized because it makes it easier to work on multiple branches. It also encourages merge requests from people outside the team.

Working with git can become extremely complex if your workflow is bad.

Not git's fault, though.

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).

If this attitude is common, maybe it's why our tools are so consistently half-broken garbage.

You'd think developers could at least make the stuff they have to use decent. But no.

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.

git --> github

porn --> pornhub

best explanation of github for noobs

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.

GrubHub?

StubHub?

A safer-for-work version might use:

fried chicken --> KFC

bat --> bathub

Wow, I didn't know that, that thing is supposed to be a hub for bats.... Learn something new every day!

I use video --> youtube

"Porn" is a genre of video and YouTube is better known than pornhub.

But the whole point of the "porn --> Pornhub" half-joke analogy is that it shares the word "hub" with Github!

Lol

Should explain with another git hoster than github first, let them get used to something else. Then, when they meet github, they will know, that they used something different before (hopefully, otherwise they are hopeless cases).

With students you ran into this?

I'm surprised that at a coding bootcamp students would already have some idea of git ... at all.

Most didn't. That's my point exactly. Even though I introduced them to git, and then later github, AND I was aware of the problem and tried to ensure they wouldn't conflate the two. It still happened.

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.

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

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.

That entity is usually Microsoft. I've met web developers who relied on Microsoft drag-and-drop tools to build websites, they were unable to tell me what a cookie or HTTP request was. Microsoft could be injecting telemetry into their websites and they wouldn't know.

Since then I've been obsessed with knowing how things work under the hood and doing as much as possible by myself until I understand what's being abstracted away from me.

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?

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?

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.

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.

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.

Yes, it was a learning experience.

The same thing happens with people who should know better that google or even the www is not "the internet"

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?

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

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?

> 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?

Git has two levels of built-in/native commit signing support. There's "Signed-Off-By" which adds a note to the bottom of a commit. Some projects use that for CLA verification. There's also GPG signing which signs a commit hash.

If you want to use that as a level of "merge request"/"pull request" reviews there's a natural commit to sign that says you reviewed an entire branch: the merge commit itself. You can make a policy of --no-ff merges in your main and important branches. You can make a policy that they are signed (using one or both of the sign off types). You can make a policy that they are signed by someone who wasn't the author of most of the branch's commits.

> 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?

There's multiple cool approaches to this that people have tried. Search for "git distributed issue tracker" and you should find some of them. Some have okay web views. There's multiple options for storing the issues. Some use YAML files inside of the branch. The neat thing about files in the branch is that you can find things about where fixes happened using basic branch diffs. Some use git "Notes" which are indeed like git commits as a first class top-level object in git's object tree. Those do have the benefit that they form their own branches outside of your code branches.

It's neat to explore what people have already tried in that area.

maybe this? https://www.gerritcodereview.com/

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.

I think the parent's point was that the intern knew about github and assumed git was github.

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

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.

Well GitHub is just a hub for git projects, a git hub.

Most people will get that.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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-Protoco...

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."

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.

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

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.

Reply on news.ycombinator.com