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

Still hatin' on git: now with added Actual Reasons

reprog.wordpress.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Still hatin' on git: now with added Actual Reasons

#151

Post by koenigdavidmj »

Xurinos wrote: post #98
pyre wrote: post #63

Earlier quoted context omitted.

The point -- as I understand it -- is that the author feels that a version control system should act like X. So he takes a random version control system, reads about it briefly, and then tries to use it assuming that it acts like X. The version control system doesn't act like X, which leads to problems for the author. Author writes a blog post about how random version control system sucks because it doesn't meet his…

That is what I got out of it. A big clue was his "git commit filename". git is not svn. Is git's greatest sin really that it uses a few of the same words with different meanings from how they have been used in the past? Someone in another post mentioned revert. svn revert file == git checkout file, while git revert patches out a whole change. It actually makes sense if you forget about cvs and svn's version of the AP…

The only valid point made is that checkout has two functions:

* If there does not exist a branch 'foo', then 'git checkout foo' will reset the file named foo to the head.

* If such a branch does exist, then 'git checkout foo' will move to that branch. You have to say 'git checkout -- foo' to have the first behaviour.

Re: Still hatin' on git: now with added Actual Reasons

#152

Post by thenduks »

phaylon wrote: post #148
thenduks wrote: post #146

Earlier quoted context omitted.

I don't really want my tool to be the kind of paranoid you're describing. I know what I'm doing, I've never lost changes like that, and I don't want git acting like it knows better. The commands are semantically correct, you just need to use them in conjunction with your brain.

Er, first, if you'd like to call me stupid, please do so openly. Personally, I like safety-features on tools. You know that feature that stops rotating blades when they come into contact with fingers? Would "just don't touch the blade" have been an equal solution to you?

I didn't mean to imply you personally are stupid. Just that 'one' wanting to use git should effectively concede that it gives you the tools to cut off your hands if that's what you're aiming to do.

So as to your next point, I don't think that's a very good analogy. If the rotating blades are meant to be used to amputate limbs and to cut logs in half - then yes, I'd say if you are trying to cut a log in half you shouldn't put your arm in it.

Re: Still hatin' on git: now with added Actual Reasons

#153

Post by phaylon »

Xurinos wrote: post #149
phaylon wrote: post #137

Earlier quoted context omitted.

You mean it actually makes sense if you forget the other VCS versions of that command, and know git's? Because ignoring all VCS experience I have, "checkout" would indicate to me that I could "check something out" as in "have a peek at it."

In git, it means "checking out the current branch version of a file" or "checking out an entire branch". Pulling all the patches from another resource also makes sense. Think of checkout as a local thing to do, and pull/fetch as a remote action. It can make sense if you do not have prior associations. It is not as if the English language is not terribly abused and ambiguous in our languages. What does "cancel" mean?…

"What does "cancel" mean? In linux with CUPS, it cancels a print job. To cancel a process, you have to kill it, but you cannot kill print jobs. Shocking."

Those are different projects. Git is one. OO is an abstract concept, we're talking about git communicating to the user, and what level the user must have to understand that communication.

The problem is not that git and svn have different opinions on what "checkout" means, it's that git itself has different opinions on what it should mean.

Again, why is it so bad that we say the interface could be better? Why do so many of those that managed to get a grip on this feel the need to strictly deny that there could be any problem in the interface itself?

Yes, Linus designed it. But he's just human too.

I still have yet to see a single useful advantage of mixing up different meanings in the same word. All I get is "It is that way, learn it or GTFO."

Re: Still hatin' on git: now with added Actual Reasons

#154

Post by phaylon »

thenduks wrote: post #152
phaylon wrote: post #148

Earlier quoted context omitted.

Er, first, if you'd like to call me stupid, please do so openly. Personally, I like safety-features on tools. You know that feature that stops rotating blades when they come into contact with fingers? Would "just don't touch the blade" have been an equal solution to you?

I didn't mean to imply you personally are stupid. Just that 'one' wanting to use git should effectively concede that it gives you the tools to cut off your hands if that's what you're aiming to do. So as to your next point, I don't think that's a very good analogy. If the rotating blades are meant to be used to amputate limbs and to cut logs in half - then yes, I'd say if you are trying to cut a log in half you shoul…

"I didn't mean to imply you personally are stupid."

You implied I wasn't using my brain when using git. What did you want to imply with that if not stupidity?

"Just that 'one' wanting to use git should effectively concede that it gives you the tools to cut off your hands if that's what you're aiming to do."

Not sure I get that. I need to use git, so it's my fault? The thing about a mistake is that I wasn't aiming to do it.

"If the rotating blades are meant to be used to amputate limbs and to cut logs in half - then yes, I'd say if you are trying to cut a log in half you shouldn't put your arm in it."

Who would build such a thing? And even further, who would build a machine with 100 buttons, two of which look exactly the same, but one cuts wood, one cuts of your arm.

What is to gain by having a destructive file operation and a non-destructive branch operation have the same name? Why do people seem to feel hurt when people suggest to name them separately?

Re: Still hatin' on git: now with added Actual Reasons

#155

Post by arantius »

rue wrote: post #112
arantius wrote: post #88

Earlier quoted context omitted.

> 'git checkout ' == 'replace with the version of in the index' (if the index is empty, then index == HEAD) Well, really: "git checkout foo" means: 1) Switch the branch, if foo is a branch. 2) Destroy all local modifications, if foo is a file. These are two drastically different actions, and they're given the same name. The "rm" command has one name, and does one thing: remove files. It isn't also, sometimes, used to…

> 2) Destroy all local modifications, if foo is a file. Not exactly. It updates the file to the state from the index . git-checkout is just poorly overloaded. The idea is the same in both operations (updating some set of files in the working directory to some state from this or some other branch) but the two should be separated.

> Not exactly. It updates the file to the state from the index.

Whoops, you got me. I of course meant "in the working tree" when I said local. It's just easy to be close, but not quite, right with the terminology.

Re: Still hatin' on git: now with added Actual Reasons

#156

Post by thenduks »

phaylon wrote: post #154
thenduks wrote: post #152

Earlier quoted context omitted.

I didn't mean to imply you personally are stupid. Just that 'one' wanting to use git should effectively concede that it gives you the tools to cut off your hands if that's what you're aiming to do. So as to your next point, I don't think that's a very good analogy. If the rotating blades are meant to be used to amputate limbs and to cut logs in half - then yes, I'd say if you are trying to cut a log in half you shoul…

"I didn't mean to imply you personally are stupid." You implied I wasn't using my brain when using git. What did you want to imply with that if not stupidity? "Just that 'one' wanting to use git should effectively concede that it gives you the tools to cut off your hands if that's what you're aiming to do." Not sure I get that. I need to use git, so it's my fault? The thing about a mistake is that I wasn't aiming to…

What is to gain by having a destructive file operation and a non-destructive branch operation have the same name? Why do people seem to feel hurt when people suggest to name them separately?

Because they are both the semantically correct name for the operation. Check out a file, overwriting my local unstaged changes. Or checkout an entirely new working copy from the point referred to by a branch.

I don't feel hurt that you suggest it, though. In fact I mentioned in another comment that I always thought `git branch` could do the switching itself rather than checkout... I just don't think it's a problem. I know I'm working with a file or a branch, so I just know what will happen. It doesn't matter that the name is the same since it's function depends on context.

Re: Still hatin' on git: now with added Actual Reasons

#157

Post by phaylon »

thenduks wrote: post #156
phaylon wrote: post #154

Earlier quoted context omitted.

"I didn't mean to imply you personally are stupid." You implied I wasn't using my brain when using git. What did you want to imply with that if not stupidity? "Just that 'one' wanting to use git should effectively concede that it gives you the tools to cut off your hands if that's what you're aiming to do." Not sure I get that. I need to use git, so it's my fault? The thing about a mistake is that I wasn't aiming to…

What is to gain by having a destructive file operation and a non-destructive branch operation have the same name? Why do people seem to feel hurt when people suggest to name them separately? Because they are both the semantically correct name for the operation. Check out a file, overwriting my local unstaged changes. Or checkout an entirely new working copy from the point referred to by a branch. I don't feel hurt th…

"Check out a file, overwriting my local unstaged changes. Or checkout an entirely new working copy from the point referred to by a branch."

Well, of course they both seem the same if you use the word "checkout" in the explanation for "checkout." But "rolling back changes in a file" and "switching the current branch I'm developing in" aren't that close anymore. The word itself might mean multiple things, but that doesn't imply it's a good idea to use it in both meanings.

"In fact I mentioned in another comment that I always thought `git branch` could do the switching itself rather than checkout... I just don't think it's a problem. I know I'm working with a file or a branch, so I just know what will happen."

But evidently there are people who do think it's a problem. Also, the argumentation is that this would prevent mistakes from being destructive. When you know what you want to do, and it does it, it's not a mistake. When you want to do one thing, but the other one happens for any reason (bash completion was one of the mentioned ones) you don't know it.

"It doesn't matter that the name is the same since it's function depends on context."

It depends on the type of its argument. A simple "git checkout foo" is indistinguishable. I'm just a bit astounded by the amount of contra to this simple proposal to an existent problem.

Re: Still hatin' on git: now with added Actual Reasons

#158

Post by pellicle »

itistoday wrote: post #103
avar wrote: post #68

Earlier quoted context omitted.

Why yes, a lot of us are just fine spending "hours" learning something that we'll probably spend more than a few years using. Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. You're not going to come up with some solution that allows the user to "just do it"…

> Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex. This is a limitation of your imagination. You can write a DVCS that's easy to use and intuitive. Git has an absolutely terrible UI, it borders on idiotic. One example of a DVCS with a good design and UI is a…

How do you think the Bzr UI design compares with that of Hg?

Re: Still hatin' on git: now with added Actual Reasons

#159

Post by pellicle »

moe wrote: post #10

Don't give up faith my friend. Git and mercurial are not the end of the story. I'm optimistic that, within another few years (give or take a decade), someone will come up with a VCS that's both powerful and usable. :-) Other than that: I enjoyed your article. Very nice walk through some of the problems and hair-pulling that I'm going through regularly, too. Pro-Tip: My life with git got a bit easier since I keep this…

> Git and mercurial are not the end of the story.

> I'm optimistic that, within another few years (give or take a decade), someone will come up with a VCS that's both powerful and usable. :-)

Do you think Hg shares the same amount of usability as Git?

Re: Still hatin' on git: now with added Actual Reasons

#160

Post by pyre »

lars512 wrote: post #123
pyre wrote: post #110

Earlier quoted context omitted.

Issues that I've heard of with Bazaar: - Being pure Python it doesn't have the same performance that git does. This may not show up in day-to-day usage, but things like 'convert this svn repo to Bazaar' tend to bring the bottlenecks/performance issues into the light. - Bazaar made this weird design decision to have two revision numbers. a 'r12345' type revision number that is similar to SVN, but only applies to your…

The use case for numeric local revisions is pretty clear. How many global operations do you really do? In reality, nearly all operations are local. So would you rather write r37 or 0b090d7267df? Why wouldn't you want the choice?

Two points:

1. You can abbreviate the SHA-1's in git

2. When you are collaborating on code, it's much more common to use a global identifier so that people can all know which commit is being referenced. It seems like you are making things needlessly complex when you are trying to maintain local and global revision numbers, for little (in my opinion) return. Sure 'r37' is easier to remember off-hand than '5b98d8f' (a shortened SHA1), but if you memorize 'r37' it only means something locally, you'll still have to lookup the global revision id when you want to communicate with others.

Post reply on HN