[ --resist-object | --prove-photograph-log | --roll-berate-history ]

April 28, 2014 3:42 PM

git man page generator
posted by OverlappingElvis (76 comments total)

Okay, now that's effin funny.
posted by Tell Me No Lies at 3:50 PM on April 28, 2014

(this is a parody of the inscrutable documentation for Git, a popular tool for revision control)
posted by LogicalDash at 3:59 PM on April 28, 2014 [2 favorites]

As a regular user of git, I particularly appreciate that they put the disclaimer at the top, because I actually would have set up a repo and tried some of these to see what they did.

Yes, git really is like that. Apparently there's some sort of "aha, I get it now" switch that turns on for people. Hasn't happened for me in the years I've been using it; I still just type boilerplate commands and hope it works.
posted by straw at 4:03 PM on April 28, 2014 [17 favorites]

LogicalDash - thank you for the explanation. These are the only Gits I previously knew.
posted by Joey Michaels at 4:10 PM on April 28, 2014

If you use git, you want to know about this trick for remembering the obscure flags.
posted by feloniousmonk at 4:13 PM on April 28, 2014 [5 favorites]

Are there people who actually use git entirely from the command line? If I didn't have GitX, I'd be totally out of my depth.
posted by indubitable at 4:27 PM on April 28, 2014

FWIW, Tower is a wonderful OSX git client.
posted by xmutex at 4:33 PM on April 28, 2014

Apparently there's some sort of "aha, I get it now" switch that turns on for people.

Conceptually, sure. You get the ideas. The UI remains terrible, no matter how much you use it, because it is terrible.

That said...

Are there people who actually use git entirely from the command line?

I use git-gui to throw together commits all the time, and gitk or GitHub's stuff for navigating history, but in the general case, I have only seen avoiding the command line result in suffering.
posted by brennen at 4:37 PM on April 28, 2014 [3 favorites]

I use git from the command line, and tend to edit .git/config by hand when necessary, but also use github enterprise (a web interface) for the workflow with my team.

Graphical git tools kind of scare me because I have no idea what they're doing, or what state they're leaving everything in.

Overall I would say I'm just barely proficient at git, and getting to this level took me 6 months.

Anyway this thing is awesome and spot-on.
posted by Pruitt-Igoe at 4:40 PM on April 28, 2014

git-shave-head: shave the remote heads opposite of the stashed non-bundled unstaged submodules
posted by ardgedee at 4:40 PM on April 28, 2014 [5 favorites]

I use it completely from the command line many times a day for work and personal projects.* I've noticed that everyone I work with has a particular workflow, set in concrete, based on how they learned to use it and are terrified to deviate from that workflow. I can't count how many times I've shared what I find to be a useful command with a coworker only to have them give me the "I'm never going to try that" smile and head-nod.

*- Not trying to brag. I still look at my cheat-sheet every time I use ln, find or tar, lest I screw them up, but somehow git makes sense to me. I'll admit that the man pages are not the most user-friendly documents in the world. There are also many stack overflow questions about git that have overly confusing answers that seem to be designed to scare new developers away.
posted by double block and bleed at 4:44 PM on April 28, 2014 [10 favorites]

I also think that this is funny as hell.
posted by double block and bleed at 4:46 PM on April 28, 2014

There's a running joke at my workplace: after we scramble our way out of a git-related mess we say "Oh yeah. Just do ${list of commands which probably include git reset}. Intuitive." To get a flavour on how inscrutable the man pages are, this is from the actual man pages for git for the rebase commmand:

git-rebase - Forward-port local commits to the updated upstream head

It's one of those "I only understand what each of those individual words mean."

There's a bunch of other git complaints in a reddit post where apparently some other programmer has also used Markov chains to generate just as nonsensical man pages.
posted by cyberscythe at 5:06 PM on April 28, 2014 [3 favorites]

At least you aren't using svn, like a peasant
posted by thelonius at 5:10 PM on April 28, 2014 [4 favorites]

Now I know where SAS documentation comes from.
posted by needled at 5:19 PM on April 28, 2014 [3 favorites]

git problems are caused by not visualizing version control mechanics exactly the way git does

coincidentally, the problems with all other version control tools are caused by this very same factor
posted by idiopath at 5:19 PM on April 28, 2014 [3 favorites]

If it weren't for git rebase -i to fixup topic branch commits, the master branch log would be full of my interim commit messages like:

"Stupid before_save callback is broken in the billing model. Screw it. Im going home"

"Why the fuck are all of the fucking params nil in the fucking activity controller"

"Cleanup in aisle Person.rb:534 -- bring a fucking mop"

"View works but is unfit for human eyes"

and

"Suck it haters -- IT WORKS -- even a broken clock is right twice a day"

All of these are real ones I've used in the past week. Please don't judge: I abuse git so that I can be nice to my coworkers. After all of my bitching, I end up with one clean, professional sounding commit like this:

FEATURE: Allow users to associate Carrier Systems with Carrier Accounts
PT 12345678
posted by double block and bleed at 5:35 PM on April 28, 2014 [22 favorites]

I abuse git so that I can be nice to my coworkers.

This worked well for GitHub.
posted by xmutex at 5:36 PM on April 28, 2014 [7 favorites]

I really should code something up that makes a fart sound every time a pull request is accepted.
posted by srboisvert at 6:11 PM on April 28, 2014 [2 favorites]

Are there people who actually use git entirely from the command line?

Absolutely
posted by Noisy Pink Bubbles at 6:26 PM on April 28, 2014

Apparently there's some sort of "aha, I get it now" switch that turns on for people

The "ah-hah!" moment for me was understanding that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.
posted by markr at 6:27 PM on April 28, 2014 [32 favorites]

Yes that's very much in the spirit of this post
posted by indubitable at 6:29 PM on April 28, 2014

After three years of using git every single day I think I pretty much "get" it, haha.

I think a huge help would be, rather than bombarding people with commands, to first explain the key concept: That branches are not copies of files on your computer like in other source control, but that git uses metadata files to actually change the text of files when you change branches.

That and the immensely confusing use of the word "checkout" to mean something massively different than what a) every other source control and b) common sense would lead you to think it meant.
posted by drjimmy11 at 6:30 PM on April 28, 2014 [1 favorite]

This is why I've been more-or-less avoiding git. The last thing I need is a version control system that adds complexity to my life. That's the opposite of the point, isn't it?
posted by escape from the potato planet at 7:11 PM on April 28, 2014

I think you can get by in a GUI as long as you don't need to do detailed rebases or merges. Without those (which can be very useful), it does not have to be overwhelmingly complex. Certainly, it's simpler than some sort of ClearCase-type enterprise monster.

It's basically a bunch of commits in a graph. Commits are diffs. Points on the graph are labeled as "branches."

The language becomes complex because there's just a ton of things you can do with graphs, which does make that documentation rough to read.

However, it does make the grammar for the man page generator fun to browse!
posted by ignignokt at 7:20 PM on April 28, 2014 [1 favorite]

So...

I get the impression that a lot of people who use git on a daily basis are "[typing] boilerplate commands and [hoping] it works". Is that perception accurate?

Because...that really makes me wary. I don't want my tools to be doing arcane voodoo that I don't understand.
posted by escape from the potato planet at 7:28 PM on April 28, 2014

The "ah-hah!" moment for me was understanding that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

Was this sentence also the product of a markov process? Much like the fake man pages, I had to get about halfway through before I hit something I understood confidently enough to be sure it was nonsense.

Are there people who actually use git entirely from the command line?

For anything I do myself, yes. I'm lazy enough to just use Github's interface for viewing others' pull requests as diffs.

The last thing I need is a version control system that adds complexity to my life.

We stuck with Subversion for years, until a glitch in Sourceforge's servers made it impossible, for just that reason. In hindsight that was a huge mistake. Git has a bit of a learning curve and a few idiosyncracies (I rebase branches more frequently than I'd like, to avoid further "merge vs rebase" arguments with collaborators...) but it's more than worth the hassle. Even the arguments are deceptive - however you choose to juggle branches, doing so is easier than svn ever was.
posted by roystgnr at 7:31 PM on April 28, 2014 [2 favorites]

Mercurial has its warts, but I've found it to have just enough DVCS foo to not make you want to kill something. Anyone who's frustrated by the git learning curve should give hg a go.
posted by tonycpsu at 7:36 PM on April 28, 2014

I use git entirely from the command line, but this is brilliant.
posted by cj_ at 8:13 PM on April 28, 2014

I'm so sorry.
posted by deathpanels at 8:47 PM on April 28, 2014 [2 favorites]

> I'm so sorry.

It's -c or -x for compress or extract, and -f for filename. Every time.

The ordering of tar flags is understandable enough in itself, but confusing compared to other unix commands that usually have different standard orders for input and output filenames, and never operate on entire directories.

What's great about git is it has a zillion subcommands, each with a completely different personality. Want to merge a patch from a local branch? That's a totally different vocabulary and syntax than merging a patch from a remote branch.
posted by Phssthpok at 9:08 PM on April 28, 2014

deathpanels: "I'm so sorry."

tar -xvjf file.tar.bz2 isn't really all that hard to remember.
posted by Joakim Ziegler at 9:39 PM on April 28, 2014

Are there people who actually use git entirely from the command line?

There are things that I don't think you can do via command-line, like forking. But a lot of it can be done from the CLI, and it is usually preferable to do so, believe or not.
posted by Blazecock Pileon at 9:40 PM on April 28, 2014

I have never used anything but the git command-line to interact with git repositories, unless you count "download zip" from github packages occasionally.

But the documentation can be mystifying and the command-line UI is clearly developed by asking an expert UX person to design the opposite of a good experience.
posted by R343L at 9:46 PM on April 28, 2014

Are there people who actually use git entirely from the command line?

Me. But mainly because 90% of my tasks are git pull/status/diff/commit/push. I generally just find the command line easier for this.
posted by xmutex at 9:58 PM on April 28, 2014 [1 favorite]

100% command-line here, it’s just faster to type things and the Github-for-Mac app is sloppy and half-done like I’ve come to expect from Github.

Git really only has two features (commit and merge) but they come with a thousand names.
posted by migurski at 11:31 PM on April 28, 2014 [1 favorite]

Git is complex. Some of the actions that it let's you perform on the underlying data structure don't really have any easy real world analogues. Unless some other aspect of your life includes a directed aycyclic graph with nodes identified by the hash of their contents.

My aha moment was really understanding those data structures.

So suck it up designers. Learn to use the command line and stop polluting the project history with 14 million pointless commits each day.

I mean damn, you complain about Git, and you love Photoshop? You know what Photoshop needs? A CLI... Imagine:

photoshop resize image.jpg 640x400 --keep-proportions

... I've never understood why people think tiny rows of abstract icons are easier to remember than 5 - 10 composable words...
posted by aychedee at 11:40 PM on April 28, 2014 [2 favorites]

It's one of those "I only understand what each of those individual words mean."

git-rebase [--interactive] is like slow-motion action replay for commits where you can jump and say "NOOOOooooooo!" at any time and amend a commit from the past before it gets replayed on top of the current commits. The common use case for this is to replay work from a branch on top of the current master to prevent merge commits. It's pretty powerful, but with great power...

So don't rebase any work you have already pushed, unless it's on a private branch (maybe, some would argue against rebasing *anything* that has been pushed). I rarely use rebase because i'm not bothered about having a linear history - git logs can be bent to your will, so if you don't want to see a mass of merge commits then RTFM and supply the necessary flags rather than enforcing policy that destroys the DAG nature of git commits. Occasionally i will notice that a commit n levels deep contains a stupid bug that the tests didn't pick up on, so being able to replay my work and fix in flight instead of reverting the original commit is very useful. I don't push my changes until end of day, so i can play around with the last few hours local history without that ever appearing on the remote end.

git "suffers" from the problem that you can know enough to happily use in certain ways or for a long time without actually knowing what is going on under the hood, but this problem is in no way unique to git. We've become accustomed to intuitive user-friendly interfaces that DTRT and hold our hand through more complicated operations. Not using the command line compounds this issue because there's another layer of abstraction. But one day you will accidentally push an incomplete feature that completely breaks master to the remote and suddenly you're tiptoeing into git reset and git push --force territory. If you mess that up and delete commits that you shouldn't have then you learn about git reflog.
posted by lawrencium at 12:06 AM on April 29, 2014

Photoshop has embedded JS, actually.
posted by xiw at 12:06 AM on April 29, 2014 [1 favorite]

git reflog has saved my bacon a few times, especially when I first started with git.
posted by double block and bleed at 3:31 AM on April 29, 2014

Photoshop includes interpreters for Javascript, AppleScript, and VBScript. It's been years since I've checked the documentation, but if recent versions have added any kind of network socket methods, Photoshop will be capable of fulfilling JWZ's Law: Every program attempts to expand until it can read mail.
posted by ardgedee at 3:53 AM on April 29, 2014

There are things that I don't think you can do via command-line, like forking.

Absolutely you can do this via command line. Check out the branch you want to fork from and then do git checkout -b [branch-name]. You'll get a branch based on the branch you currently have checked out. I'm pretty sure that there is nothing you can do via a GUI that you can't via command line, because the command line is the only official implementation of git.

This is why I've been more-or-less avoiding git. The last thing I need is a version control system that adds complexity to my life. That's the opposite of the point, isn't it?

I used to be scared of git. I worked at a place that used svn, and for my personal stuff at the time I was using Mercurial with BitBucket. It seemed so clean and easy! Why would anyone use git? When it came down to it, though, there was a debate at work about changing version control systems, and I didn't feel strongly enough about Mercurial to argue in its favor. I thought that it didn't offer enough advantages to make the pain of switching our VCS worth it.

Then, I switched to a company that uses git exclusively. I struggled for a while, but when I finally grokked git, I realized that it is simply what a VCS should be. All of my personal projects use git now, and I even evangelized it back to my previous company (who eventually switched to it).

Branching and merging in git, once you have dealt with it enough, is relatively simple. That doesn't mean it's easy—you still have to understand merges and rebases before it becomes "obvious" to you—but eventually there comes a point where the git model just makes sense and is so obviously better than what-went-before (ugh, svn) that you won't voluntarily go back.
posted by sonic meat machine at 4:23 AM on April 29, 2014 [2 favorites]

 → “You know what Photoshop needs? A CLI...”

This why we still have netpbm.
posted by scruss at 4:41 AM on April 29, 2014 [2 favorites]

I guess I should clarify before my name is forever mud as a software developer — I get the rebasing, merging, pushing etc. operations and find it easiest to do that all from the command line. But when it's time to visualize the revision graph, I'd much rather have something draw me a nice picture. Or if I want to see what the file system tree looked like at some point in the past, or take a quick look at a file's contents from a past revision without stopping what I'm doing, stashing and checking out a different branch, a GUI just feels like an easier way to get things done. When I'm staging changes, would I like to type out the path to each individual file to queue them up? No, I'd rather double click on the ones that have been marked as changed. etc.
posted by indubitable at 5:07 AM on April 29, 2014

We use SVN at work, and I used to be pretty happy with that - and then I had to fix about eleven closely-related bugs in quick succession, and because my manager was a bit slow in turning around code reviews I ended up with four different SVN working copies holding all the changes in various changelists. It was at roughly that point that I decided this wouldn't work any more.

So now I have a single SVN working copy, with my own private Git repo sitting on top of it. Every bug and feature gets its own Git branch, and I only let myself check into SVN from the master Git branch, which leads to a nice branch-fix-merge-checkin workflow. It's had its teething troubles, but I realised the benefit of my system when I deleted the entire working copy this morning and had to check out the tip again from SVN, and all my Git branches still worked happily as if nothing had happened. Never going back.

(The generated man pages are, however, scarily accurate.)
posted by ZsigE at 5:09 AM on April 29, 2014

Maybe I'm in the minority, but I find git's conceptual data model to be really, really simple. It's so simple that when you peek under the hood there's not much there -- the project even refers to itself as "the stupid content tracker". Sure, the documentation has its own jargon, but that's the case for lots of technical niches. I've never really had an issue understanding what the documentation was trying to convey.

Here's my pitch to anyone even moderately technically inclined:

A repository is a directed acyclic graph where each node contains a complete copy of all of the project's files at a given point in time as well as some metadata. A node in this graph is called a commit, and is assigned a unique identifier. Edges in the graph point from a commit to one or more parent commits. Tags and branches are ways of associating a human-friendly name with a reference to a commit. A tag is static and always refers to a given commit, whereas a branch (or "branch head") is automatically adjusted when a new commit is added such that it always refers to the "tip" of a given line of development. (As a convenience to the user, a log of these adjustments over time is maintained, called the reflog.) A reference to the parent commit of the current working tree is called HEAD. A special staging area that holds what will become the next commit is called the index. Whole files or portions of files can be copied from the working tree to the index (and vice versa) giving the user fine grained control over what changes are to be part of the next commit. The repository is garbage-collected at regular intervals, and any commits unreachable through branches or tags (and their ancestors) are deleted.

If you understand that, you understand the bulk of what you need to know to use git; you just have to read the documentation to determine the specific commands and options necessary for a given operation.
posted by Rhomboid at 6:05 AM on April 29, 2014 [5 favorites]

> A repository is a directed acyclic graph...

I will bet most people with a passing interest in git gave up there.
posted by ardgedee at 6:11 AM on April 29, 2014

I did say "moderately technically inclined", and there is nothing inherently complicated or unintuitive about the concept of a DAG. You can learn all you need to know about it in 30 seconds by looking at the illustration that's included in the wikipedia article.
posted by Rhomboid at 6:21 AM on April 29, 2014

And yet this still looks better than the CVS I'm used to at work.
posted by valrus at 6:30 AM on April 29, 2014 [1 favorite]

Actually, no, that chart explains nothing unless one knows what the numbers and symbols mean.

Sure, it can be hashed out, but that's an added layer of education necessary on top of parsing the jargon in your explanation to understand the explanation.

I mean, this is not about educating me (I've been using git frequently enough to grok what you said), this is about the barrier of entry to git generally.
posted by ardgedee at 6:37 AM on April 29, 2014

The trouble with git is not that the underlying architecture is complicated, because it isn't. The trouble is that the interface is the software equivalent of Comic Book Guy.
posted by grumpybear69 at 7:06 AM on April 29, 2014 [1 favorite]

FWIW, I had been using git for over a year with few issues before I ever heard of a "directed acyclic graph".
posted by double block and bleed at 7:13 AM on April 29, 2014

Dear AskMe: how do I convince a reticent manager to move from deeply entrenched SVN to Git? He is terrified of change.
posted by five fresh fish at 7:13 AM on April 29, 2014

Also, that's not a pitch, it's more like a pitchfork :)
posted by double block and bleed at 7:13 AM on April 29, 2014

Alternatively… Dear AskMe: how do I convince my programmers that SVN is a viable repo tool, and not a burden too great to bear? I'm tired of their whining.
posted by five fresh fish at 7:17 AM on April 29, 2014 [2 favorites]

Which are you, 5FF? Manager or programmer?
posted by grumpybear69 at 7:19 AM on April 29, 2014

I'm a photon. Wave and particle explanations are equally interesting and useful.
posted by five fresh fish at 7:24 AM on April 29, 2014 [1 favorite]

five fresh fish:

It's the same as making a case for or against any technology.

Factors for using git:

+ speed
+ ease of use (compared to SVN, I'd argue git is better)
+ flexibility of process (easy to make new branches, tags, etc. Teams can develop new workflows)
+ can reduce load on repo server
+ encourages smaller commits
+ greater code analysis tools (git log, blame, bisect... enhanced w/ small commits)
+ greater visibility on code (better web tools, GitHub, GitLab, etc.)
+ clearer code history (if your devs do rebases... but this might be painful and not useful, depending on the project)
+ attracts new devs (I'd be weirded out if I learned I had to use SVN for a potential job... but that's just me)
- have to learn *some* git concepts and tools
- have to configure and maintain new repo server

Most of the positives are great for devs, but need to be recast for management. For instance, code visibility and clarity can reduce number of bugs, or make them faster to fix. Ease of use and speed can let devs get more work done.

The challenge, of course, is to make metrics for this so that you can understand how the change is faring. If management and developers can agree on metrics, then they both can see how a switch to git is going, and they will hopefully both agree whether to continue or not.

If, as a manager, you absolutely can't make metrics then you should probably trust the team's judgement. Without metrics, you can't really tell if switching to git breaks stuff. You can't see it. It's invisible to you. So, let them do what they want because you trust them.

If you don't trust your team, you have bigger problems.
posted by sixohsix at 7:50 AM on April 29, 2014 [2 favorites]

FiveFreshFish: Next time there is a horrible SVN merge hell, SubGit your existing repo and have your best git person do the merge. Repeat until you forget to move the results back to SVN.
posted by bdc34 at 7:55 AM on April 29, 2014 [2 favorites]

Oh yeah, bdc34, that's a good one! Having a rogue dev dump svn into git with history, and then doing merges in git is a pretty fantastic demo.
posted by sixohsix at 7:59 AM on April 29, 2014

My previous job didn’t switch from CVS until Trac made SVN sensible, and didn’t switch from SVN until Github made Git workable. There has to be a compelling external reason to do it, beyond the merits of the tool. I don’t think Git is easier to use than SVN for example, because in SVN everything is a file or directory, you can see all your branches & tags, and the monotonically increasing revision numbers are easy to reason about. In a workplace, you’re not continually initing throwaway repositories like Git makes easy.

Github offers an “enterprise” version but thanks to their policy of not having managers tell people what to work on, I’m told it’s a backwater compared to the site and nobody feels like improving it. The pay-for version’s private repos offer some measure of security.
posted by migurski at 8:25 AM on April 29, 2014

? I thought it was exactly the same thing as the github site, but packaged as a virtual appliance. It's a host-your-own github.com where you control where all your data goes, and everything is private.

Maybe it's missing some new features that I'm not aware of, but from my perspective as a user, the main github.com is not really different from our instance of GHE. And they are keeping GHE up-to-date with security patches and bugfixes.
posted by Pruitt-Igoe at 9:51 AM on April 29, 2014

If, as a manager, you absolutely can't make metrics, you're probably going to have trouble selling this change to your manager who is more concerned with high-level deliverables which depend on, but are not materially related to, your source control system. This is the challenge with all infrastructure upgrades: they divert resources away from revenue-generating activities. So your best bet for success is to time the request properly, i.e. during a lull in the project cycle.
posted by grumpybear69 at 9:55 AM on April 29, 2014 [1 favorite]

The link is hilarious, and depressing.

I use git every day, and I understand it pretty well, but as others have said it has a really really terrible user interface.

As far as I can see, its popularity is based almost entirely on two things:
1) Linus wrote it.
2) GitHub.

Note there is no "3) It's the best" - because Mercurial and Bazzar are at least as good.

Cost of adoption is, anecdotally, large. I've seen it kill tens of developer-days on a couple of small projects where people (average programmers) had to learn it. Periodically people occasionally "forget to push" for a couple of days then somehow nuke their local repositories (copy-paste something from stackoverflow... oops, I lost my head... paste something else... no idea what's going on now!), that's costly too. From a management oversight perspective a DVCS can be a pain too, with centralised repositories you can see who's working on what because the commits roll in constantly - but with git etc you can suddenly discover two people have spent the last day duplicating each-others work unwittingly.

I don't hate it, but I'm not a big fan either. I just don't think version control should be difficult, certainly not among the more difficult aspects of (some) programming jobs.
posted by dickasso at 10:37 AM on April 29, 2014 [3 favorites]

Note there is no "3) It's the best" - because Mercurial and Bazzar are at least as good.

Well, I would argue that git is the best. This site covers the highlights of its advantages, and this blog post illustrates some of the issues with Mercurial's underlying model. (In short, its branching is anemic compared to git.)

I've seen it kill tens of developer-days on a couple of small projects where people (average programmers) had to learn it.

Yes, there is a learning curve. I would expect that with any new tool, though; it's a cost to be paid for changing tools. The way to mitigate this is just to have someone who knows the tool well do focused training. In the end, the productivity you gain from switching to git (or even another DVCS) will be worth it.

Periodically people occasionally "forget to push" for a couple of days then somehow nuke their local repositories...

I've never seen this, and there's no excuse for it. It's like saying that Linux isn't good because sometimes people run rm -rf /*. Uh, okay, sure. Just don't do that. If you horribly hose your branch somehow, through a mangled merge or something similar, you can always checkout master and then use git cherry-pick [sha] to apply your individual commits from your previous branch to the new one. This will give you a pristine branch with only those commits you explicitly want.

From a management oversight perspective a DVCS can be a pain too, with centralised repositories you can see who's working on what because the commits roll in constantly - but with git etc you can suddenly discover two people have spent the last day duplicating each-others work unwittingly.

This is a people problem. You need a ticketing system that makes it obvious who's working on what, or perhaps a set of smaller sub-teams that each work on limited functional areas. It has to be easier for people to say "Oh, the FooValidator integration. Wasn't Mark working on that?" It's not the fault of the tool if your team isn't talking to each other.

I just don't think version control should be difficult...

It's not. In my experience, git is much easier than svn for all but the most basic needs; if you have a large-ish codebase and several teams committing to it, the fast, effective branching and merging alone can save hours of toil. Ever had some poor bastard sitting there with Meld trying to figure out what the hell svn did to a merge, and how to get it cleaned up? Merge conflicts in git are usually a couple of lines at most, and using git rerere means that the resolutions can be recorded so that whenever the same conflict occurs, the resolution is used.

(Also check out the articles "A Successful Git Branching Model" and, for a more advanced setup using rerere, "A Pragmatic Guide to Branch Per Feature git branching strategy".)
posted by sonic meat machine at 12:04 PM on April 29, 2014 [2 favorites]

I'll only use git from the command line, except for read-only branch/graph visualizations, which are pretty sucky to infer from the command line. But my use of the command line for git is a deliberate decision. There's a reason that so many git commands are split up from each other, where they might otherwise be aggregated for common compound functions: it gives you stages to review, and possibly back out, before you truly commit to your changes.

The GUI tools make things easier, generally. But I don't want most of my write operations to be easy. That simply makes it easier to screw something up, because the GUI tool will "helpfully" infer what you actually wanted to do, and make it so. Had that push remote set wrong over in the corner when you went to commit? Well that's too bad; you just overwrote the upstream master branch with unreviewed changes.

From the command line, git actually makes it pretty difficult to do something you regret, and can't back out of. It makes it exceedingly hard to lose data. My firsthand and secondhand experience with GUI tools is that they make these things much easier, to the demise of many a developer.
posted by Brak at 12:51 PM on April 29, 2014 [2 favorites]

By the way, if you want a graphical-like history experience from the command line, try:

git log --graph --pretty="format:%h %cn - %s %d (%cr)"

…or the easier-to-remember:

git log --graph --oneline

Output looks like:

* 7a83d2d Michal Migurski - Crosshack is over now  (HEAD, origin/gh-pages, origin/HEAD, gh-pages) (14 hours ago)
* 4b3d361 Michal Migurski - Getting the Sutro GIF to fill the screen  (14 hours ago)
* a01dbc4 migurski - Updated words  (20 hours ago)
*   9104ff3 migurski - Merge pull request #12 from prestonrhea/gh-pages  (20 hours ago)
|\  
| * 017c651 Preston Rhea - Changed redirect to sutro-spin  (21 hours ago)
* |   5393267 migurski - Merge pull request #11 from prestonrhea/patch-1  (20 hours ago)
|\ \  
| |/  
|/|   
| * 0e91ebc Preston Rhea - Updated sutro-spin.html with faster redirect time  (20 hours ago)
| * 727464c Preston Rhea - Change sutro-spin.html redirect to 30 seconds  (21 hours ago)
| * 0a164ac Preston Rhea - Create sutro-spin.html  (21 hours ago)
|/  
* 206828a Michal Migurski - Actual number of seconds  (25 hours ago)
* 6414927 Sam - Use the embedable version of the youtube video.  (26 hours ago)
* 144f461 migurski - URL should not be in quotes.  (26 hours ago)
* 8a65511 migurski - Need to link to the local frame, not the remote site.  (26 hours ago)
*   cff1a3c migurski - Merge pull request #9 from ainsleywagon/patch-2  (26 hours ago)
|\  
| * 571a709 Ainsley - updating justabill.html  (26 hours ago)
| * cdffc66 Ainsley Wagoner - Added .html to the end of crosshack02 file  (26 hours ago)
| * 18c643b Ainsley Wagoner - Adding just a bill slide  (26 hours ago)
| * 29f0843 Ainsley - Editing to route to Just a Bill screen next  (26 hours ago)
|/  
*   6378872 Anna-Marie - Merge pull request #8 from ainsleywagon/patch-1  (27 hours ago)
...

posted by migurski at 1:34 PM on April 29, 2014 [2 favorites]

Git: Motivating new "Intro to Git" articles for almost 10 years!
posted by IAmBroom at 2:09 PM on April 29, 2014 [3 favorites]

migurski: "By the way, if you want a graphical-like history experience from the command line, try...

or:

gitk

to see it all in a GUI window with lots of extra info.
posted by double block and bleed at 4:41 PM on April 29, 2014

I've used something like 7 different version control systems in professional settings.

I think I've used git the least of them, so I've spent less time fighting with it, compared to the time lost to sorting out svn's made-up tree conflicts, or calming bitkeeper down after eclipse renamed a directory without telling it, or I don't even know what Perforce's problem was that one time. So yeah, they all have a way to get into a state where you start wondering if you'd be better off just throwing out the entire computer, starting over and rewriting your changes from a clean checkout. Hard-to-figure-out-and-easy-to-shoot-yourself-in-the-face-with kind of just seems like it might be an inherent property of version control. It's certainly not unique to git.

I will say one place where a distributed version control system really pays off is when your IT guy accidentally rm -rf's / on the server and hasn't made any backups for 6 months.
posted by aubilenon at 5:56 PM on April 29, 2014 [1 favorite]

I've introduced git to a lot of teams, and the nice thing with GUIs for new users (apart from that being what most are used to) is that it makes looking at the file diffs they are about to commit much easier.

On the command line they tend to just commit all changes and push. Maybe doing a quick git status first. You absolutely can teach people to use git diff or whatever, but asking them to click through the changes files quickly and eyeball the changes is an easier well. I also think the nicer display of the tree helps new users see what is going on.

Of course once users start getting the hang of the concepts the command line is faster for most things.

Even though I'm comfortable on the command line, there are still things I like using a GUI for. In particular building up a series of commits from a bunch of outstanding changes rather than just adding everything, and especially if you're going to be doing interactive staging with hunk selection.
posted by markr at 6:34 PM on April 29, 2014 [1 favorite]

markr, I think the most glorious git command is git add -p, which will let you page through all of your "proposed" changes before actually adding them to the index. I've caught printf-debugging statements and so on many times.
posted by sonic meat machine at 6:47 PM on April 29, 2014 [3 favorites]

I hadn't seen -p. Definitely nicer than trying to do a full git add -i on the command line and I can see myself using it. The problem remains that I don't think console windows display diffs as cleanly as a GUI can.
posted by markr at 6:54 PM on April 29, 2014

sonic meat machine: I get that git makes it easier to do the hard stuff, but at the same time it definitely makes the easy stuff (which is 90% or more of total 'stuff') less easy. Pragmatically I'd rather keep the easy stuff totally idiot-proof for the idiots at the cost of making the hard stuff more painful for the few people who have to deal with it.

Yes, the procedural issues I mentioned should be solved by getting the right people and using the right tools and processes - however I'm not a hiring manager or a head of IT, I'm a contract lead/senior dev. I get parachuted in for a few months at a time and generally just need to work with the situations I'm put in. Give me a few substandard developers, no issue tracking system and Subversion and I'll be in a better place than with a few substandard developers, no issue tracking system and git.

When everyone's highly competent, git is great. This is rare.
posted by dickasso at 1:30 AM on April 30, 2014

Adding an entire file to a commit is almost never what you want to do. That's why git add -p is so great. It lets you stage a coherent set of change across your entire project. It doesn't matter if those changes exist in 20 files along with lots of debugging print statements. Just add the individual lines you want and commit that.

What a wonderful user interface :)
posted by aychedee at 5:13 AM on April 30, 2014 [1 favorite]

The problem remains that I don't think console windows display diffs as cleanly as a GUI can.

Oh sorry, that was a glaring omission in my use of GUIs with git. I definitely have a GUI-based difftool/mergetool configured, that the command line parcels out to for those operations. If I had to parse console diffs to review changes, I'd go mad. I like DiffMerge on OS X, personally. But there are lots of other ones to choose from.
posted by Brak at 12:08 PM on April 30, 2014