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

131–140 of 143 posts

Re: Git koans

#131

Post by philwelch »

Anderkent wrote: post #128
philwelch wrote: post #126

Earlier quoted context omitted.

Lets back up: why are you trying to figure out what branch a historical commit was on? What problem does that solve for you? I've never found that information terribly important or interesting.

Say I bisect some issue to a particular commit. Knowing which branch it was made on tells me what issue it was trying to solve, which gives me context for the entire branch. It also means I can easily request all commits made in the master branch, to see what features were merged in recently.

> Say I bisect some issue to a particular commit. Knowing which branch it was made on tells me what issue it was trying to solve, which gives me context for the entire branch.

How is the branch name going to give you sufficient information on that anyway? You're going to have to look at the commit message and probably the surrounding history anyway if you want context for the entire branch.

> It also means I can easily request all commits made in the master branch, to see what features were merged in recently.

In this use-case, you're probably viewing some form of "git log" anyway, so it's not hard to turn on the option that shows the tree view, which should make it readily obvious.

Re: Git koans

#132

Post by philwelch »

aidenn0 wrote: post #120
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.

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.

It was discovered more or less by accident, I think. Similar to the story of M-expressions in Lisp: http://en.wikipedia.org/wiki/M-expression

Re: Git koans

#133

Post by Anderkent »

philwelch wrote: post #131
Anderkent wrote: post #128

Earlier quoted context omitted.

Say I bisect some issue to a particular commit. Knowing which branch it was made on tells me what issue it was trying to solve, which gives me context for the entire branch. It also means I can easily request all commits made in the master branch, to see what features were merged in recently.

> Say I bisect some issue to a particular commit. Knowing which branch it was made on tells me what issue it was trying to solve, which gives me context for the entire branch. How is the branch name going to give you sufficient information on that anyway? You're going to have to look at the commit message and probably the surrounding history anyway if you want context for the entire branch. > It also means I can easi…

>How is the branch name going to give you sufficient information on that anyway?

Well, in my workflow it will give me the issue number, since branches in my repo all look like '530-issue-description'. I suppose that's because we used to work with mercurial, where that is actually meaningful and helpful.

>In this use-case, you're probably viewing some form of "git log" anyway, so it's not hard to turn on the option that shows the tree view, which should make it readily obvious

The tree view will still interleave master commits with all the other commits, and if there's a lot of parallel branches and significant distance between master commits it's easy to get lost.

Tracking your single 'pipe' character down a couple pages and not losing which one you're watching... Not what I call good UI.

Re: Git koans

#134

Post by thedufer »

w0utert wrote: post #78
bvdbijl wrote: post #35

Earlier quoted context omitted.

Hg having kinks is not an excuse for git to have kinks too

And, in addition to that, I find it very hard to believe that anyone who used both can sincerely say Hg's CLI interface is 'just as bad' as git's. I've used both and switched to git eventually, because from a technical point of view it's simply the better tool. Git is faster, more flexible, easier to deploy. The things it is not: more intuitive, easier, more consistent. I don't understand why many git apologists cont…

> Git is faster

This is a bold claim, and depends on a lot of variables. On very large repos, git is completely unusable.

Re: Git koans

#135

Post by thedufer »

LeafStorm wrote: post #47
speeder wrote: post #11

I don't understood the suicidal git thing... Also of course I had to test the help commands! git branch --help opens man git branch -h throws those short commandline help summaries. Interestingly, -h does not mention -h itself or --help, so the only way to know that --help exists, is someone else telling you, you will never find on your own.

Or by using every other Unix command ever. (Disclaimer: This is a hyperbole.)

In every other Unix command ever, -h is the same as --help. Having used -h, I would never try --help if I was looking for something different.

Re: Git koans

#136

Post by develop7 »

ollysb wrote: post #82
templaedhel wrote: post #32

Earlier quoted context omitted.

Your critique seems to be based off comparing git to mercurial and declaring that git is designed better. I don't think you're going to see a ton of disagreement with that in this community. You make good points too, with context a lot of those commands make more sense. However well designed software shouldn't need the context. Well designed software is intuitive. We shouldn't need to know the intricacies in the git…

Normally I would agree with you that software should be intuitive with a minimum of learning. However git is only used by expert users, people who use it all day every day. There's no doubt that git has a bit of a steep learning curve but the abstraction you're forced to learn is really powerful. Having come from SVN the intuitive abstraction I was used to now seems woefully inadequate.

> git is only used by expert users

1 235 026 expert users, my eye

Re: Git koans

#137

Post by develop7 »

etjossem wrote: post #71

Context --- Master Git and a novice API developer stood together in a crowded office. "I am trying to merge two massive XML files," explained the API developer, "and I am getting many tedious conflicts. You must have a strategy for making the lines match up in a human-readable manner. What is my best option?" "Patience," said Master Git, turning away from the monitor. "But I have been manually resolving for hours!" p…

Create a pull request to https://bitbucket.org/sjl/stevelosh

Re: Git koans

#138

Post by develop7 »

the_mitsuhiko wrote: post #21
varikin wrote: post #12

Earlier quoted context omitted.

This may seem like a joke, but having used Hg a little bit, I do think it has a superior interface. The error messages are clear, the commands are intuitive. The command addremove is genius. But I still use git because I already grokked it before I learned hg.

> The command addremove is genius That's the default of what git does even without a command.

No, git doesn't track renames — git _guesses_ them

Re: Git koans

#139

Post by qznc »

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.

Git for computer scientists: http://eagain.net/articles/git-for-computer-scientists/

Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.

Re: Git koans

#140

Post by qznc »

reinhardt wrote: post #94
aidenn0 wrote: post #75

Earlier quoted context omitted.

Yeah, named branches in hg are just weird.

Not as weird as hijacking the term "branch" to mean a symlink to a ref that is not part of the history. Then again why make it easier by naming it to something more intuitive, like say, "bookmark".

Because a bookmark is usually immutable. If I bookmark "http://news.ycombinator.com has "Hacker News" it will be same URL forever.

In contrast, git branches symlink to a different ref, whenever you commit to it.

A git tag could be called bookmark intuitively.

Post reply on HN