I would argue git is not novice friendly. It's original intended audience was not lay people learning how to program. It was seasoned kernel developers working on the Linux source tree. It (made) assumption(s) it's userbase were experts in their domain.
> Naturally, people get confused and reach for the docs, which are filled with even more newbie-hostile terms like 'tree-ish', 'hunks' and 'refspec'.
Yup, these are everyday terms for an expert in computer science and algorithm and software design. If I were a student in medical school I'd expect the books I'm learning from to use the expert terminology of my domain of study when describing the body and functions and not laymans terms such as -- "the hip bone is connected to the Red-Squishy-Thing .... ELI5 me plz" ...
I agree git is complex, and can be scary. But building software is a complicated process rife with engineering pitfalls! If one is unable to properly use the Lego building blocks, then stay away :D
I do believe when used properly, a productive Git workflow using Branches and sane commit messages can help to give Visibility to your project development life-cycle and help to make an issue or task on a project understandable in scope and difficulty by segmenting ones development work into comprehensible mergable pieces (branches) within the project.
Git is not friendly period, it's a huge pile of leaky abstraction and incoherent commands, the "high-level UI" being closer to shortcuts for common sequences of lower-level operations than an actual abstraction. It simply can not be understood "top-down".
> It's original intended audience was not lay people learning how to program. It was seasoned kernel developers working on the Linux source tree. It (made) assumption(s) it's userbase were experts in their domain.
Domain expertise has nothing to do with it, unless the domain is playing with footguns and expertise is having toes left.
> I agree git is complex
Git is not complex, it just has a very, very shitty API.
people with any kind of technical knowledge of a domain tend
to get hopelessly (and unwittingly) stuck in a frame of
reference that relates to their view of the issue, and
their trade's technical parlance, not that of the ordinary
humans with whom they so signally fail to engage.
Could this principle not also apply to any journal/conference paper? For the most part, one has to have a basic understanding of the field, and read through prior research to have a better understanding of the current problem domain.
We don't expect journal papers to be written at an elementary level. But people who make an effort to get themselves up to speed in the area can understand them. The same thing applies to a lot of tools that are used in software development.
> Could this principle not also apply to any journal/conference paper?
Git's man pages are not journal papers.
> For the most part, one has to have a basic understanding of the field
"Basic understanding of the field" does nothing for understanding Git.
> and read through prior research to have a better understanding of the current problem domain.
You should not have to "read through prior research" to be able to use a basic VCS tool, literally no other VCS asks that of you, not even Darcs (especially not Darcs, which actually put real effort into a sensible CLI).
> We don't expect journal papers to be written at an elementary level.
We don't expect tooling documentation to require a phd unless the tool's entire purpose is something only a phd would need.
> The same thing applies to a lot of tools that are used in software development.
No. It applies to very few tools that are used in software development. And git most definitely is not one of them.
> "Basic understanding of the field" does nothing for understanding Git.
Assuming one has at least read up on data structures, then one would have read about graph structures and have heard about what a directed acyclic graph is.
> You should not have to "read through prior research" to be able to use a basic VCS tool
You should have some understanding of what source control is and have read at least some of the documentation of the VCS tool you are using. I've never used hg and wouldn't know where to start without reading some of the documentation first. But having prior knowledge of VCSs and distributed VCSs would allow me to target my search for documentation about how to commit changes, how to publish them to a remote repository, how to make a branch, etc.
> We don't expect tooling documentation to require a phd
Many of these papers can be read and understood by students who are pursuing their undergraduate degree. But they do need to put some effort into it.
> No. It applies to very few tools that are used in software development.
Can I use grep without a basic understanding of how regular expressions work? Could I use a debugger like gdb without understanding concepts like the call stack and variable addressing? You have to be able to read through documentation to effectively use a lot of tools in software development.
> Assuming one has at least read up on data structures, then one would have read about graph structures and have heard about what a directed acyclic graph is.
Knowing what a DAG is doesn't help using git and Git being singularly problematic despite every DVCS being a dag indicates that DAGs have nothing to do with Git's issues.
> You should have some understanding of what source control is and have read at least some of the documentation of the VCS tool you are using.
Basic understanding of source control and the ability to read correctly-written documentation (which Git's is not) is not "read[ing] through prior research".
> Many of these papers can be read and understood by students who are pursuing their undergraduate degree. But they do need to put some effort into it.
Completely missing the point.
> Can I use grep without a basic understanding of how regular expressions work? Could I use a debugger like gdb without understanding concepts like the call stack and variable addressing? You have to be able to read through documentation to effectively use a lot of tools in software development.
Your original assertion was not the ability to read some documentation (under the assumption that the documentation actually makes sense, which isn't the case for git).
If you're not going to make even cursory attempts at basic honesty and coherence, there's no point to a discussion, enjoy playing with yourself.
> correctly-written documentation (which Git's is not)
How does git's documentation fundamentally differ from tools like ffmpeg or grep? That is, what makes it incorrect? I've read through those man pages and have been able to figure out how to use the CLIs for those commands.
>> We don't expect tooling documentation to require a phd
Very few dev tool organizations employ dev-oriented UX designers. It’s mostly the developers and PMs themselves doing UX design, when they have been evaluated and promoted based on other things (coding, project management).
Because it's hard demanding proper UI when you intuitively know you couldn't build one to save your life, not only does it feel like whining, if it spreads you might be out of a job.
> Naturally, people get confused and reach for the docs, which are filled with even more newbie-hostile terms like 'tree-ish', 'hunks' and 'refspec'.
Yup, these are everyday terms for an expert in computer science and algorithm and software design. If I were a student in medical school I'd expect the books I'm learning from to use the expert terminology of my domain of study when describing the body and functions and not laymans terms such as -- "the hip bone is connected to the Red-Squishy-Thing .... ELI5 me plz" ...
I agree git is complex, and can be scary. But building software is a complicated process rife with engineering pitfalls! If one is unable to properly use the Lego building blocks, then stay away :D
I do believe when used properly, a productive Git workflow using Branches and sane commit messages can help to give Visibility to your project development life-cycle and help to make an issue or task on a project understandable in scope and difficulty by segmenting ones development work into comprehensible mergable pieces (branches) within the project.