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

101–110 of 143 posts

Re: Git koans

#101

Post by philsnow »

I don't use a complicated .gitconfig (just user.name and user.email), so this is all new to me.

Something that leaps out to me as horribly wrong is that aliasing a builtin doesn't cause the config file to be "invalid". Doing anything else is just doing spooky things that are explained only several hundred lines into the man page by a single sentence.

Maybe better would be to choke on config lines that alias a builtin, and to print error messages before or after the output of each git command while the offending line(s) are present.

Further,

  git config alias.pull "pull --ff-only"
should definitely be an error. Instead, git gladly makes the (no-op) confusing edit to your config file.

Re: Git koans

#102

Post by Anderkent »

philwelch wrote: post #85
pilgrim689 wrote: post #77

Earlier quoted context omitted.

You're making the same mistake as GP. I love Git, and I know that asking "what branch was this commit on" makes no sense. My point is that some users have different requirements as to what a DVCS should provide. If Git can't fulfill some of these requirements, then just say "Git can't do this" rather than beating around the bush.

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 of which is simply putting the branch name at the start of the commit title. Of course that usually cuts the space available for the actual commit title down from ~60 characters to 20-40, depending on how verbosely you call your branches.

Re: Git koans

#103

Post by Anderkent »

philwelch wrote: post #73
aidenn0 wrote: post #59

Earlier quoted context omitted.

Maybe Linux kernel devs deserve that credit, but it's becoming increasingly clear that developers as a whole don't deserve that credit.

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!

Re: Git koans

#104

Post by Anderkent »

the_mitsuhiko wrote: post #62
aidenn0 wrote: post #60

Earlier quoted context omitted.

More people use git; I'm becoming increasingly convinced that few of them actually know git.

> More people use git; I'm becoming increasingly convinced that few of them actually know git. And yet I have noticed that people find merging and branching much easier than in mercurial. Few people understand the implications of named branches in hg.

> And yet I have noticed that people find merging and branching much easier than in mercurial.

That's the first time I've heard this opinion - do you know what kind of complaints people have?

In my experience, it's much easier to say 'When you start work on an issue, start a branch called 'issue-XXX', then once you're done we will merge it into the default branch'. I've never seen much confusion in response to that.

Re: Git koans

#105

Post by duaneb »

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.

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

Re: Git koans

#106

Post by jamesgeck0 »

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.

I am an expert user. I've been using git almost every day for months. I've read about it's underlying data model and could write a tool that used it if I really needed to.

I _still_ have to use Google whenever I try to do anything with git that falls outside my normal workflow.

Re: Git koans

#107

Post by elbear »

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.

What do you mean that git is used by expert users? Expert in what, git? If that is true, then I agree with you that you need to be an expert in git to be able to use it efficiently and not second guess yourself constantly when you come across a problem.

I agree that git's internal design is very well thought out. Its interface is very inconsistent though.

Re: Git koans

#108

Post by mpyne »

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…

> 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.

I don't see people doing too often, to be honest.

I do see git proponents saying that commands like git-checkout are misunderstood, but that isn't contradictory to "organic growth". From the beginning Linus was claiming that git was more of a content-addressable filesystem than an actual designed VCS.

If anything defenses like "git checkout -b is just shorthand for git branch && git checkout" are nothing but an acknowledgment of that organic growth. There's no reason to add a shorthand for a command sequence that no one uses.

Re: Git koans

#109

Post by mpyne »

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.

> 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.

I've found the --help option on probably a dozen commands without ever being specifically told that --help was a valid option.

If you have trouble discovering it you might want to look inward, at least for that particular well-known option.

Re: Git koans

#110

Post by Aga »

nazri1 wrote: post #34
ajanuary wrote: post #25

Earlier quoted context omitted.

> There is just a convenience operation on `git checkout` that also changes branches. Isn't that violating 'doing one thing'? (Your other examples in this point are valid, and serve to show how powerful building concepts on top of a few primitives can be, if confusing at times)

Here's how I view the checkout command: It is used to check out stuff from your git database into your working tree. Stuff here means either the whole tree or some files in it. You can check out a whole tree (branch) by specifying its sha1, or you can check out a single file by specifying the tree and the filename. The fact that checkout can be used to create a branch is just a convenience because most of the time it…

This is exactly what I tell students in my Git courses during the first hour.

Git checkout is a command to read something from your .git-folder to your working directory.

Especially for people coming from ClearCase, the concept of Git checkout needs to be clarified as fast as possible. (In CC checkout means you make an element (file) editable for you, and possibly reserve it to you too)

Post reply on HN