Just putting it out there: if anyone ever wants help - debugging, problem-solving, tutoring, whatever - with the Linux CLI (bash/ksh93, GNU coreutils..., vi, emacs, sed, awk) and/or git, I'll help.
I won't make you feel bad for anything you don't already know. I promise. (Nobody ever should.)
I'll reiterate every once in a while. Boosts appreciated!
Recurring offer reminder: I'll help / mentor / teach / tutor / troubleshoot with anyone who wants to learn git for basic version control, collaboration, managing personal projects, or for a day job. I'll work to connect people with mentors other than me if they prefer - no need to explain why.
Same for bash, command line tools, and so on.
I want using & contributing to FS/OSS to be easier for way more people.
@gnomon I'm a fledging too in contributing as well. I feel there's some level of toxicity in OSS communities which kinda keeps me away.
@varkychen I know what you mean. It made me nervous when I first started getting involved many years ago.
I still see it but now instead of nervous it makes me frustrated and impatient: there is so much work to do in these projects, and so much complexity to deal with, how is it fair for newcomers to have to figure out how to navigate that toxicity too?
Then I ran out of patience with myself for just being bothered by it, so now I'm working on fixing it.
I hope it helps you.
@gnomon I'll sheepishly admit that it's a cocktail of that, laziness, inertia and social media that keeps me away
@dpreacher that's a really excellent question.
I don't think there's any single best way to learn it, not in general. It'll always depend on the best way your own mind moves things from short term into long term memory, what metaphors you already know that you can use to attach new contexts to, how task-oriented vs how knowledge-oriented you tend to be.
I've observed that learning the terminology first can help make all the rest of the documentation easier to absorb and retain.
@dpreacher that is, if you can take a couple of hours to dig deep into exactly what a commit is, what a tree is, what a blob is; what refs, branches, and tags (lightweight and annotated) are and how they work; what remotes are and that to do with them; what the work tree, index, and data store are; then all the actions you can perform that operate on those things make a bunch more sense. Really helps everything else you pick up kind of hang together in a way that makes sense.
@dpreacher does that help at all? I can get more specific and offer more specific, concrete direction if you like.
@dpreacher oh! I forgot to mention the single best way to cheat at learning git quickly!
At some point you'll run into a situation where your repo is doing something you don't quite understand, you'll look up a fix, it'll screw things up badly, and you'll feel a bit panicked & maybe start trying random actions.
1. Don't feel bad, literally every single git learner does this.
2. Stop, stand up, take a short 5 minute walk. (Actually do this.)
3. Run "git reflog --help". You're safe!!
@gnomon I'll need some time to get back to this. some points:
1. your long toot about all the various concepts and terms summed up my fear of how to know all that. also it is ironic that you need to learn terms in the docs, before reading the docs.. Like you need a doc for the doc.
2. I've got to use git in a company where I worked only for a month.
3. In last company git was used with some Atlassian component. I wondered, do I need all that if I just want to code myself on my own laptop?
@dpreacher I'll respond in inverse order, if that's OK!
3. By Atlassian component I'm guessing you mean either Bitbucket (probably Server, the on-prem version?) or SourceTree? Bitbucket is fine; but although I try not to speak poorly of specific tools, avoid SourceTree if you can. Not necessary, not good.
2. Only a month? That's super challenging!! Even in very mature shops with strong dev practices that can be barely long enough to learn their conventions, let alone a tool like git!
1. You're absolutely right, it's complicated and it can be challenging to learn. If you start by learning actions before learning terms, you can usually get started faster, but then every small issue turns into a long research process and it's *always* when you need to get other work done. If you start with the terminology instead then there's always the question "OK, that's what $THING is - but why does it matter, what do I *do* with that?"
There's no easiest way. ):
@gnomon what a fantastic offer. Good for you! I hope a lot of people take you up on it... But not TOO many. :)
@enthdegr33 thank you! It's not too many so far; and several other folks have already kindly offered to accept referrals if the load ever gets to high. I'd be happy to have to work on solving that problem!
@gnomon I'm glad to hear it's going well! Most of the topics you listed are things I'm in the process of learning. I actually thought to reach out if I find myself hung up on something that I can't find an answer for!
@4believeme ahoy!! Sorry for taking so long to get back to you.
So, a good place to start would be with three questions:
1. Where are you on your journey at the moment? In which knowledge and skills are you already confident, what do you want to build on?
2. In which direction do you want to go? (This can be a challenging question because learning usually involves not knowing a topic already; but even a very general answer helps.)
3. How do you prefer to learn?
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!