Editing 1597: Git

{{comic
| number    = 1597
| date      = October 30, 2015
| title     = Git
| image     = git.png
| titletext = If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
}}

==Explanation==
{{incomplete|Title text - with he name of the friend not explained yet.}}

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. Git is a particularly apt target for such a joke due to its widespread use and significant discrepancy between perceived simplicity and complex underlying design. Tutorials for git tend to make extensive use of a cozy bootstrap layout and deal only with the most basic commands to get started, which can fool a novice to believe that git can be used appropriately without extensive studying. As this is rarely the case, a large group of git users (including Cueball) have a knowledge of git that extends to memorizing set of commands rather than a conceptual understanding of what those commands actually do. As this habit eventually will lead to a corrupt working tree, Cueball suggests that Ponytail keeps an alternative copy of her project outside git which, of course, defies every purpose of employing a version control system to begin with.

{{w|Git (software)|Git}} is a {{w|Version control|version control}} system often used to track changes to (usually) plain text files, such as computer code. Within a folder and its subfolders, the user can tell Git which files to keep track of changes for.  All the files that are being tracked in this manner make up a repository. Internally, Git works by saving entire snapshots of the files hashed by contents so that the same file content is only stored once, rather than creating a new copy each time the user "commits" the current version of the code.  This approach allows the user to switch between various versions of the code fairly quickly.  However, this can be confusing for new users because when changing between versions, Git effectively rewrites the files under its control to match that version - one file may have several different versions depending on which state Git has set it to, but only one of these versions is visible at any given moment.  The others are not hidden or moved, they do not exist until Git modifies the file to match that version.

In addition to allowing the user to track changes to the files over time using "commits" (versions of the files stored by the user), Git also allows the user to develop several versions of the files in parallel using "branches" (mentioned in the title text). This allows a programmer to, for example, keep a stable, functioning version of their code in one branch, while developing a new feature in a separate branch.  When the new feature is ready, Git provides tools to efficiently "merge" the changes from the development branch back into the main branch.  While powerful, there are also several pitfalls which can confuse users. For example, a file may have only been committed in one branch (so it is only visible in that branch), causing a user who has switched to a different branch to think that file was lost somehow.

Sharing a Git repository with other users is done through a remote repository, such as [https://github.com/ GitHub], [https://about.gitlab.com/ GitLab], or one set up by the user themselves.  This remote repository acts as a central location through which collaborators share their work. Changes do not automatically propagate between users; instead, once someone has changes they are ready to share, they must upload ("push" in Git terminology) their changes to the remote repository.  Other users can then download ("pull") those changes.  This allows each user complete control over when changes are applied to their version of the files.  Once one user has pushed his or her changes, all other users will need to merge those changes into their code before they can push.  Depending on how much the changes conflict, Git may be able to automatically combine both users' versions, or the user may need to do so manually.

In programming, Git is a very popular way to share source code of programs between computers and users and thus work on projects collaboratively. 

However, problems often arise when, for example, one attempts to upload code to a file someone else has already edited. 
Git has quite a few tricks to handle "merging" itself. 

One way of simplifying collaboration is to work in a different "branch" than other collaborators. All branches independently track their changes and can be viewed independently of each other. Only when you successfully "merge" (there we go again) individual branches together will you see other collaborators' "commits" in your working set of files.

But, due to the complex nature of Git (and its notoriously counter-intuitively named commands), a large portion of users are unable to use it beyond basic commands. They consider it usually much more efficient just to save the code to a different file, download a newer copy, and then re-apply their original changes to the new copy than to try and understand and use Git's own convoluted built-in commands to attempt to fix it properly.

Git was originally created by {{w|Linus Torvalds}}, the same person who originally created {{w|Linux}}.

==Transcript==
:[Cueball points to a computer on a desk while Ponytail and Hairy are standing further away behind an office chair.]
:Cueball: This is Git. It tracks collaborative work on projects through a beautiful distributed graph theory tree model.
:Ponytail: Cool. How do we use it?
:Cueball: No idea. Just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a fresh copy.

{{comic discussion}}

[[Category:Comics featuring Cueball]]
[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Hairy]]
[[Category:Programming]]
[[Category:Computers]]
[[Category:Internet]]
@@ Line 8: / Line 8: @@
 ==Explanation==
-===This is Git===
+{{incomplete|Title text - with he name of the friend not explained yet.}}
-{{w|Git (software)|Git}} is a version control system, used to manage the code in many millions of software projects. It is very powerful, and was amongst the first widely adopted tools to use a distributed version control model (the "beautiful {{w|graph theory}} {{w|Tree (graph theory)|tree model}}"), meaning that there is no single central repository of code. Instead, users share code back and forth to synchronise their repositories, and it is up to each project to define processes and procedures for managing the flow of changes into a stable software product.
-===How do we use it?===
+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. Git is a particularly apt target for such a joke due to its widespread use and significant discrepancy between perceived simplicity and complex underlying design. Tutorials for git tend to make extensive use of a cozy bootstrap layout and deal only with the most basic commands to get started, which can fool a novice to believe that git can be used appropriately without extensive studying. As this is rarely the case, a large group of git users (including Cueball) have a knowledge of git that extends to memorizing set of commands rather than a conceptual understanding of what those commands actually do. As this habit eventually will lead to a corrupt working tree, Cueball suggests that Ponytail keeps an alternative copy of her project outside git which, of course, defies every purpose of employing a version control system to begin with.
-Although very powerful, the command line of Git is notoriously difficult to master. Dozens of blog posts and websites (see [http://think-like-a-git.net/epic.html], [http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/]), and even books ([http://blog.anvard.org/conversational-git/chapter-01.html], [http://git-scm.com/book/en/v2]) have been written to help users navigate this complexity.
-The difficulty of using Git in common situations is contradicted by the apparent simplicity of its use in tutorial-style situations. Committing and sharing changes is fairly straightforward, for instance, but recovering from situations such as accidental commits, pushes or bad merges is difficult without a solid understanding of the rather large and complex conceptual model. For instance, three of the top five highest voted questions on Stack&nbsp;Overflow are questions about how to carry out relatively simple tasks: undoing the last commit, changing the last commit message, and deleting a remote branch.
+{{w|Git (software)|Git}} is a {{w|Version control|version control}} system often used to track changes to (usually) plain text files, such as computer code. Within a folder and its subfolders, the user can tell Git which files to keep track of changes for.  All the files that are being tracked in this manner make up a repository. Internally, Git works by saving entire snapshots of the files hashed by contents so that the same file content is only stored once, rather than creating a new copy each time the user "commits" the current version of the code.  This approach allows the user to switch between various versions of the code fairly quickly.  However, this can be confusing for new users because when changing between versions, Git effectively rewrites the files under its control to match that version - one file may have several different versions depending on which state Git has set it to, but only one of these versions is visible at any given moment.  The others are not hidden or moved, they do not exist until Git modifies the file to match that version.
-This comic thus explores the difference between the idealised view of Git's architecture, and its actual typical usage. Tutorials for Git tend to use simple systems in their examples, and only deal with the most basic commands to get started, which can create the misleading impression that Git can be used effectively without extensive study.
+In addition to allowing the user to track changes to the files over time using "commits" (versions of the files stored by the user), Git also allows the user to develop several versions of the files in parallel using "branches" (mentioned in the title text). This allows a programmer to, for example, keep a stable, functioning version of their code in one branch, while developing a new feature in a separate branch.  When the new feature is ready, Git provides tools to efficiently "merge" the changes from the development branch back into the main branch.  While powerful, there are also several pitfalls which can confuse users. For example, a file may have only been committed in one branch (so it is only visible in that branch), causing a user who has switched to a different branch to think that file was lost somehow.
-Due to this problem, compounded by the fact that Git's commands are named differently from similar commands in other version control systems, many users (including Cueball) are unable to use it beyond basic commands, and might try to avoid problems by saving their code outside Git, downloading a newer copy, and then re-applying their changes to the new copy instead of trying to understand and use the features that exist in Git to accomplish this task.
+Sharing a Git repository with other users is done through a remote repository, such as [https://github.com/ GitHub], [https://about.gitlab.com/ GitLab], or one set up by the user themselves.  This remote repository acts as a central location through which collaborators share their work. Changes do not automatically propagate between users; instead, once someone has changes they are ready to share, they must upload ("push" in Git terminology) their changes to the remote repository.  Other users can then download ("pull") those changes.  This allows each user complete control over when changes are applied to their version of the files.  Once one user has pushed his or her changes, all other users will need to merge those changes into their code before they can push.  Depending on how much the changes conflict, Git may be able to automatically combine both users' versions, or the user may need to do so manually.
-===Memorize these shell commands===
+In programming, Git is a very popular way to share source code of programs between computers and users and thus work on projects collaboratively.
-Cueball suggests "just memoriz[ing] these shell commands and type them to sync up". He is probably referring to a sequence of commands such as:
-    git pull
+However, problems often arise when, for example, one attempts to upload code to a file someone else has already edited.
-    # remote changes have now been received, so work on your file
+Git has quite a few tricks to handle "merging" itself.
-    git add file.txt
-    git commit -m "Added some text"
-    git push
-===If you get errors...===
+One way of simplifying collaboration is to work in a different "branch" than other collaborators. All branches independently track their changes and can be viewed independently of each other. Only when you successfully "merge" (there we go again) individual branches together will you see other collaborators' "commits" in your working set of files.
-As long as every contributor to the project follows these principles, this may suffice for a while. But many situations may cause "errors":
-* merge conflicts (two people editing the same part of the same file)
+But, due to the complex nature of Git (and its notoriously counter-intuitively named commands), a large portion of users are unable to use it beyond basic commands. They consider it usually much more efficient just to save the code to a different file, download a newer copy, and then re-apply their original changes to the new copy than to try and understand and use Git's own convoluted built-in commands to attempt to fix it properly.
-* unmerged changes (another person committed a change before you did, so you need to merge their changes first)
-* attempting to recover from a situation such as an accidental merge, and making the situation worse.
-In a situation such as a merge conflict, Git will show an error message such as:
+Git was originally created by {{w|Linus Torvalds}}, the same person who originally created {{w|Linux}}.
-    CONFLICT (modify/delete): README.md deleted in HEAD and modified in branch-b. Version branch-b of README.md left in tree.
-    # Automatic merge failed; fix conflicts and then commit the result.
-===Save your work elsewhere...===
-Although Git experts can of course deal with such situations, the remedy proposed by Cueball is "save your work elsewhere, delete the project, and download a fresh copy". That is, to copy the files out of their local repository's working directory, delete that whole structure, then clone the remote repository again (and, implicitly, copy the saved work back again):
- # Copy files elsewhere
- mkdir /tmp/myproject
- cp * /tmp/myproject
- cd ..
- # delete the project
- rm -rf myproject
- # Download a fresh copy
- git clone https://github.com/myorg/myproject
- cd myproject
- # Copy saved work
- cp /tmp/myproject/* .
-Abandoning the old project likely means losing some work, but may be faster and give a more predictable outcome than attempting to salvage the situation. Applying this method to a mere merge conflict issue may prolong the issue however, as the merge conflicts may still be present.
-===Title text===
-The title text suggests an alternative method for working around Git's complexities, which reflects common practice: knowing a "Git expert" who can help in any situation. Such experts are somewhat notorious for waxing lyrically about Git's strengths, so it may be necessary to win their favour by first letting them ramble enthusiastically about it. They will hopefully eventually give the exact commands needed. In practice, the question-and-answer site Stack&nbsp;Overflow is frequently used for this exact purpose.
-It may even be a reference to the infamous tweet "[https://twitter.com/agnoster/status/44636629423497217 Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space]" which has been [http://www.beyondjava.net/blog/git-explained-in-really-simple-words/ discussed here] but it is inconclusive whether a meaningful interpretation exists.
-Putting a telephone number of someone who "understands Git" into such a file is humorous because:
-*Software teams would more normally use electronic means of communication
-*Explaining Git over the phone to team members should not be necessary, as there is extensive help available online, and
-*In the situation where many team members would need phone support to avoid or fix basic Git problems, this would be extremely distracting to the person whose phone number was given in the file.
-=== TL;DR===
-In short: programmers use {{w|Version control|version control systems}} to track changes to code. Most of these version control systems are quite similar and easy to learn if you already know another one. Git is a version control system based on completely different principles, and most programmers find it difficult to wrap their heads around it (although Git also offers a large number of nontrivial benefits over standard version control systems, which is why it is used). Cueball is one of those programmers.
-== Trivia ==
-This comic was referenced in an earlier version of the page for ''what if?'' #153, where Randall, due to a problem with git, had at one time erroneously posted a draft of his ''[[what if? (blog)|what if?]]'' piece on peptides. As of December 17th, 2016 the page read:
-:;Whoops
-:This article is still in progress. An early draft was unintentionally posted here thanks to Randall's {{xkcd|1597|troubled approach to git}}, and it took a little bit to get everything sorted out and rolled back. Sorry for the mixup!
-On January 30, 2017, the page was updated with a completed article, ''{{what if|153|Hide the Atmosphere}}''.  As of September 23, 2019, the page no longer contains any reference to this comic or Randall's earlier mistake with Git (or anything related to Git, for that matter).
-The comic [[1296: Git Commit]] also features Git.
 ==Transcript==
 :[Cueball points to a computer on a desk while Ponytail and Hairy are standing further away behind an office chair.]
-:Cueball: This is git. It tracks collaborative work on projects through a beautiful distributed graph theory tree model.
+:Cueball: This is Git. It tracks collaborative work on projects through a beautiful distributed graph theory tree model.
 :Ponytail: Cool. How do we use it?
 :Cueball: No idea. Just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a fresh copy.
 {{comic discussion}}
 [[Category:Comics featuring Cueball]]
 [[Category:Comics featuring Ponytail]]
 [[Category:Comics featuring Hairy]]
+[[Category:Programming]]
 [[Category:Computers]]
-[[Category:Programming]]
+[[Category:Internet]]
-[[Category:Version Control]]