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