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

61–70 of 143 posts

Re: Git koans

#61

Post by the_mitsuhiko »

stevelosh wrote: post #29
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…

1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? That's better than telling you "hey this isn't going to do what you think any more"? Do you have `try: foo except: pass` in your Python code too? Come on. There's no reason git shouldn't at least warn you on stderr here. 2. `git checkout -- somefile.py` does not have anything to d…

> 1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command?

Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea.

> `git checkout -- somefile.py` does not have anything to do with checking out a revision.

Of course not. `git checkout` checks out things. You can check out a lot of things. Just because it works differently in hg does not mean it's wrong in git. git checkout does what it says on the tin: it checks out a branch or paths to the working tree.

> I like Mercurial's named branches because I don't need to create a branch for every single commit.

I think the concept of named branches in mercurial are hugely flawed and were the final nail in the coffin of why I migrated over to git. And I never looked back.

> What if you want the current branch in your prompt?

Then you use the underlying low-level commands or even better, you cat `.git/HEAD` which will be even faster. Not sure why for your prompt to look nice you need to have non-cryptic commands. Exactly for things like prompts there is the plumbing.

> gives you the same power as Git and has a UI where "--help x", "-h x", "help x", "x -h", and "x --help" all do the same thing

How is this different from mercurial? If anything mercurial has even more ways to show help: `man hg` which shows the manpage for all the builtin commands. `hg help` which shows a short version or `hg -v help` which shows a long version (which is not the man page). git only has two help pages: man pages for long and short text for short.

> gives you the same power as Git

I have yet to see this.

Re: Git koans

#62

Post by the_mitsuhiko »

aidenn0 wrote: post #60
the_mitsuhiko wrote: post #23

Earlier quoted context omitted.

> That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway. Considering more people know git I would assume the training cost for hg is higher.

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.

Re: Git koans

#63

Post by wereHamster »

stevelosh wrote: post #29
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…

1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? That's better than telling you "hey this isn't going to do what you think any more"? Do you have `try: foo except: pass` in your Python code too? Come on. There's no reason git shouldn't at least warn you on stderr here. 2. `git checkout -- somefile.py` does not have anything to d…

`And how should I create a branch?. Use git checkout.` No. You create a branch with git branch. If you want to create a branch and immediately switch to it, use git branch (to create it) + git checkout (to switch to it). git checkout -b is just a shorthand for the two, it's there just for convenience. Unix has a lot of these occurrences. rm -rf as a shorthand for rm+rmdir, the open() syscall with O_CREAT shorthand for creat()+open() etc.

Re: Git koans

#64

Post by micampe »

the_mitsuhiko wrote: post #61
stevelosh wrote: post #29

Earlier quoted context omitted.

1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? That's better than telling you "hey this isn't going to do what you think any more"? Do you have `try: foo except: pass` in your Python code too? Come on. There's no reason git shouldn't at least warn you on stderr here. 2. `git checkout -- somefile.py` does not have anything to d…

> 1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. > `git checkout -- somefile.py` does not have…

> Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea.

You should understand what you are responding to before typing your answer.

Say today I create an alias “boom = ” and next week git introduces a boom command.

Now my alias is ignored, my scripts are broken and I might destroy my working copy or kill my cat by using it without knowing it now means something else.

Git gives some very stupid hints “branhc is not a git command, did you mean branch?” it should also warn me when I defined an invalid alias.

Maybe that alias was valid two versions ago or I just don’t know that command exists, since there are eleventy thousand of them.

Re: Git koans

#65

Post by GhotiFish »

giberson wrote: post #30
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…

Either you or I have misunderstood the article. These koans aren't criticism. They are stories meant to enlighten readers to lessons regarding git. If you see each of these stories as criticism's about git, then you are the novice. Once you receive enlightenment on each story you will realize why each story is not criticism--you will see the error of the reasoning of the novice in the story and you will understand wh…

These really DO seem like criticisms. Particularly the hobgoblin. Given the context of the author[1] pointed out by the parent post, I think the thrust of these koans is obvious.

Personally It feels a bit dirty. I started out enjoying them, now they feel petty.

1. http://stevelosh.com/blog/ Scroll down. Mercurial everywhere.

Re: Git koans

#66

Post by stevelosh »

the_mitsuhiko wrote: post #61
stevelosh wrote: post #29

Earlier quoted context omitted.

1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? That's better than telling you "hey this isn't going to do what you think any more"? Do you have `try: foo except: pass` in your Python code too? Come on. There's no reason git shouldn't at least warn you on stderr here. 2. `git checkout -- somefile.py` does not have anything to d…

> 1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. > `git checkout -- somefile.py` does not have…

If your solution to "get the current branch" is "cat out this magic data file that happens to exist in the data directory" then we have completely incompatible definitions of "user interface" and are never going to agree on this.

Re: Git koans

#67

Post by stevelosh »

the_mitsuhiko wrote: post #56
stevelosh wrote: post #36

Earlier quoted context omitted.

No it's not. [alias] addremove = !git add . && git add -u That will do it though, so it's not too hard to add.

Git does it on `git commit -a`.

No, it doesn't.

    -a, --all
        Tell the command to automatically stage files
        that have been modified and deleted, but new
        files you have not told Git about are not affected.

Re: Git koans

#68

Post by the_mitsuhiko »

micampe wrote: post #64
the_mitsuhiko wrote: post #61

Earlier quoted context omitted.

> 1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. > `git checkout -- somefile.py` does not have…

> Yes. Otherwise command line scripts will start doing horrible things. It was never intended that you can alias builtins, the only reason you might think you can is because it is allowed in mercurial which I think is a horrible idea. You should understand what you are responding to before typing your answer. Say today I create an alias “boom = ” and next week git introduces a boom command. Now my alias is ignored, m…

> Now my alias is ignored, my scripts are broken and I might destroy my working copy or kill my cat by using it without knowing it now means something else.

Your scripts should not rely on aliases you have in your config. Scripts are intended to be used by different people.

Re: Git koans

#69

Post by the_mitsuhiko »

stevelosh wrote: post #67
the_mitsuhiko wrote: post #56

Earlier quoted context omitted.

Git does it on `git commit -a`.

No, it doesn't. -a, --all Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.

Ah, it's too long since I used hg. Thought it only picks up deletes.

Re: Git koans

#70

Post by npsimons »

GhotiFish wrote: post #65
giberson wrote: post #30

Earlier quoted context omitted.

Either you or I have misunderstood the article. These koans aren't criticism. They are stories meant to enlighten readers to lessons regarding git. If you see each of these stories as criticism's about git, then you are the novice. Once you receive enlightenment on each story you will realize why each story is not criticism--you will see the error of the reasoning of the novice in the story and you will understand wh…

These really DO seem like criticisms. Particularly the hobgoblin. Given the context of the author[1] pointed out by the parent post, I think the thrust of these koans is obvious. Personally It feels a bit dirty. I started out enjoying them, now they feel petty. 1. http://stevelosh.com/blog/ Scroll down. Mercurial everywhere.

Yeah, about a third of the way through "Git Koans" I got the strong suspicion that the author was a Mercurial fan. It had potential and started out kind of amusing, but definitely felt like a bullied kid's fantasy near the end. Shame, too, as many of the author's other posts seem very well written and insightful. Eh, nobody's perfect.
Post reply on HN