Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to teach Git

rachelcarmena.github.io

Post reply on HN
Print view View original

251–260 of 273 posts

Re: How to teach Git

#251

Post by vharuck »

iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

I took it upon myself to introduce Git to my colleagues: statisticians who've never used version control. I tried to preempt hard questions by going into a repo, wrecking it like a mad bull, and trying to undo the damage with Git. Turns out, it was a great way to learn for myself.

Exercises:

- Commit a "secret" and involve it in other branches, commits, merges, etc. Then remove the secret so that nobody can ever learn it from the repo.

- Clone a repo from another local repo and then rewrite history with rebase and revert. Then commit different work in each repo. What's the least painful way to get them "compatible" without losing any work?

Re: How to teach Git

#252

Post by marssaxman »

maceurt wrote: post #241
Derbasti wrote: post #217

I have taught git for university classes for some years. To be honest, git is a mess. It is conceptually not that hard, but the nomenclature is inconsistent and dangerously ambiguous (quick, what is the difference between reset, rebase, revert, and checkout?). The most effective work flow I have found so far, is teaching only status/clone/pull/add/commit/push. Show them explicitly what happens normally, what happens…

I don't know if this is true. For me personally I have had to use git for a lot of different projects, but I still don't understand anything besides commit, push, pull, add, and force-push (lol). In my experience you can get away with just learning those commands, but I still don't feel comfortable with git.

Does anyone really feel comfortable with git? I've been using it for over a decade, in a handful of different organizations, on projects large and small, both at work and for personal projects, and it still feels like a convoluted mess. Its terminology is wildly inconsistent and my mental model of its behavior remains stubbornly full of fog. I have a library of recipes committed to memory, but I still don't really understand it, and sorting out what's gone wrong when things inevitably go wrong remains challenging.

Re: How to teach Git

#253

Post by P_I_Staker »

krupan wrote: post #249
P_I_Staker wrote: post #240

Earlier quoted context omitted.

Honestly, you just need to try some things. Your reflog is your friend. You'll get the hang of reset/rebase/ect with a little experience. I also think it's worth it to learn a bit more about diff and log. I have no idea why anyone would want to go back to SVN. If you don't want to use all the features, I understand; by all means, continue to only ever branch -> commit -> push -> create pull request. There's no need t…

"and even mercurial to some extent, prevent users from tracking their changes" False. Stop spreading misinformation about Mercurial. "Git means never being scared to create a commit." This is indeed one of the biggest benefits of DVCS tools, including git and mercurial.

Thanks for the feedback. Quite frankly, I never found a comparable workflow in Mercurial (but that doesn't mean one doesn't exist). Commits still felt like a permanent thing that made me pause and think about whether something was "worthy" of a commit, thus I was unable to track my changes. This problem just doesn't exist in Git, though some care is needed when publishing (as w/any system).

I'm unaware of anything within base Mercurial that lets me do what I can do with git. Maybe the answer is to use the extensions, however that's a bit unsettling when some of them are being depreciated (eg. hg queues). Often times I found myself cloning and maintaining multiple directories for something that was better off as one thing. This led to reluctance to track changes, which is clearly evil. I guess I must have been doing something wrong, but I've heard similar feedback from others regarding Mercurial. I loved using hg and would have no problem using it (it was my first); I just prefer git now.

Re: How to teach Git

#254

Post by gglitch »

WorldMaker wrote: post #103
Ajedi32 wrote: post #47

Earlier quoted context omitted.

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

I got into the habit of teaching people `gitk`. It's not the prettiest tool, but it's included with most distributions of git, defaults to a decorated color graph log, and thus avoids the "copy paste this weird config line" step on other people's machines.

I have a soft spot for Tk interfaces. I hope they become cool again (or, I mean, for the first time).

Re: How to teach Git

#255

Post by jstimpfle »

oblio wrote: post #227
jstimpfle wrote: post #226

Earlier quoted context omitted.

git is much more powerful. It gives you control to manipulate the repository like say, a relational database. If svn is enough for you, that's fine.

> It gives you control to manipulate the repository like say, a relational database And how many people do that? Not that many. This angle is a bit like the guy who said that he doesn't want Unix file names to be UTF-8 text-only, because he crafted a sort of relational database on top of a Unix FS and by having file names be just text he couldn't do some super niche trickery. I think it was in response to this articl…

> And how many people do that?

I regularly fix my commits, (just like I edit most comments on hn within a few minutes after sending them). And sometimes I take back commits even from the server (working in small teams).

Locally, I regularly switch to older commits and branches to try things out. In svn all this requires a network connection and it is quite costly. Which means you do a hell of a lot less of it. And I would assume it shows in software quality.

Man, how I used to freak out regularly waiting for a stupid svn diff or svn log to finish. These operations are the bread and butter of version control, and they are instantaneous in git.

Or, aren't you regularly blocked from doing quick fixes using svn for problems that you saw, but couldn't fix them because you had a different pending commit? I have that often when working with svn (admittedly I don't know svn very well, but I'm sure it is a real blocker in many situations). Situations like these are easy in git.

And how idiotic, after all, is it that we have to setup a SERVER to keep a simple log of changes to a few files? I have so many small ephemeral projects that I simply put in my laptop's home directory. There is no point in maintaining server repositories for those. Git is simply a tool that lets you do that. It lets you do bookkeeping of your data. It's a tool. While svn feels like an inflexible process. (yes, svn has the file:// protocol, but you still have to setup a separate repository, right?)

In a sense, git is the sqlite of version control. You are really missing out.

> It is, but every job these days forces you to use git.

Here in Germany, svn seems to be the norm still in the engineering domain. But I figure the situation is quite different for web shops.

> And most places I've worked at, git is used as a glorified SVN where people just have a 2-step commit to a remote server.

That's my experience as well. When it's about communicating changes most setups will be centralized just like a regular svn setup. It's a fine approach for small teams. But with git you still have the huge advantage of being independent of the server. And you can easily fix problems that are already committed to the server.

Re: How to teach Git

#256

Post by LyndsySimon »

zwieback wrote: post #152
ahartmetz wrote: post #60

And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"

Love it. I'm sold on git but it often feels like I'm in one of those man pages.

In my experience, it gets better. After a while you know everything you need to not only do your job, but to understand and resolve common issues. After a couple of years you'll be at the point where the only time you have to dig through manpages is when you're trying to do something esoteric or clever.

Re: How to teach Git

#257

Post by LyndsySimon »

war1025 wrote: post #95
cyborgx7 wrote: post #19

Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".

`git log -p` is my favorite obscure git command. Shows you commit by commit changes. If you specify a path, it limits to only those files. If you do a single file you can do `git log -p --follow ` and it will track the file across moves and renames. Also `git whatchanged` is a super helpful command to see just the list of files that changed in each commit

`git add -p` is also very, very useful. I use it all the time, to the point that I've aliased it to `a`.

If you're interested, here's my .gitconfig, including all of my aliases: https://gitlab.com/lyndsysimon/dotfiles/blob/master/git/gitc...

Re: How to teach Git

#258

Post by war1025 »

LyndsySimon wrote: post #257
war1025 wrote: post #95

Earlier quoted context omitted.

`git log -p` is my favorite obscure git command. Shows you commit by commit changes. If you specify a path, it limits to only those files. If you do a single file you can do `git log -p --follow ` and it will track the file across moves and renames. Also `git whatchanged` is a super helpful command to see just the list of files that changed in each commit

`git add -p` is also very, very useful. I use it all the time, to the point that I've aliased it to `a`. If you're interested, here's my .gitconfig, including all of my aliases: https://gitlab.com/lyndsysimon/dotfiles/blob/master/git/gitc...

Completely agree. I think a lot of people would enjoy git more if they made better use of the `-p` options.

Re: How to teach Git

#259

Post by romwell »

P_I_Staker wrote: post #239
karmakaze wrote: post #230

Earlier quoted context omitted.

I don't think the complexity of git's command options is a UI problem. It results from the basis of its operation. We could change some names, add or remove some concepts to how some of the operations are performed, but there are simply a large number of actions to handle many edge cases. A better solution for prose was to always be merging with live multiple collaborator updates. Conflicts are visible in real-time.…

Yes, I don't really understand all the people trying to "fix git". Git's fine, though the complexity makes it challenging, especially for new users. However the complexity is a direct result of useful features. "Keeping it simple" is great, except when the complexity is needed. I'm hard pressed to name any features I could do without.

>I'm hard pressed to name any features I could do without.

Nobody is complaining about there being too many features. People are complaining about the arcane incantations that one needs to conjure to call them.

Re: How to teach Git

#260

Post by P_I_Staker »

romwell wrote: post #259
P_I_Staker wrote: post #239

Earlier quoted context omitted.

Yes, I don't really understand all the people trying to "fix git". Git's fine, though the complexity makes it challenging, especially for new users. However the complexity is a direct result of useful features. "Keeping it simple" is great, except when the complexity is needed. I'm hard pressed to name any features I could do without.

>I'm hard pressed to name any features I could do without. Nobody is complaining about there being too many features. People are complaining about the arcane incantations that one needs to conjure to call them.

Good point. I wouldn't say nobody though. There are people out there that think there are too many commands. I've even seen academic papers that claim the staging area is problematic. I love the staging area, and don't think it's terribly confusing; there's always commit -a if you don't want to use it. It does lead to some confusion, but it's worth it for the added features.

That's just one example, but there definitely are people that think git's too featureful. As for more valid criticisms, I'd agree. I've heard the CLI compared to being in an abusive relationship. All that said, I can't really think of a better way to handle things without losing useful functions. In which case, I don't have any better ideas, and don't really know what I'm criticizing.

Post reply on HN