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

91–100 of 143 posts

Re: Git koans

#91

Post by DannyBee »

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.

Basically, people are wrapping stuff up in justifications that didn't even exist when the commands came to be.

That doesn't make it bad, of course, but uh, retroactively justifying things is always a bit odd to watch.

I actually could care less about either git or mercurial; having helped write subversion, the majority of us were/are glad that we were replaced by not just one, but two things that people like more. The fact that it "destroyed" our software is irrelevant, Subversion made what we set out to make, something better than CVS, succeeded, and then the world got even better through git and hg.

The fact that git and hg proponents seem to simply enjoy fighting about which VCS is better/worse, rather than concentrating on making actual progress, is fascinating to me.

Re: Git koans

#92

Post by koenigdavidmj »

__david__ wrote: post #88
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. Why? I find that in the middle of a big project I have lots of stupid files strewn about that I absolutely don't want checked in (TODO lists, patches I'm considering, copies of large log files I'm investigating, etc). I always add things explicitly and delete explicitly, otherwise I'd get random junk checked into my repo. How do you keep your repo clean enough to actually use automa…

Put that type of thing in .hgignore.

Re: Git koans

#93

Post by kyrias »

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

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.

If you want the branch in your prompt you should use the script that is shipped with git.

Re: Git koans

#94

Post by reinhardt »

aidenn0 wrote: post #75
the_mitsuhiko wrote: post #62

Earlier quoted context omitted.

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

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

Re: Git koans

#95

Post by __david__ »

koenigdavidmj wrote: post #92
__david__ wrote: post #88

Earlier quoted context omitted.

> The command addremove is genius. Why? I find that in the middle of a big project I have lots of stupid files strewn about that I absolutely don't want checked in (TODO lists, patches I'm considering, copies of large log files I'm investigating, etc). I always add things explicitly and delete explicitly, otherwise I'd get random junk checked into my repo. How do you keep your repo clean enough to actually use automa…

Put that type of thing in .hgignore.

Isn't that checked in like .gitignore? I'd rather not put stupid local stuff into a file that the rest of the team shares. And if I don't commit it then I'm stuck with a local file that always has changes, which is also begging for trouble. It also implies that I name things in some consistent way or that I add a lot of files into the ignore file.

I guess other people just aren't as messy as I am?

Re: Git koans

#96

Post by sirclueless »

wereHamster wrote: post #63
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…

`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 fo…

By the way, rm -rf does a lot more than rm+rmdir. You will probably learn this the hard way soon enough, unless you already know this and are just oversimplifying to show a point.

Re: Git koans

#97

Post by imissmyjuno »

giberson wrote: post #43
imissmyjuno wrote: post #37

Earlier quoted context omitted.

Surely you can't say that about `git branch -d` vs. `git rm` and other puzzling inconsistencies.

Yes I can, and am. As pointed out elsewhere, the commands are named for what they do not necessarily for how you would use them.

Which is terrible UI. I don't think we're disagreeing so much as diverging on the definition of what constitutes an issue here.

Re: Git koans

#98

Post by Anderkent »

wonderzombie wrote: post #72
stevelosh wrote: post #66

Earlier quoted context omitted.

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.

The question was not how to just get the current branch, thought, right? As pointed out already, `git branch` does that. The question was how to do it programmatically, and there are multiple ways to do it. You might still call that user interface, but it's that's a stretch; fancy shell magic like branch-in-prompt is typically write-once.

`git branch` doesnt do that. `git branch | less` followed by search might, if I remember some part of the branch name well enough to search for it.

Printing all the branches and having me scroll two screens up to find the one that's in color is not a solution to 'what branch am i on'

Re: Git koans

#99

Post by koenigdavidmj »

__david__ wrote: post #95
koenigdavidmj wrote: post #92

Earlier quoted context omitted.

Put that type of thing in .hgignore.

Isn't that checked in like .gitignore? I'd rather not put stupid local stuff into a file that the rest of the team shares. And if I don't commit it then I'm stuck with a local file that always has changes, which is also begging for trouble. It also implies that I name things in some consistent way or that I add a lot of files into the ignore file. I guess other people just aren't as messy as I am?

You can keep multiple ignore files. Then .hgignore can be shared by the whole team (if you're working in C, you're going to ignore .o files, for instance, and so will everyone else). Look up the ui.ignore hgrc option to add more files (presumably one of which doesn't sync).

Re: Git koans

#100

Post by Anderkent »

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…

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

How does having more information available ever hurt you?

Now, fair enough, the fact that mercurial expects branches to be unique might be annoying if you have the tendency to call all branches 'bugfix', but you seem to imply that simply having the branch name in which the commit was originally created as metadata on it would be somehow bad.

>git checkout does what it says on the tin: it checks out a branch or paths to the working tree.

'git checkout is good because checkout means the thing that git checkout does' riiiiight

Post reply on HN