Mina
I think i'd have an easier time using whatever VCS people already know, than trying to stuff "teaching git" into teaching a work-shop.
like, I already know (have used) cvs, svn (and svk!), mercurial, fossil, darcs, bazaar, and git (and git svn!).
i might have even used RCS at one companyβ¦
and I'd even have an easier time teaching most of those, compared to teaching git, which i have extensive knowledge of.
Stefan Sperling
@meena Yes, words have meaning. cache index staging area
Stefan Sperling
@meena All the systems on your list have a well-designed and consistent user interface, except for one. Which is why that particular one is difficult to teach.
Mina
@stsp right? RIGHT??
Stefan Sperling
@meena Yes but that does not make it hard to teach the concepts of each such domain.
Anyway, I think it is sad that the Git project has this problem. It would have been easy to prevent in the early days if attention to consistency had been paid in advance. Now any attempts to fix the UI makes it worse by adding even more terms and aliases as they are unable to remove old ones for compatibility reasons.
Stefan Sperling
@meena Sure but each such domain would usually settle on one such term and use it consistently. Or are the books about, say, Lisp, which use Map, Table, and Hash interchangeably to refer to one and the same thing?!?
Mina
@stsp no, but it's still really confusing when you jump from one such domain to another
(multiple times on a daily basis, like some people in the DevOps space do ;)
Mina
@stsp but seriously tho: Hash, associative array, map, table, Hash-map, or the all containing PHP array and Lisp list.
which one is it?
what are the performance characteristics?
it cannot be known
not from the name, anywayβ¦
Mina
@stsp having looked at linguistics, and at computer science vs computer programming languages and their libraries, i am not convinced words have any meaning
but why the heck is git one the one everyone standardized on?
(i know why, or rather, i have my theory why:
everyone wanted to be as cool as Linus.
now everyone is as much a butt as Linus. /s)
Chris [list of cold emoji]
The way to teach git is to first teach the underlying model. (Object IDs behave like pointer values; branches are linked lists of change sets; branch names are just a named box holding the object ID of the latest commit.)
After that, the quirks kind of make sense as handy shortcuts.
(You need to know a small amount of computer science to get this, but it *is* a software development tool.)
Stefan Sperling
@suetanvil @meena That is not the hard part to teach. The hard is part how to map a given workflow onto the tooling that is provided. Endless discussions...
Chris [list of cold emoji]
Yeah, but that's like complaining that C lets you use different indentation styles. If it matters, you write out a policy and require people to stick to it.
And in the case of git, it's pretty easy for an individual developer to use it however they wish on their own machine before coalescing their changes into something that conforms to the project's policy.
Stefan Sperling
@suetanvil @meena Yeah, a team with proficient people who are capable and motivated self-learners (like Linux kernel devs) can make very good use of this tool. Not every group is like that, though. I have taught SVN and Git in many places (mostly companies where writing software is _not_ their only order of business) and you don't find many people on such teams who would even want to play around with a custom workflow. They mostly just want to get their job done without making a lot of mistakes, and the tool really doesn't make this easy for them.
Chris [list of cold emoji]
It seems to be that it'd be easy to design a git workflow that mimics the current tools and just teach the git process in terms of how it relates to that, e.g.
svn co -> git clone
svn merge -> git pull
svn commit -> git add + commit + push
etc.
More motivated users can figure out the extra capabilities on their own, but even with the above mappings, you benefit from being able to roll back a botched merge.
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.