Hacker News Reader

Comment by pyre | Hacker News Reader

> I wince every time I have to revert a file, as "git checkout" is friendly but "git checkout <filename>" is destructive without warning.

From my point of view, that's like saying that 'rm -rf' is destructive 'without warning.' It does what it was meant to do, you can't expect everything to warn you all the time in an effort to save you from yourself. It would get really annoying, really fast if it asked you to confirm every time you performed an operation in git.

'git checkout <filename>' == 'replace <filename> with the version of <filename> in the index' (if the index is empty, then index == HEAD)

I'm also unsure how 'svn checkout <filename>' is less destructive.

[Note: Though these 'git debates' tend to get heated because you have "frustrated people that don't understand git but are trying to use it" on one side and "people that understand git and are frustrated at the 'ignorance of newbs'" on the other side, this is not an attack.]

View on HN

that's like saying that 'rm -rf' is destructive 'without warning.'

Well, "rm -r" when run as root does warn. You have specified a flag that explicitly doesn't not ask. Also, "rm" only ever destroys things, whereas "git checkout":

  - creates a new branch (non-destructive, additive)
  - switches to an existing branch (non-destructive)
  - obliterates uncommitted changes to a file (destructive)

And the two major modes (destructive and non-destructive) have no syntactical differences. "git checkout X/Y" is non-destructive if X is the name of a remote and Y a file, and destructive if X is the name of a folder and Y a file. Deep down, you know this just isn't right.

The chief problem with git is that the user interface is a simple reflection of the mechanics and vocabulary used to implement it. That first part is great for performance, and the whole thing might seem like a good idea if you happen to be a filesystem hacker, it's arbitrary nonsense to the rest of the world.

git has been purposely architected so that you do not lose data. "stash" allows you to temporarily store local changes while you test things out. Extensive branching is key to sharing patches in a trackable way. Most destructive commands actually alert you that data will be lost. I really like this philosophy of never accidentally losing anything.

But the interface is inconsistent and needlessly complex, and should not be defended. git could be vastly improved simply by changing the command structure and vocabulary. Destructive commands could universally prompt unless an option ("-f"?) is specified.

Maybe someone could make "tig", which is a proper version control system organized from an everyday user's perspective, based on git.

> Well, "rm -r" when run as root does warn.

No it doesn't, but perhaps you're using a distro (like RedHat) where "rm -r" is actually aliased to "rm -ri".

> 'git checkout <filename>' == 'replace <filename> with the version of <filename> 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 gain access to otherwise inaccessible files. I think, ultimately, the names are the worst part of git for me.

There's checkout, which is ambiguous. I'm used to using "svn revert" in the past, but I have to use "git checkout" to do that ... at least for individual files. If I want to do them all, "git reset" is, usually, what I'm looking for in this case. The "git revert" command also exists, but does something different (apply past commits in reverse). Git has three different commands for the "put the files back the way they used to be" concept (at least, are there more I don't know about yet?).

Then there's "the in between thing". From the man pages:

If you're doing "git add" then it "updates the index using the current content found in the working tree" and "the content staged for the next commit". If you're doing "git reset" then you have to ask for "--mixed" or "--hard" in order to "resets the index". If you're doing "git diff" then you have to ask for "--cached" to get the "changes you staged for the next commit". Then there's "git ls-files" which talks about "the file listing in the directory cache index" and "--cached Show cached files" and "--stage Show staged contents object name". Wait, "--cached" and "--staged" are different options?

So what is it? Is it "the index" or "the stage" or "the cache"? Do I have to pass "--hard" or "--cached" or "--index"? Whoops, I made that last one up! But wouldn't it be nice if it had one name, and that's always the name I used to refer to it? I know there's something between "files I edit on disk" and "files in the repository" but the documentation does anything but make it clear what that something is even called.

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

'svn checkout <filename>' isn't a valid svn operation; checkout applies to directory urls. Actually, beyond svn revert, I struggle to think of an easy way for you to lose your local modifications. If you really just wanted the latest version of <filename>, I guess you might use svn cat, but you'd have to redirect it to overwrite the other file yourself. For svn update, it won't overwrite local modifications.

svn revert seems to be better named for this purpose.

Sorry, it's been a while. But yea. 'git checkout <filename>' is basically doing what 'svn revert <filename>' is doing. So, I fail to see how one is necessarily 'more dangerous' than the other.

On the face of it, I think it's dangerously misleadingly named, but that's all.

Not a good comparison. "rm" stands for remove; "f" stands for force. Neither "git" nor "checkout" indicate anything irreversible or destructive.

Well you should be using more than just the 'name of the command' as your determination of whether or not you should just run a command with little to no understanding of the consequences... Unless the command is 'do-something-completely-safe' and it doesn't live up to it's name, then I'm failing to see the issue. 'git checkout' doesn't convey safety or danger, so I would think that one should try to have a grasp of what it does before randomly running it.

Git checkout also switches branches. "Checkout" sounds pretty safe, and svn has a checkout command (Which doesn't do anything but print an error message if you're in a working directory. It's the equivalent of git clone.). Finally, in most commands, git is paranoid about not destroying your changes. Combine all of these and you're in for a nasty surprise.

It's still being paranoid. You shouldn't be checking out anything while you have working copy changes unless you really, really mean to. This is why it's not a big deal that it's named the same.

Also, git defaults to working on a branch if the names conflict. If I have branch 'foo' and file 'foo' (both terrible names for files and branches) and try: `git checkout foo` it will switch to the foo branch and not checkout the file. Why would you ever do this with working copy changes except in very rare circumstances?

In short, I'm suggesting that if you have working copy changes then `checkout` means "restore this file to it's state in the index" and if you don't have working copy changes then it means "switch to this branch".

Since you always know if you have working copy changes or not, this is a pretty easy distinction to make.

That's not being paranoid, that's depending on me being paranoid. People make mistakes, and a clearer separation of these two functions would make it harder to make this mistake.

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.

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

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.

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

Reply on news.ycombinator.com