Difference between revisions of "Talk:1597: Git"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
(Linux user friendliness (or lack thereof).)
Line 47: Line 47:
 
Comically missing the point. That is NOT what the comic is about, that is a poor excuse from a fanboy. --[[Special:Contributions/162.158.90.159|162.158.90.159]] 12:00, 1 November 2015 (UTC)
 
Comically missing the point. That is NOT what the comic is about, that is a poor excuse from a fanboy. --[[Special:Contributions/162.158.90.159|162.158.90.159]] 12:00, 1 November 2015 (UTC)
 
: I agree the verbose "explanation" misses the point. The reality is that git is a confusing mess from a user's point of view. It's a very nice and powerful design from a technical point of view yet one that will mostly confuse anyone who encounters it at first; most people are afraid of admitting it because they don't want to look dumb. There's beauty in a design that is user-friendly at its core, and git misses that mark. [[User:Ralfoide|Ralfoide]] ([[User talk:Ralfoide|talk]]) 17:38, 1 November 2015 (UTC)
 
: I agree the verbose "explanation" misses the point. The reality is that git is a confusing mess from a user's point of view. It's a very nice and powerful design from a technical point of view yet one that will mostly confuse anyone who encounters it at first; most people are afraid of admitting it because they don't want to look dumb. There's beauty in a design that is user-friendly at its core, and git misses that mark. [[User:Ralfoide|Ralfoide]] ([[User talk:Ralfoide|talk]]) 17:38, 1 November 2015 (UTC)
 +
: The same can be said of Linux.  It seems to be a common theme in Linus Torvalds' work.
  
 
In pretty much every team I've worked I found there ends up being one "git expert" that raises above the rest and people continuously go see that person with "I don't know how to do X", to which the expert will often reply with a magic unheard-of-before git command line that looks pretty much like perl line noise. [[User:Ralfoide|Ralfoide]] ([[User talk:Ralfoide|talk]]) 17:38, 1 November 2015 (UTC)
 
In pretty much every team I've worked I found there ends up being one "git expert" that raises above the rest and people continuously go see that person with "I don't know how to do X", to which the expert will often reply with a magic unheard-of-before git command line that looks pretty much like perl line noise. [[User:Ralfoide|Ralfoide]] ([[User talk:Ralfoide|talk]]) 17:38, 1 November 2015 (UTC)

Revision as of 23:51, 1 November 2015

If someone is interested, the best book I've read on it is Pro Git. The chapters 2 and 3 explain pretty well this mess of branching and merging. But it's true that it takes a bit of patience to go over it all. 108.162.228.35 08:47, 30 October 2015 (UTC)

Also take a look at GitFlow: A Successful Git Branching Model. Though Randall is correct there usually comes a time when it is easier to give up and "start again". 162.158.34.147 08:53, 30 October 2015 (UTC)

I never liked the name of this piece of software; in British English, the name "git" is mildly rude :-) https://en.wikipedia.org/wiki/Git_(slang) . Gearóid (talk) 09:20, 30 October 2015 (UTC)

According to word of god it was on purpose: https://en.wikipedia.org/wiki/Git_(software)#History 162.158.22.46 11:41, 30 October 2015 (UTC)

'Internally, Git works by saving the differences between various versions of the files, rather than creating a new copy each time the user "commits" the current version of the code.' - It is exactly the opposite. It stores whole files, or rather all committed pieces of data (blobs). See http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html 141.101.88.202 09:38, 30 October 2015 (UTC)TK

It is stored as diffs in pack file. Whole file (loose object) are packed automatically by default.
See https://schacon.github.io/gitbook/7_the_packfile.html and https://www.kernel.org/pub/software/scm/git/docs/git-pack-objects.html


162.158.177.59 10:15, 30 October 2015 (UTC)

Not sure what pack files are used for, but data is stored as is and named by the SHA-1 of its contents. See object model in the same reference. Walenc (talk) 16:02, 30 October 2015 (UTC)

I feel like this article should end with a quick guide to git commands. 108.162.216.27 (talk) (please sign your comments with ~~~~)

Well, I feel this article focuses on explaning git too much that it loses the point of the joke. We have Wikipedia to refer readers to ... The thing is, not just users who are unable to use git beyond a few basic commands, but also those who understand git often use some sort of "start over" method because an action looking perfectly legit got the repository into unusable state, where recovery is much more difficult than reapplying patches. For one of the most common, search for "detached head", for example - especially funny when git insists on falling into that state after checking out master which is in direct contradiction to what docs say when it happens. But I don't feel like rewriting that, sorry :-/ --kavol, 141.101.96.206 16:04, 30 October 2015 (UTC)

I feel you've all been nerd-sniped. 108.162.216.8 19:33, 30 October 2015 (UTC)Pat

The problem is not about the working copy and about the branching tree structure and some git internals that is quite confusing. This 4 years old reddit post can be used as a funny reference: https://www.reddit.com/r/programming/comments/embdf/git_complicated_of_course_not_commits_map_to/

http://tartley.com/?p=1267 "One of the things that tripped me up as a novice user was the way Git handles branches. Unlike more primitive version control systems, git repositories are not linear, they support branching, and are thus best visualised as trees, upon the nodes of which your current commit may add new leaf nodes. To visualise this, it’s simplest to think of the state of your repository as a point in a high-dimensional ‘code-space’, in which branches are represented as n-dimensional membranes, mapping the spatial loci of successive commits onto the projected manifold of each cloned repository." 108.162.210.212 (talk) (please sign your comments with ~~~~)

Should someone mention how git is by default used through a terminal - which is often more confusing than a GUI for most people - and that while there are graphical shells for git, some people refuse to use them because they're not fully-featured? 108.162.221.36 11:43, 30 October 2015 (UTC)

Shit. I use git for almost a year and I delete my repos more often than I'd like to admit. I'm going to read [1] and (hopefully) fix this once and for all. Kripmo (talk) 02:04, 31 October 2015 (UTC)

It was way easier than I thought. This is what I needed: git reset --hard <commit before fuck up>. Its alias will be fu. Kripmo (talk) 08:10, 31 October 2015 (UTC)

The really sad part of all this is that if you work in a multi-dev environment and anyone on the team is doing what Cueball suggests, it negates every other user's ability to use the main trunk properly. Ericm301 (talk) 02:26, 31 October 2015 (UTC)

Hasn't it got too extensive about git? I've never used git but quite understood the comedy. I just visited this page to know about git.txt and there's nothing about it but just long text that doesn't help whatsoever to understand the comic. 141.101.84.125 08:45, 31 October 2015 (UTC)

I agree completely! I've stripped out the overlong discussion of git's features. --Slashme (talk) 00:12, 1 November 2015 (UTC)

AFAIK, the git.txt is not the part of the Git itself. I just added it to explanation. 162.158.114.231 20:21, 31 October 2015 (UTC)

"This comic is a play on how git, a popular version control system, is misused by people who have a very poor understanding of its inner workings."

Comically missing the point. That is NOT what the comic is about, that is a poor excuse from a fanboy. --162.158.90.159 12:00, 1 November 2015 (UTC)

I agree the verbose "explanation" misses the point. The reality is that git is a confusing mess from a user's point of view. It's a very nice and powerful design from a technical point of view yet one that will mostly confuse anyone who encounters it at first; most people are afraid of admitting it because they don't want to look dumb. There's beauty in a design that is user-friendly at its core, and git misses that mark. Ralfoide (talk) 17:38, 1 November 2015 (UTC)
The same can be said of Linux. It seems to be a common theme in Linus Torvalds' work.

In pretty much every team I've worked I found there ends up being one "git expert" that raises above the rest and people continuously go see that person with "I don't know how to do X", to which the expert will often reply with a magic unheard-of-before git command line that looks pretty much like perl line noise. Ralfoide (talk) 17:38, 1 November 2015 (UTC)