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

Git koans

stevelosh.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Git koans

#111

Post by j-kidd »

DannyBee wrote: post #91
the_mitsuhiko wrote: post #19

A lot of these are just plain wrong though or have a good reason and it makes me sad because I know Steve Losh uses a lot of Mercurial which I think has a much worse UI. 1. Silence: you can't alias built-in commands — for good reason. You don't change the defaults of commands, that's just going to cause problems with scripts. Why is it ignored silently? For starters because new git versions can add a command that wou…

It's interesting to watch people here defend git's interface as if it was all a very deliberate, intricate design that is well justified and thought out, when it very clearly grew organically. Not that there was "no" thought, but it's not like there is a huge poster on a wall in Junio's office (I checked) or the surrounding whiteboards, that have git UI principles that are being enforced on new commands/patches. Basi…

Retroactively justifying things is what we always do. Here's an excerpt from Dan Ariely's "The (Honest) Truth About Dishonesty":

> The experience taught me that sometimes (perhaps often) we don't make choices based on our explicit preferences. Instead, we have a gut feeling about what we want, and we go through a process of mental gymnastics, applying all kinds of justifications to manipulate the criteria. That ways, we can get what we really want, but at the same time keep up the appearance -- to ourselves and to others -- that we are acting in accordance with our rational and well-reasoned preferences.

Simply replace all occurrence of "we" with "mercurial/git fanboys" based on your own preferences ;)

Re: Git koans

#112

Post by Aga »

duaneb wrote: post #105
philwelch wrote: post #87

Earlier quoted context omitted.

Git is predicated on the notion that it's actually quite simple and elegant how Git works, and programmers are clever enough to understand how their software works, so not much porcelain is necessary. There's a refreshing honesty to that.

I have no idea how git works. Where do they tell you? I'm curious to learn.

I have found the Pro Git book to be the best: http://git-scm.com/book

That, and constantly creating your own test repositories to test new commands/concepts. With a distributed VCS it's easy and fast. Just run "git init test" somewhere and start committing!

I also recommend you to use "gitk" when you're learning to constantly look at your history tree. That should clarify the concept "branches are pointers" after a few tests.

Re: Git koans

#113

Post by Aga »

syncsynchalt wrote: post #80
the_mitsuhiko wrote: post #26

Earlier quoted context omitted.

> I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it). What about the index? Or the branching (bookmarks kinda work now I think), or the better remote management?

You're touting these as positives for git but in the context of training a large group to use a new VCS they are a negative.

I have found branching in Git to be a pleasure to teach, even to large groups. There is nothing I have to hide about them, implementation or otherwise. "This is how it works and this is what you can do thanks to that"

Re: Git koans

#114

Post by j-kidd »

the_mitsuhiko wrote: post #55
tootie wrote: post #33

Earlier quoted context omitted.

I personally hate the index. It gets in my way far more often than I actually make use of it.

How does it ever get in the way? Just add `-a` and you can essentially ignore that there is an index on commits.

Let's say I modified an existing file (not staged) and then git add a new file. It is a work in progress, and the two changes are not supposed to be in the same commit.

Now, what can I do to see all changes I have made so far?

I have done this many times with subversion (svn diff) and mercurial (hg diff). Git's index just get in the way.

Re: Git koans

#115

Post by Aga »

Even if this was meant as an critique to Git, I (some kind of a Git-evangelist) enjoyed it a lot. I even learned something new!

The critique is quite well established. One needs to understand these quirks to be an enlightened Git user.

However we make up with them, as the overall gain from Git's approach to version control is so big.

Some things could be improved though, like introduce something like "git branch --current" to avoid the Hobgoblin...

Re: Git koans

#116

Post by duncan_bayne »

DannyBee wrote: post #91
the_mitsuhiko wrote: post #19

A lot of these are just plain wrong though or have a good reason and it makes me sad because I know Steve Losh uses a lot of Mercurial which I think has a much worse UI. 1. Silence: you can't alias built-in commands — for good reason. You don't change the defaults of commands, that's just going to cause problems with scripts. Why is it ignored silently? For starters because new git versions can add a command that wou…

It's interesting to watch people here defend git's interface as if it was all a very deliberate, intricate design that is well justified and thought out, when it very clearly grew organically. Not that there was "no" thought, but it's not like there is a huge poster on a wall in Junio's office (I checked) or the surrounding whiteboards, that have git UI principles that are being enforced on new commands/patches. Basi…

Thank you for Subversion :) Not only was it better than CVS but it was a damn site better than Visual SourceSafe too, which was often the alternative in Microsoft-land.

Re: Git koans

#117

Post by philwelch »

Anderkent wrote: post #102
philwelch wrote: post #85

Earlier quoted context omitted.

I'm saying that "for the user" is a distinction not necessary for a tool designed for the type of people who actually know how software works. For the user, Git does the same thing that it does for the programmers who wrote Git. There's only one side of it. It's not two-faced like most software. The only possible explanation is to explain how Git works.

No, a possible explanation would be 'that is unnecessary, because: ...'. Except of course tagging commits with branches is not unnecessary, because that's the only way a user might make sense of ancestors of a merge commit... Unless you like manually tracking parents of a commit, and trying to guess which branch is which based on commit messages. Fun! I've seen many workarounds to this clear deficiency, the simplest…

> Unless you like manually tracking parents of a commit

Git tracks the parents of a commit. There are ways to visualize that, even with command-line git. When you do this, it's usually clear which branch is master and which branch was the feature branch, and since the merge commit has a default commit message like "merge > to master" it's even easier to figure out.

It's also entirely possible to use a Git workflow where you rebase your branches onto master before merging then in with a fast-forward, which means there are no merge commits. This workflow usually involves squashing. Conversely, you can use a workflow where you never fast-forward merge to master, in which case master is the branch that consists of a series of commits called "merge > to master".

Re: Git koans

#118

Post by philwelch »

Anderkent wrote: post #103
philwelch wrote: post #73

Earlier quoted context omitted.

That's their problem. There are tools for fools. I'm glad I don't have to use them.

Of course everyone who doesn't like your tool is a fool. It's just not possible they'd have different but equally valid requirements!

Someone who can't understand the Git data model is, by programmer standards, a fool. If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Unfortunately, most criticisms come from people who can't be arsed to grok how Git works and just ragequit.

Re: Git koans

#119

Post by aidenn0 »

philwelch wrote: post #118
Anderkent wrote: post #103

Earlier quoted context omitted.

Of course everyone who doesn't like your tool is a fool. It's just not possible they'd have different but equally valid requirements!

Someone who can't understand the Git data model is, by programmer standards, a fool. If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Unfortunately, most criticisms come from people who can't be arsed to grok how Git works and just ragequit.

Going back to my comment, I think for a lot o peole it's not that they can't understand the Git data model, it's that they:

1) don't magically know that they're supposed to understand the data model in order to use it

2) Come for help when they screwed up because they don't understand it and are basically told "You screwed up because you're an idiot"; since they are already in a bad mood, they then ragequit.

Re: Git koans

#120

Post by aidenn0 »

philwelch wrote: post #87
aidenn0 wrote: post #58

Earlier quoted context omitted.

What you described is how git thinks of branches. Most developers think of branches as something they commit to. Therefore they are surprised when later they can't tell which branch they committed to. This could trivially be fixed with porcelain that puts the name of the branch the commit was made to at the end of the commit message. The issue of branches not really being branches is not unique to git; most VCs I've…

Git is predicated on the notion that it's actually quite simple and elegant how Git works, and programmers are clever enough to understand how their software works, so not much porcelain is necessary. There's a refreshing honesty to that.

That's not my understanding of it's history; it was originally planned to have, potentially, multiple porcelains, but that idea died of a couple years back.
Post reply on HN