3 ms·

You didn't lose any data in that scenario. Every line of code you wrote still exists in those files. The problem is that you are in a conflicted state that must

You didn't lose any data in that scenario. Every line of code you wrote still exists in those files. The problem is that you are in a conflicted state that must be manually resolved. Unfortunately, making updates atomic across a branch has disadvantages. For example, svn lets you update individual files or directories instead of the whole branch. If you want to avoid this pitfall in the future, run "svn merge --dry-run -r BASE:HEAD ." before a real update. (I wish svn update had a --dry-run flag. Just because git is bad doesn't mean svn is perfect.) Also, your scenario is extremely unlikely. I've used svn for 5 years and I've encountered that problem once. It was for a binary file. Two versions of the same image. It's not very often that two developers create a new file with the same name at practically the same time. It's even less often that those files can be properly merged. By your logic, "rm" is flawed because it doesn't ask for confirmation when you pass -f instead of -i. Well, yeah. Sorry. $ git checkout blah This command either switches to branch blah or it erases all uncommitted changes in a directory or file named blah. Without more information, you can't tell. I find that frustrating and annoying. Your analogy would be more accurate if rm somename was the equivalent of apt-get update, and rm othername was rm -fr othername. Oh, and somename is never tab-completed but othername is.

pyre 16y ago
> You didn't lose any data in that scenario. Every line of code you wrote still exists in those files. The problem is that you are in a conflicted state that must be manually resolved. I think that the point is that file 'foo' has already been merged, regardless of the conflict in file 'bar'. There is no way for you to revert to the pre-update state. In git, your previous commit still exists in the objects store even if it is no longer connected to the tree. And garbage collection won't even clean it out right away because it is still in the reflog ('git reflog'). The point being that once something is committed, it's permanently (barring garbage collection) in the repository. Whenever you make a change to a commit, a new commit is created, some pointers are changed, and the old commit still remains in the repository. > Oh, and somename is never tab-completed but othername is. Responsibility for the tab-completion falls squarely on your shell (or where ever you got the tab-completion setup from). Don't point your finger at git and say, "git sucks because bash tab-completion screwed me up." Neither rm nor git can control how your shell bothers to determine tab-completion.
- MikeTaylor 16y ago
  Still, it can't be right that "get checkout foo" does one of two COMPLETELY different things depending on whether or not there is a file called foo in the current directory. Surely one of those two commands should have a different name.
  - thenduks 16y ago
    I've always felt like `git branch` could be the one to switch branches (since it's used to create them too). But `git checkout -b` also creates branches... I think semantically checkout is the right command for this. It's never come up as a problem because I tend to know what files are in my project and I also tend to know what it is I'm about to/want to do. I very rarely switch branches with a dirty working copy anyway and my branches are never named even remotely close to what files are named (by coincidence, I suppose, but I name branches after: 'releases' which have names like "2.2.2"; 'bug fixes' which have names like "bug2598" or 'features' which have names like "dashboard-rewrite" and "chunk-load-thumbnails").

pyre 16y ago

> You didn't lose any data in that scenario. Every line of code you wrote still exists in those files. The problem is that you are in a conflicted state that must be manually resolved. I think that the point is that file 'foo' has already been merged, regardless of the conflict in file 'bar'. There is no way for you to revert to the pre-update state. In git, your previous commit still exists in the objects store even if it is no longer connected to the tree. And garbage collection won't even clean it out right away because it is still in the reflog ('git reflog'). The point being that once something is committed, it's permanently (barring garbage collection) in the repository. Whenever you make a change to a commit, a new commit is created, some pointers are changed, and the old commit still remains in the repository. > Oh, and somename is never tab-completed but othername is. Responsibility for the tab-completion falls squarely on your shell (or where ever you got the tab-completion setup from). Don't point your finger at git and say, "git sucks because bash tab-completion screwed me up." Neither rm nor git can control how your shell bothers to determine tab-completion.

MikeTaylor 16y ago
Still, it can't be right that "get checkout foo" does one of two COMPLETELY different things depending on whether or not there is a file called foo in the current directory. Surely one of those two commands should have a different name.
- thenduks 16y ago
  I've always felt like `git branch` could be the one to switch branches (since it's used to create them too). But `git checkout -b` also creates branches... I think semantically checkout is the right command for this. It's never come up as a problem because I tend to know what files are in my project and I also tend to know what it is I'm about to/want to do. I very rarely switch branches with a dirty working copy anyway and my branches are never named even remotely close to what files are named (by coincidence, I suppose, but I name branches after: 'releases' which have names like "2.2.2"; 'bug fixes' which have names like "bug2598" or 'features' which have names like "dashboard-rewrite" and "chunk-load-thumbnails").