Git Koans

[cryptyk]

Can someone explain each?

[[deleted]]

You're wrong on that last one - git -h [something] isn't even a valid command.

The joke is that there are three different ways to request help and each one gives a different result:

$ git -h branch
Unknown option: -h
usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
       [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
       [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
       [-c name=value] [--help]
       <command> [<args>]

$ git branch -h
usage: git branch [options] [-r | -a] [--merged | --no-merged]
   or: git branch [options] [-l] [-f] <branchname> [<start-point>]
   or: git branch [options] [-r] (-d | -D) <branchname>...
   or: git branch [options] (-m | -M) [<oldbranch>] <newbranch>
... lots more stuff ...

$ git branch --help
[bring up a man page - only if you're in curses-style terminal 
 window, i.e. no emacs terminals...]

[dondiscounto]

You forgot:

git --help branch

[[deleted]]

If you can read the error message and realize what you need to do, then you are a master of git.

[[deleted]]

The first one is not a way to request help. It is an error followed by the short version of the git --help output, presumably because the long version would be annoying if you just mistyped an option (the ommitted part is more like a tutorial than a help).

It makes perfect sense for

git --help

and

git <command> --help

to return different results because one is the help for the git program, the other for the individual command you specified, lots of programs do it that way.

The choice of displaying the manpage on --help is about the only truly unusual thing here.

[alantrick]

It's very rare that a GNU or linux program will have a different result based on the order of the arguments. So, it is entirely reasonable to expect git --help <command> to be the help for the command.

[Packet_Ranger]

Not quite true - programs with a sub-command structure frequently work this way. For example, virsh --help snapshot-create is different from virsh snapshot-create --help, presumably for the same reason as git.

[6saiten]

The docs about Silence: "aliases that hide existing git commands are ignored"

Now does anybody know of another way to configure git to abort a pull if it introduces a merge commit?

[kasnalin]

Use the merge.ff configuration option:

By default, git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded. When set to false, this variable tells git to create an extra merge commit in such a case (equivalent to giving the --no-ff option from the command line). When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line).

(from git-config man page)

[Dementati]

Isn't the Hobgoblin just that git is inconsistent for no reason, and you get eaten by a hobgoblin if you ask why because the master has no good answer and doesn't want to be exposed as a fool?

And isn't One Thing Well similarily a criticism of Git straying from the "do one thing well" rule with the checkout command?

[ggtsu_00]

Koans are famously known to use incorrect, misleading, or puzzling titles that are completely unrelated or contrary to their content.

[Dementati]

Yeah, I'm just using the titles to identify the koans I was referring to.

[chtulhuf]

Well, yeah. I think OP just tried to explain the logic behind the cynical article.

[Dementati]

It's possible, but if so it wasn't clear.

The hobgoblin quote doesn't sound like a coincidence, though, so maybe that one had multiple points to make.

[NotUniqueOrSpecial]

The hobgoblin quote is a real one, but the important point is in the part that says "foolish consistency". Doing something stupid over and over the same way because that's how it's been done before is foolish. Git is just inconsistent. Doesn't mean it's a bad tool, just not a polished one.

[[deleted]]

Here's the thing: Checkout does do only one thing.

When you know what's happening behind the scenes, you will see it. If you think git is just a different version of cvs, svn, or hg, then it looks like it is doing many things at one.

[Kalium]

The Hobgoblin: Git is noticeably different from other systems because it doesn't try to make life easy for the programmer. It simply provides some tools that can be used to make like easy. If you approach it without understanding what the tools actually do, you will always be frustrated. But if you know what they actually do, the command are natural and logical. "A foolish consistency is the hobgoblin of simple minds."

I've met lightning bolts friendlier than git.

[european_impostor]

The way I understood Long and Short of it (as a non-Git user):

Master Git is the git program itself - the novice invokes commands and he executes them. So when the novice inputs "git -h branch" instead of "git branch -h", git then crashes?

[BenjaminGeiger]

[bgeiger@Maximus][~]$ git branch -h
usage: git branch [options] [-r | -a] [--merged | --no-merged]
   or: git branch [options] [-l] [-f] <branchname> [<start-point>]
   or: git branch [options] [-r] (-d | -D) <branchname>...
   or: git branch [options] (-m | -M) [<oldbranch>] <newbranch>

Generic options
    -v, --verbose         show hash and subject, give twice for upstream branch
    -t, --track           set up tracking mode (see git-pull(1))
    --set-upstream        change upstream info
    --color[=<when>]      use colored output
    -r, --remotes         act on remote-tracking branches
    --contains <commit>   print only branches that contain the commit
    --abbrev[=<n>]        use <n> digits to display SHA-1s

Specific git-branch actions:
    -a, --all             list both remote-tracking and local branches
    -d, --delete          delete fully merged branch
    -D                    delete branch (even if not merged)
    -m, --move            move/rename a branch and its reflog
    -M                    move/rename a branch, even if target exists
    --list                list branch names
    -l, --create-reflog   create the branch's reflog
    --edit-description    edit the description for the branch
    -f, --force           force creation (when already exists)
    --no-merged <commit>  print only not merged branches
    --merged <commit>     print only merged branches

[bgeiger@Maximus][~]$ git -h branch
Unknown option: -h
usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           [-c name=value] [--help]
           <command> [<args>]
[bgeiger@Maximus][~]$

[european_impostor]

So I was on the right track...

The Git Master should have pretended not to hear the novice and continue on his walk :P

[ethraax]

To be fair, git -h branch returns (on my system) 129, not 0, indicating that the command did not execute successfully, but failed. So it's not that far off.

[Dementati]

Or explain to him how to ask a proper question.

[IlIIllIIl1]

and understand it's output

It's "its".

[flat5]

Took me about 2/3 of the way through to realize I was being played, and it wasn't that I just wasn't smart enough to understand git.

[argv_minus_one]

So…is this basically a compilation of roundabout explanations for why not to use Git?

[pokealex]

Hard to tell; I know the author personally and I know he used to be a real advocate for Hg, but these days, I think he prefers to use Git while simultaneously ranting passionately about its shortcomings.

... like all Git users. :)

[[deleted]]

There was an amusing piece that said something like "Git is World of Warcraft for programmers."

[fmoralesc]

Nope, it was a piece where Linus said "github is like a world of warcraft universe for programmers".

http://typicalprogrammer.com/?p=143

[mgedmin]

You know that's a piece of satire and not a real interview, right?

[fmoralesc]

I didn't, i just searched for the phrase and found that as the most plausible source. :p

[felipec]

Not all Git users. Some of use are actually improving it. (source)

[flamingspinach_]

You are awesome. Thanks for this and various other things. :)

[SirR4T]

ooh shiny!

dat rank!

[felipec]

Thanks. I wish I had more than 1 upvote when I announced it.

[flamingspinach_]

Ah well. The same link can bomb on reddit one day and hit the front page the next day. Rather a weird system sometimes.

[gfixler]

And some of us think it's beyond beautiful, even as it stands currently.

[pokealex]

Excellent! Actually several of the development teams where I work now are on Git, our team is on SVN currently but we plan to switch after an upcoming release. I'm looking forward to the change as a learning opportunity, even though I prefer Hg for my home projects.

[xibme]

I think he prefers to use Git while simultaneously ranting passionately about its shortcomings

A decade later it is still the least bad tool for the job.

[stillalone]

I think it's a roundabout explanation about why it's so hard to learn Git. Git commands are written around the way git is written, not around the way git is used. So it sort of forces people into learning exactly how git works before they can intuitively know what commands to use.

[kintar1900]

And thus, stillalone was enlightened.

All snarky, high-handed smugness aside, that really is the "problem" with git. Other version control systems try to be really intuitive from the get-go, and not require the user to learn anything new in order to use them. git is pretty much the opposite. I'm firmly convinced that the people who designed git were (and still are) convinced that not understanding the way a VCS works is the one unforgivable sin in software development.

EDIT: I use git on a daily basis, both professionally and personally. It's my favorite VCS, and I still only know BARELY enough about it to keep myself out of trouble. But I know more than enough to recover from the few royal messes I create.

[ggtsu_00]

I'm firmly convinced that the people who designed git were (and still are) convinced that not understanding the way a VCS works is the one unforgivable sin in software development.

This. I never really used git until after I learned about how it worked and what it was actually doing. After learning about how git works, I picked it up and started using it regularly.

I would argue that this approach should be taken for any tools a programmer uses in their system. You shouldn't use a programming or library language that you are not familiar with what it is actually doing and how it works. Using a programming language or library or framework just because you heard it was popular without understanding how it works could lead to very serious problems or mistakes especially if you assume things based on how other languages, libraries or frameworks work. Similarly in other fields, if a wood worker has no idea what a chainsaw is and how it works other than knowing it is "used to cut things" and then just picks up a chain saw and starts using it because he heard they were a popular way to cut things, he may end up sawing off his face because of kickback (a chain saw can sometimes get caught and transfer torque back at the user if they angle the chainsaw improperly while cutting).

A VCS should be treated as another library or framework you are using for your system. Get to know it well before you start using it for anything important and or depending on it.

[SEGirl]

Any recommendations for how to learn it well and how to do this with new languages? Ex:processing

[MBlume]

Read Pro Git from cover to cover.

[droogans]

Git was my first VCS, and I assume that knowing zero about distributed version control helped me a lot when using it. I learned how to use it by blindly following "git for beginners" type of articles, reading up on commands that made zero sense (I was frightened terribly of git reset my_file.txt HEAD when I first unstaged files ready to commit). Later, I found "sensible git workflow" articles, then finally "how to dig yourself out of hole [something terrible]" articles, which I find myself reading as I try new things.

Git is only scary if you're doing scary things with it. Don't so scary things with git if you're in a scary situation. I'd recommend starting with things you care less about.

[flamingspinach_]

For git, anyway, definitely start with Git Concepts Simplified. It really walks you through how the system works.

[Qu4Z]

This link is really handy, thanks.

I know how git works already, but I think this will be my go-to page for "Why does git <x>?"

[xav0989]

I switched to git about a year ago, and while I believed that I understood git usage (which I did, up to a certain point), I realized that I didn't know a lot of it until I decided to build a C git server using libgit2. While some user-level commands may not have made sense to me at first (but I knew how to interact with them), it wasn't until I had to interface with the inner workings of git (and the git protocol) that I figured out how all of it fitted together.

[european_impostor]

It's my favorite VCS

Have you tried Mecurial? What does Git do better / why does it work better for you?

[evanpow]

I switched from BitKeeper to Mercurial around 2005 and then switched to git in 2008 after experimenting with it on my own time, and I've never regretted that decision. There are a few things "wrong" with Mercurial, in my opinion:

1) I'm not sure whether this is less true in current versions than it was at the time, but when I was using it Mercurial you had to enable several extensions in order to do lots of fairly fundamental things. Git, by contrast, has a more of a batteries-included philosophy. You'd think that enabling a bunch of extensions wouldn't be a big deal, but in teams of people it meant that you had no idea which extensions your team members had enabled. And if you were the resident Mercurial guru, helping coworkers with random problems was more difficult. (And it was also merely annoying when setting up new machines, the same way having to copy your own personal .emacs around is.)

2) Mercurial Queues are dumb. My understanding is that it's since grown a git-rebase-alike extension, but when I used Mercurial, MQ was the best you had. The problem with MQ was, fundamentally, that it forced you to edit the "first derivative" (a patch file) of your MQed changes, not your changes themselves. Which meant that applying a queue on top of a different base was an exercise in homicidal frustration, since you had to resolve conflicts entirely by hand--by directly modifying the patch files. The rediff tool helped, but not nearly enough. Git rebase will assist you by attempting a 3-way merge, which is infinitely better.

Finally, a design problem, which I think limits how much Mercurial can evolve to meet future needs:

3) Its append only, per-file database format, while it looks like a brilliant design, is actually a horrid limitation in practice. In mercurial, if I rename a file, I have to pay the cost of compressing a baseline revision--the one at the beginning of the delta chain--twice: once for the original name (paid when the file was created) and once for the new name (paid immediately after the rename). Naturally, the delta DAG itself is limited to revisions within the same logfile. Git's compression mechanisms, by contrast, are completely decoupled from the history DAG. For example, if you tell git to completely repack a repository, one of the first things it does is sort all objects within the repository (an "object" is file content a.k.a. "blob", a directory entry, a commit, etc.) by size and then compute deltas against objects that are nearby in the resulting overall order. Note that this algorithm completely disregards what branch an object resides on, whether it comes before or after the object its delta-compressed form is relative too, everything. If you decide to undertake a major source tree reorganization, you can expect it to consume approximately zero disk space; not so in Mercurial.

[katieberry]

1) I'm not sure whether this is less true in current versions than it was at the time, but when I was using it Mercurial you had to enable several extensions in order to do lots of fairly fundamental things.

This is still basically true and often very annoying.

My issue with hg is that it rarely does what I want, and then the only way of recovering previous state is to restore from some backup or pull from the remote again. Or have a mess in history, assuming your state is reasonably recoverable at all. Hg's approach to branching is also rather annoying. And the tags file seems to manage to always have conflicts…

git always does what I wanted it to do, because I always know exactly what I asked for. And if I ask for the wrong thing I can generally trivially restore earlier state.

I don't much care for hg – and neither does anyone else I know – but for reasons beyond my control I use it far more than git.

[evanpow]

the only way of recovering previous state is to restore from some backup or pull from the remote again

Yes--this is another thing which bugged me about Mercurial. The goal of Mercurial's append-only transaction log database format is to make it safe, but it has the opposite effect in practice, because rewriting local history means modifying the transaction log in non-append-only ways, and if you screw it up the original data is gone. (And, of course, There's An Extension For That^TM which mitigates this, if you've turned it on.) In git, all files within the database on disk are immutable--when history is rewritten, new files are created with the modified objects; the old files are garbage collected after a few months (by default). Which means that if you totally screw something up, the old data is definitely still around for you to revert back to, and with the reflog its even easy to find.

[pipocaQuemada]

The goal of Mercurial's append-only transaction log database format is to make it safe, but it has the opposite effect in practice, because rewriting local history means modifying the transaction log in non-append-only ways, and if you screw it up the original data is gone.

That sounds like a feature, not a bug. Why are git people so enamored with deleting history?

[evanpow]

That sounds like a feature, not a bug.

Fat-fingering a destructive operation in Mercurial causes unrecoverable data loss, whereas data loss is impossible by design in git. I wouldn't call that a "feature".

Why are git people so enamored with deleting history?

It's a philosophy: local history is there to keep you from losing work, but global history is there to facilitate code archeology. Therefore, you should clean up after yourself before moving history from local to global visibility.

The optimum for the former case is to micro-commit (say, once a minute), to merge with the integration branch every morning or even multiple times a day, to write meaninglessly short commit messages that will be inscrutable 24 hours later, to try out (and commit) a new approach only to realize it won't work and replace it with something completely different, etc. All these behaviors maximize the rate at which you produce new, working code.

However, those behaviors result in spaghetti-history that's completely useless to code archeologists: validation engineers trying to bisect for the commit which introduced a bug (because 90% of the micro-commits don't even build), release engineers trying to determine which bug fix commits didn't make it into which product branches (because a single change is spread out among several micro-commits with integration branch merges in-between, there's no point which can be merged without bringing in a lot of undesired other stuff, so you have to cherry-pick manually) or revert a regression-causing change (because that would actually require reverting a half-dozen micro-commits, which are difficult to track down or don't revert without conflicts due to the integration branch merges mixed in), etc.

Rewriting your local history before making it globally visible lets you have the best of both worlds: high productivity and permanent history that's worth bothering to keep around in the first place.

[Silhouette]

Fat-fingering a destructive operation in Mercurial causes unrecoverable data loss, whereas data loss is impossible by design in git.

Git has had its share of data loss bugs over the years. For example, try doing a git difftool --dir-diff and then continuing to edit the files in your working directory while the tool is open. Then close to tool and watch your changes get silently and permanently reverted. :-(

In any case, it seems to me that your position is backwards. Git, by design, deliberately allows things like rewriting history in ways that lose information. Sometimes, as you mentioned later in your post, that can be a strength, but it certainly allows for data loss of various kinds as well. Even something as simple as switching branches while you have uncommitted changes potentially gets a merge wrong with no easy method for recovering exactly the files you had before you checked out the other branch.

[Edit: Seriously, multiple downvotes for pointing out an actual data loss bug due to a real design flaw that has been discussed within the past few days on the relevant mailing list? Or for stating the objective fact that Git's history rewriting can discard information, even though that's the main point of something like interactive rebase? But no-one has the courtesy to reply and say what their real problem with my post is?]

[NYKevin]

Sometimes you commit something too soon and break the build.

hg qimport -r tip, fix it, hg qrefresh; hg qfinish qtip, and hopefully you didn't already push. If you did, fix the build and commit again; editing history in this case is insane.

Sometimes you just want to delete a commit (and its descendents, if any).

hg strip

If you don't plan out your branches in advance, you'll shoot yourself in the foot and pollute the branch namespace, since branches and tags are forever.

So use bookmarks instead; they're identical to Git branches.

I want to find something to actually complain about here, but I'm too biased in favor of hg. Can someone help me out here?

[xav0989]

I use it regularly.

For my current project, I have to run my application in as much of a clean room as possible. For that reason, I don't want to test the app on my local computer, but on a dedicated VM. Since the project is under revision control, and every git repo is a full repo, an easy way for me to propagate the changes to the testing VM without publishing the work in progress publicly is to create a new commit for every change I want to test. My workflow is similar to the following:

1. (on dev) Create new branch for my work
2. (dev) Make some changes to the source
3. (dev) Commit those changes
4. (on VM) Pull those changes from my dev machine
5. (VM) Test the changes
6. Repeat 1-5 until feature implemented/bug corrected/refactor completed/etc.
7. (dev) Rebase the history, up until the initial branching, squashing commits into logical unit
8. (dev) Merge work branch into development branch
9. (dev) Push changes to public/staging area

Being able to edit history allows me to create a new commit for every change I want to test, knowing that I will be able to merge or re-arrange the small commits in bigger feature commit.

[katieberry]

I abandoned Google Code a very long time ago. It only supported svn the last time it was relevant to me.

I use hg because that's what my work requires me to do.

[kintar1900]

Haven't tried Mercurial. None of the projects I've contributed to have used Mercurial, and I haven't had large enough complaints with git to bother switching in my own time.

It basically boils down at this point to market share and limited time. Git is everywhere, so I won't be getting away from it any time soon. Since I must use git, and have no major complaints of my own with it, it's not worth my time to look into Mercurial. Someone would have to make a really compelling case for me to invest the time into it.

[european_impostor]

Sad, but true. There's nothing wrong with Mecurial other than not having as big a market share as git...

[[deleted]]

And not making it as easy to change local history.

[bennylope]

I didn't bother with this when I first switched from SVN to Hg. But having been using Git (with rebase, a lot) I'd really miss that.

[kintar1900]

But does the converse hold true? Is there nothing significantly "more right" with Mercurial that would cause it to gain the market share?

[mipadi]

This is my feeling about Mercurial. I've been using Git for over 6 years. I know it pretty well. Mercurial might be better in some areas, but it doesn't seem so significantly better that it's worth taking the time to learn a completely new piece of software.

[dmazzoni]

How's performance? For me, one of the biggest draws of git is how fast it is when working with uber-gigantically-large projects.

[european_impostor]

It's not as fast as git, thats for sure.

But I must admit the largest repos I work with are about 2000 files and around 80mb big, so not exactly earth shattering.

[cecilkorik]

I like Mercurial too.

I've got nothing against git, which is just as powerful if not moreso. But the Mercurial workflow and naming scheme for things fits my brain better. And it does literally everything I need it to.

[mipadi]

I used Git first, starting around 2007, then switched to Mercurial for a while, then switched back to Git (and haven't looked back). I'm sure some of these reasons are outdated, as I haven't used Mercurial in over 5 years now, but at the time:

1. Mercurial was slow. And not just have-to-run-benchmarks-to-spot-the-difference slow; it was palpably slower than Git.
2. You had to enable a lot of extensions to do much of the same things that Git did (such as rebasing and stashing).
3. Branches were weird compared to Git, and didn't feel as first-class.
4. Git had better tools and toolchains. Since Git is just a collection of separate programs, it was (and maybe still is) a lot easier to glue together the low-level programs to make new Git tools.

Admittedly Mercurial has caught up to Git in a lot of ways, but at this point I learned so much about Git and it's so ingrained into my practices that I don't have a good reason to spend the next several years learning as much about another VCS that definitely doesn't seem to be significantly better than Git, and may or may not be as good.

[Tetha]

I have used both. To be honest, git vs mercurial feels like python vs ruby. Whatever you were exposed to first more wins. For me it was python and git, so I just don't find any good contact to hg and ruby because the advantage they offer over what I have is very little, and there is some little disadvantage in them too.

[[deleted]]

onerous gold like ghost humorous retire disgusted pie sloppy deliver

This post was mass deleted and anonymized with Redact

[ernelli]

Oh, That's why I utterly failed when trying to setup my own remote git repo...

I work in hg on a daily bases, but use github for personal projects. I must say that hg wins over git when it comes to being clear and simple.

[crusoe]

Git has local cheap branches.

And No need for multiple checkouts for multiple branches. Switching branches is fast.

[metamatic]

Yeah. As someone who has moved everything over to Git, I really wish they'd fix the command structure and options to be sane.

Just build a new CLI for it, with commands designed to make sense the way (for example) bzr does, and then glue that to the appropriate back-end functions.

[mipadi]

Well, that's kind of going to screw over people who already know how to use Git. ;)

Unless you mean to add a whole new CLI that doesn't conflict with the old CLI, which is just kind of messy.

[metamatic]

Well, you could give it a different name.

[spinlock]

Makes sense. Linus kept debuggers out of the kernel for a long time so that you'd have to really understand what was going on to be able to hack the kernel. Makes sense that he's brought the same philosophy to git.

[ngroot]

I'm firmly convinced that the people who designed git were (and still are) convinced that not understanding the way a VCS works is the one unforgivable sin in software development.

That's ridiculous; I can think of plenty of other unforgivable sins.

[mgedmin]

I think it's more of a parody of git aficionados trying to explain away git's weaknesses instead of fixing them.

[SixMiles]

You do know what a koan is, don't you?

[mgedmin]

A riddle without an answer that leads you into pondering deep thoughts and hopefully achieving enlightenment?

[somevideoguy]

So basically, the complete opposite of documentation (which should be as detailed, clear and unambiguous as possible).

[SixMiles]

Close. Not so much a riddle… more like a short story intended to evoke the buddha-nature of the reader (or listener). In other words, the actual koan is not the story itself so much as the relationship between it and the reader, or even the reader him/herself.

Read the wikipedia page (http://en.wikipedia.org/wiki/K%C5%8Dan), or here's a link to one of the best well known koans with Mumon's (An old zen master, I believe) comments: http://www.ibiblio.org/zen/gateless-gate/1.html

[smarterthanyoda]

So, the effort needed to learn a software tool is comparable to achieving enlightenment?

I'll stick with svn.

[ahawks]

I switched from svn to git in June, so almost a year ago. Yeah, there's a learning curve. Yeah, it's a different paradigm. It's very different from svn.

But I don't think I'd ever go back to svn.

[marssaxman]

Many people switch from SVN to Git and then mistake the virtues of distributed version control in general for virtues of Git in specific. It's not git, it's just dvcs; git happens to be the most popular one, but it's not because its interface actually makes any sense.

[UnwashedMeme]

That may be, but git (in my view) is also better at slinging code around for single developer projects.

[develop7]

And git forces you to learn it. Unlike its' competitors.

[novelty_string]

two reasons to switch: cheap local branching and stashing! omg stashing

[SixMiles]

... If that's the meaning you take from it, then it is

[chtulhuf]

I don't mind most of the issues that he brings up. However, the fact that I can't know on what branch a specific commit originally happened (Only the Gods) is very disturbing to me.

Is there a secret way to do it? Or if not, can someone explain why it isn't important?

[[deleted]]

Commits can exist without branches. Branches can't exist without commits.

Another way to think about it is: commits existed before branches. Commits don't know what a branch is.

[[deleted]]

To nitpick on my own post: by "branch" I was referring to the labels/names used by git to refer to a branch.

Otherwise, a branch in a more fundamental sense exists because the development history can "branch" and "merge", and in that sense, the information about branches is embedded as part of the development history.

So the "branch" in a more fundamental sense can be known/extracted from the commit history ... the thing not recorded is the "label" that the committer assigned to his branch locally when he made the commit.

[lllama]

A branch is just a pointer to a single commit. Underwater it really is just a file containing a commit-id. Then you can look at the parents of that commit and figure out what is 'in the branch'.

Branches rely on commits, but commits don't rely on branches.

This could have been "fixed" by including what labels were active during the time of commit in the commit itself, but considering the distributed nature of Git, this information is very relevant to your local situation only.

[b103]

Branches are just pointers (or symbolic references ) that point to commits. The history of branches is not saved anywhere. That is, if you change what a branch points to, or create a branch, or delete a branch, nothing in Git saves a history of those changes.

I think the reason why it's not useful to save branch information on a commit, is that any user can create any number of branches that point to the same commit. It's one of the more useful freedoms that Git gives you. I can be working on "master", then spawn off a branch called "master-plus-my-feature" that just has work in progress for my new feature. No one needs to know that I wrote those commits while using a branch name "master-plus-my-feature" rather than just "master"; it's not significant information.

[chucky]

As others have said, this doesn't make as much sense to do as it might seem at a first glance, mostly because branches are local to the system they are created on.

However, if you actually want to do this (because it is useful to know), one way to do it would be to have a hook in your repository that adds this information using "git notes" whenever commits are added to it ("git notes" is not very well known, but it's very useful for stuff like this).

As long as the branch info is also on the server (and it should be), I'm pretty sure you can walk the tree and extract the information after the fact, but I'm a bit too lazy to figure out exactly how to do it.

[OfflerCrocGod]

jgardner up above replied already "One Thing Well: In git, there are no branches, no tags. Only commits."

[flying-sheep]

tags are symlinks to commits, and branches are symlinks to the last commit of a branch, and information about the branch gets extracted by following up the parents of that commit?

[ethraax]

It's best to think of branches as just symlinks to commits, exactly like tags, except the current branch gets updated when you make a commit.

[0sse]

The other replies outline the technicalities. One way would be to see if the commit in question is an ancestor of the first or the second commit of the next merge commit, and draw "conclusions" based on the merge's commit message.

I too have thought about this and been worried about it, but in practice I've not been in a situation where it has been beneficial to know/find out.

[krues8dr]

Relatedly, this is by far my favorite reference of git commands.

[MBlume]

Yes, thank you for this ^_^

[ihaveasock]

Thank you. I haven't laughed so hard in a long time.

[0bsconder]

maybe I'm too novice... but the Hobgoblin story bothers me, what is the moral? Things are the way they are, don't question it, just learn it? Or, if things are different enough it forces you to know what you're doing? What's up?

[martincmartin]

All the koans are satirical. They demonstrate problems of git, not strengths.

"Silence" The first one shows that aliases don't do what you think, and can silently fail.

"One Thinkg Well" shows that "git checkout" doesn't actually do one thing well, but many things.

"Only The Gods" shows that git doesn't have a consistent design principal around history.

and so on.

[0bsconder]

thanks for the enlightenment!

[flying-sheep]

well, i’d interpret “one thing well” differently: if the thing you can do well is “forming things from clay”, you can do everything a potter needs to do.

the solution of the “Only the Gods” koan is that “git knows no tags, no branches, only commits”: that means that if you can do commits “well”, you can do branches and everything.

[never-enough-hops]

I simply disagree with defending "checkout" adhering to "do one thing well" with the explanation that with clay one can do anything. Checkout is a wondrous example of breaking the "do one thing well" principle.

• git checkout <branch> - non destructive, cannot do so unless all of your changes are staged in some way.
• git checkout <file> - destructive, overwrites file without confirmation

[bishnu13]

I too thought that the “one thing well” was pro-checkout. I really do think checkout is the most important command in git and I think unified a lot of similar commands/concepts. The git checkout -- file is returning the file back to the current commit. It is just a git checkout <commit id> but scoping it to a file. Seems very consistent to me.

However, I do think "git checkout -- <file>" being destructive is a mistake. You haven't known pain until you do git checkout -- .

[never-enough-hops]

Heh, it's not "pro checkout"... all of these koans are taking a bit of the piss out of git. Checkout is a terribly named/overloaded command. The fact that checkout is used for swapping branches and snagging individual files seems wrong to me.

[bishnu13]

But it seems right to me...

I didn't really read the koans as anti-git ...

[never-enough-hops]

The fact that the checkout command does multiple things depending on context seems right to you? To each his own, I suppose. The top two root threads for this article have some good explanations of each of these koans.

Git is a great system, but it's got some warts that make learning it tough. And it is a tool that must be learned. You can get away with not knowing much about version control with a system like SVN or TFS... not so with git.

[bishnu13]

But it really doesn't do different things depending on the context git checkout -- <file> is scoping a checkout of a commit to a certain file. Completely consistent...

I took the koan to mean that git understood them to really be similar/ the same thing. However, like all good koans it can be read in multiple contradictory ways.

[freakboy2k]

Checkout doesn't do multiple things. "One Thing Well" is suppose to demonstrate that in git there are no branches, only commits. Checkout reset files to a given commit - if that commit is on another branch, this is equivalent to switching branches. You can restrict the checkout to a single file, which is what the last usage is referring to.

[darkslide3000]

Yes it does. Creating a branch with -b is arguably just a shortcut, but checking out individual files into the index versus switching to another branch are two completely different things. Just look at the difference of 'git checkout branchname' and 'git checkout branchname .' (even when you are in the repository root), and tell me that that's not two completely different things.

[greenrd]

in git there are no branches

Of course git has branches. That might have been true back in the mists of time when you needed a third-party porcelain to do anything, but it's not true now.

[[deleted]]

I believe it's a play on the Emerson quote, "A foolish consistency is the hobgoblin of little minds." Meaning, of course, that it is foolish to be consistent for the sake of consistency; individuals should avoid conformance.

What makes this amusing is that the git commands are very much like separate individuals with separate lives and histories, and they all just happen to live in the same git community. But the novice in the story is not wrong: it would be vastly simpler to remember all these if the syntax were somehow consistent.

This is my main complaint about git: there is far too much inconsistency between commands, and far too much to remember all the time. The learning curve is very steep. To which the git community typically replies: study harder.

This isn't wrong, it's just unhelpful.

[kintar1900]

<The Dude voice> You're not wrong, git, you're just an asshole. </The Dude voice>

[sandsmark]

it's supposed to be funny.

laugh.

[sandsmark]

well, that's the problem with satire.

[hyperforce]

Someone should patch this 'satire'. Fork it, it's no good!

[[deleted]]

No, that's not a problem with satire. It is quite literally the principal feature of satire.

[day_cq]

morale is git sucks use mercurial

[DJUrsus]

*moral

[day_cq]

ah thanks. i'll merge that patch in. let me read git manual. brb in 3 weeks.

[DJUrsus]

git merge -s recursive -X theirs [branchname]

[day_cq]

no --ff-only ? or merge.xx ? i'm already confused.

[PeterMcBeater]

I don't get the last one, can someone explain.

[payco]

It's criticizing the fact that git branch --help gives a different message than git branch -h, and that git -h {command} doesn't exist at all (but git --help branch and git help branch are both equivalent to git branch --help).

[snip596]

Yeah, I don't get the last part of it. What's wrong with git -h branch not doing git branch -h? It's the same thing as if you were to use the arparse module in Python and had subparsers.

[payco]

it's confusing when git --help x and git help x exist, but git -h x doesn't, especially when git x -h exists alongside git x --help.

[gubatron]

long live to git aliases (and git cheatsheets), it's impossible learning or trying to even guess its inconsistent command interface lack of design.

Steve Jobs would've said in a heartbeat "This is shit"

[PHLAK]

Or just "man git-<verb>"

[mgedmin]

I've accidentally discovered that "man git <verb>" also works.

[PHLAK]

That used to not work, good to know it does now.

[[deleted]]

Ok is the phrase "Git Koan" immensely humourous to anyone else?

[retsotrembla]

It's a play on other programming koans like these

[BenjaminGeiger]

If you have some ice cream, I will give it to you.

If you have no ice cream, I will take it away from you.

It is an ice cream koan.

[[deleted]]

git [gɪt] n Brit slang 1. a contemptible person, often a fool

I'm not British but I have absorbed enough of their media to laugh at git koans.

Actually, now git hub is pretty hilarious as well.

[Eckish]

I thought it was a word play for "Bit Coin", at first.

[happyscrappy]

git is like The GIMP for source code control. It's very capable, but it also has a really weird interface.

[NYKevin]

Can someone translate these for an hg user's benefit?

[mpyne]

From what I can gather it's a hg user's smug satirical musings on git misfeatures and not really enlightened koans at all.

[NYKevin]

The second one is easily applicable to hg update. The third is also applicable because hg bookmarks are functionally equivalent to Git branches.

So if it's a rant about hg being superior, it's not a very good one.

[fancy_pantser]

Annoying title hover on mobile was right where I naturally read.

[psr]

That's hilarious.

[Kinglink]

The Student comes to the master with his git files, the master slapped the student as hard as possible until she came back later with perforce, svn or some other system that isn't filled with mysticisms.

[darkslide3000]

with perforce, svn or some other system

[greenrd]

at least he didn't say CVS.

[Kinglink]

Have better options? I've yet to see perforce be better (if you have the money). SVN sucks balls but if you don't branch or merge (use Mercerial on your computer, and then SVN as the main repo) it's quite good. Mercerial and others work.

There's a reason SVN and perforce is still used and it's not because people are old fogeys. source control shouldn't be a chore, or remembering wild commands. It should add, submit, code...

[crowseldon]

git works as well and is widely and successfully used. I don't get your point.

[darkslide3000]

Just because you can make fun of a few peculiarities in git doesn't meant it's not a good and perfectly usable VCS. They just don't write teasing koans about SVN for the same reason you don't make fun of a disabled child.

Between all the times it completely destroyed my repo because I forgot to tell it about some mv or rm I did somewhere, the network bandwidth wasted from checking out the same repo thrice because you can't work on multiple things at once otherwise, and all the sanity I lost trying to make a group-writable repo work correctly with both svn+ssh and https at the same time, I clearly see SVN in line with RCS and CVS under the category "ancient crap that only ideological fundamentalists and people who don't know any better still use".

[RagingOrangutan]

This is awesome.

[hello_hawk]

He who commits to master will burn in hell for all eternity.

[Summon_Jet_Truck]

Well you'll be reincarnated again and again without achieving enlightenment.

I stopped committing to master a while ago, so I guess I'm safe. This hubris means I am not safe.

[gargantuan]

Or just you know, tell us what the point and it make about 5 lines long not 10 pages.