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

A Hacker’s Guide to Git

wildlyinaccurate.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: A Hacker’s Guide to Git

#111

Post by aidenn0 »

wmt wrote: post #102

"Once you start talking about branching, merging, rebasing, multiple remotes, remote-tracking branches, detached HEAD states… Git becomes less of an easily-understood tool and more of a feared deity. Anybody who talks about no-fast-forward merges is regarded with quiet superstition, and even veteran hackers would rather stay away from rebasing “just to be safe”." "That’s why trying to understand Git in this way is wr…

You are the very first person I have run into in any forum to say that moving from SVN to Git had a smooth conceptual migration (at least among people who have ever done anything more complicated than "git commit -a" which I assume you have if you've been using git for a number of years).

It is hard to come up with two systems that implement source control and are more different.

Re: A Hacker’s Guide to Git

#112

Post by jammycakes »

timblair wrote: post #31
jammycakes wrote: post #28

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface. I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVC…

Yes, but if you choose to use a CLI for your explanation, you are alienating an even larger portion of your readerbase who can't use/don't want to use the command line. I'm thinking in particular of Windows developers, who have to put up with a CLI experience that borders on the unusable (or at the very least requires a lot of work to get it set up), and a culture that views it as the domain of poseurs and prima donnas into the bargain.

In any case, I'm quite sceptical of the claim that you can teach Git more effectively through the command line alone. Here's why: the two most important concepts to understand before you can properly grok DVCS are (a) that your source history is a key integral part of your workflow and not just a sideshow, and (b) how revisions, changesets and merges relate to each other through the DAG. GUI tools do this very effectively by putting your source history, complete with a graphical view of your revisions, right at the front of your workflow. By contrast, the command line requires you to type git log --graph, effectively relegating it to a sideshow like in the bad old days of Subversion.

I can't help getting the impression that learning DVCS through the command line risks you ending up with an understanding of the subject that is fundamentally flawed. You see this in virtually every Git versus Mercurial debate that focuses on which one is better at branching and merging. Most of the arguments that I've seen leave me with the impression that the people who are making them haven't a clue what they're talking about.

Re: A Hacker’s Guide to Git

#113

Post by seren »

SoftwareMaven wrote: post #104
seren wrote: post #39

Quick question for people using git daily : do you push the features branches to a central repo or you simpy merge with --no-ff on a common dev branch ? (There is no necessarily a right answer, but I'd like to know what is more usual)

Feature branches are pushed to remote, where code reviews can take place. Once the code is reviewed and approved, the submitter rebases it onto master. We run a batched continuous integration, so once it's on master, it is expected it could be pushed into production at any time (batched because somebody has to do the push manually, usually after merging the code).

Interesting because you'll get the cleanest history possible, however have you ever had an issue when the rebasing post code review would have had unintended effect (and not caught by a reviewer) ?

Re: A Hacker’s Guide to Git

#114

Post by edanm »

dahart wrote: post #105
edanm wrote: post #93

Earlier quoted context omitted.

"And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology." I heavily disagree with this. When I started heavy use of git branches, being able to actually visualize what a branch is (e.g. just a pointed, as the art…

I don't disagree with you. ;) Its a fair point that visualizing branches makes a big difference to people learning git. One reason that all git intro articles have these A->B->C diagrams. FYI, the git CLI can give you branch visuals, e.g., 'git log --graph'. I was honestly thinking beyond basic branching when I wrote the above, but its worth remembering that the basics matter, and I also wouldn't even disagree with s…

I agree with your larger points.

But I would point out that the "advanced" functionality of git that you're talking about is something 99.9% of people will never use. Hell, even branches is something that most people don't use.

Re: A Hacker’s Guide to Git

#116

Post by mbrock »

jammycakes wrote: post #112
timblair wrote: post #31

Earlier quoted context omitted.

That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface. I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVC…

Yes, but if you choose to use a CLI for your explanation, you are alienating an even larger portion of your readerbase who can't use/don't want to use the command line. I'm thinking in particular of Windows developers, who have to put up with a CLI experience that borders on the unusable (or at the very least requires a lot of work to get it set up), and a culture that views it as the domain of poseurs and prima donn…

But this isn't really a newbie's guide to using Git, as far as I can tell. There are probably other texts that are more suitable for that purpose. This text was pretty useful for me as a refresher-type thing to clarify the basic data types and inner workings of Git.

There are many, many people who have no problems with using the command line, and who in fact by default prefer it to GUI tools. The guide itself provides graphs and visual means of understanding, and explains how these representations relate to the CLI tools. Very helpful!

I don't really agree with your complaint, because it seems like you're just saying "I would prefer to read a different kind of article," which is fine, but it's not a criticism. The argument about "alienating an even larger portion of your reader base" seems spurious; the author can write to whatever target audience they want!

Re: A Hacker’s Guide to Git

#117

Post by Goladus »

lloeki wrote: post #86

Every tutorial I read falls in two camps: 1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add) 2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand. Both equally fail at making people get git. Having explained…

2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand.

While true, there's also a category of git users who are no longer really "newcomers" but still use git primarily as a subversion emulator and want to learn more.

Re: A Hacker’s Guide to Git

#118

Post by yxhuvud »

seren wrote: post #39

Quick question for people using git daily : do you push the features branches to a central repo or you simpy merge with --no-ff on a common dev branch ? (There is no necessarily a right answer, but I'd like to know what is more usual)

Neither. We rebase feature branches on top on master or release branch and enforce --only-ff. This assures a straight and clean history except for the cases when there are several release branches.

Re: A Hacker’s Guide to Git

#119

Post by jammycakes »

mbrock wrote: post #116
jammycakes wrote: post #112

Earlier quoted context omitted.

Yes, but if you choose to use a CLI for your explanation, you are alienating an even larger portion of your readerbase who can't use/don't want to use the command line. I'm thinking in particular of Windows developers, who have to put up with a CLI experience that borders on the unusable (or at the very least requires a lot of work to get it set up), and a culture that views it as the domain of poseurs and prima donn…

But this isn't really a newbie's guide to using Git, as far as I can tell. There are probably other texts that are more suitable for that purpose. This text was pretty useful for me as a refresher-type thing to clarify the basic data types and inner workings of Git. There are many, many people who have no problems with using the command line, and who in fact by default prefer it to GUI tools. The guide itself provide…

My problem isn't with this article specifically. In fact I'll probably find it quite useful myself: it's one of the clearest presentations of Git's internals that I've seen so far. I personally have no problem with the CLI tools either: I myself use PowerShell (with Posh-Git), Git Bash, vim, you name it, and for most things I actually prefer it.

But the fact of the matter is that the Git community is churning out articles such as this one left, right and centre, while ones at a more readily accessible level are being neglected, and therein lies the problem. While there are many, many people who do not have any problems with the command line tools, there are also many, many people who do -- especially in the Windows and .NET world. The fact that we have a glut of command-line focused low-level Git tutorials and a dearth of more readily accessible ones, combined with the common attitude in the Gitosphere of "if you're using GUI tools you're doing it wrong," paints a picture of Git to people such as these of an ecosystem that is elitist, arrogant and user-hostile.

It's nothing to do with the kind of article I'd like to read. It's everything to do with bad marketing.

Post reply on HN