7 ms·

I have read a fair amount of documentation on git. I still don't even know what most git commands do. When people recommend a rebase, I pretty much just prete

by ynniv 16y ago

I have read a fair amount of documentation on git. I still don't even know what most git commands do. When people recommend a rebase, I pretty much just pretend that my repository isn't going to die. I wince every time I have to revert a file, as "git checkout" is friendly but "git checkout <filename>" is destructive without warning. I once destroyed a number of local files (I don't remember how) that were thankfully still open in emacs. git is awesome, and git is terrible, often for the same reasons. git is a Sharp Knife, which is fantastic if you need one, and horrible if you don't. I personally have basic distributed version control needs and git is far too sharp for my needs. I have managed to not cut anything important off, but I tread carefully around each command, often worrying that I will irrevocably destroy my files. So, +1 for being way better than previous version control systems, but a friendlier modern version control might easily win.

pyre 16y ago
> 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.]
- barrkel 16y ago
  '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.
  - pyre 16y ago
    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.
    - barrkel 16y ago
      On the face of it, I think it's dangerously misleadingly named, but that's all.
- viraptor 16y ago
  Not a good comparison. "rm" stands for remove; "f" stands for force. Neither "git" nor "checkout" indicate anything irreversible or destructive.
  - pyre 16y ago
    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.
- AngryParsley 16y ago
  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.
  - thenduks 16y ago
    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.
    - phaylon 16y ago
      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.
      - thenduks 16y ago
        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.
        phaylon 16y ago
- arantius 16y ago
  > '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.
  - rue 16y ago
    > 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.
- ynniv 16y ago
  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.
  - avar 16y ago
    > 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".
d0mine 16y ago
Once files are added to git it is almost impossible to destroy them irrecoverably. So my impression of git is the opposite I perform any command without fear to lose anything. If the command doesn't do what I need I just rollback to the last known good state.
- pyre 16y ago
  'git gc' ? ;-)
  - kuahyeow 16y ago
    http://www.kernel.org/pub/software/scm/git/docs/git-gc.html http://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound)."
    - pyre 16y ago
      If you have an object that's no longer referenced by anything you can lose it when you garbage collect, which was my point. I was only being half-serious, which is what the wink was meant to convey.
fr0sty 16y ago
If you are having trouble with git losing your changes you shouldf really be committing more often. Once a change is in git it is very hard to lose but until it is in git losing it is very easy.

by ynniv 16y ago

pyre 16y ago

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

barrkel 16y ago
'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.
- pyre 16y ago
  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.
  - barrkel 16y ago
    On the face of it, I think it's dangerously misleadingly named, but that's all.
viraptor 16y ago
Not a good comparison. "rm" stands for remove; "f" stands for force. Neither "git" nor "checkout" indicate anything irreversible or destructive.
- pyre 16y ago
  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.
AngryParsley 16y ago
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.
- thenduks 16y ago
  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.
  - phaylon 16y ago
    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.
    - thenduks 16y ago
      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.
      - phaylon 16y ago
arantius 16y ago
> '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.
- rue 16y ago
  > 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.
ynniv 16y ago
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.
- avar 16y ago
  > 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".

d0mine 16y ago

Once files are added to git it is almost impossible to destroy them irrecoverably. So my impression of git is the opposite I perform any command without fear to lose anything. If the command doesn't do what I need I just rollback to the last known good state.

pyre 16y ago
'git gc' ? ;-)
- kuahyeow 16y ago
  http://www.kernel.org/pub/software/scm/git/docs/git-gc.html http://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound)."
  - pyre 16y ago
    If you have an object that's no longer referenced by anything you can lose it when you garbage collect, which was my point. I was only being half-serious, which is what the wink was meant to convey.

fr0sty 16y ago

If you are having trouble with git losing your changes you shouldf really be committing more often. Once a change is in git it is very hard to lose but until it is in git losing it is very easy.