7 ms·

> But I certainly wouldn't call the interface or syntax "inconsistent" or "random". Uhm, NO WAY. git checkout works on both branches and files. I can `checko

• vidar 15y ago
  Yeah, deleting a remote branch by "git push remote :branch" is pretty terrible, one colon between heaven and hell.
  • rjh29 15y ago
    If you understand how git push works, it sort of makes sense. But fortunately the devs added a --delete option to git push which is much more clear.
    • vidar 15y ago
      That is indeed clearer, thanks for the tip!
• djacobs 15y ago
  Git checkout is actually pretty consistent and only really works on branches. When you say it works on files, you actually mean it has a shorthand that works on files: git checkout my-file ... is actually using a lot of smart defaults. Namely, you're actually running ... git checkout HEAD -- my-file If you don't specify a branch or identifier, git uses HEAD by default in most cases. (When you run git diff other-branch, you're actually running git diff HEAD other-branch.) And the dash-dash syntax is mostly optional in modern git. Not inconsistent at all, as far as I can tell. In fact, most features of git that I use on a regular basis are completely consistent and orthogonal. The exceptions are submodules and remote cache branches...
  • gcb 15y ago
    So, in the end it worked on a file. :-)
    • djacobs 15y ago
      It worked on a branch, filtered by a file name. I think that's an important distinction. That distinction unifies the definition of `git checkout`.
      • adamc 15y ago
        But But it doesn't lead to an obvious, consistent command syntax, and that was the point.
        • djacobs 15y ago
          It's a consistent syntax with smart defaults you can leave out. You wouldn't say Unix's wc is inconsistent, would you, just because it has default behavior?
          • phillmv 15y ago
            Apples to Oranges. wc is a bad example. Better example is tar vs cp, where you go cp files you want to copy destination/ and tar destination.tar files you want to archive And yes, I would say that's inconsistent.
            • gcb 15y ago
              hum... both are wrong. wc is "word count" it's not a sane default. it's a obviously explicitly behavior. if git checkout were called 'git checkbranch' then you would have a point. tar does not have sane defaults. it requires explicit flags. your example (besides not working because as i said, it does not have defaults) could very well be `tar -c files you want to copy -f destination.tar` and all would be well. you actually still repeat the very first tar command line example you ever saw to this day, even not agreeing with it :)
• djacobs 15y ago
  It's surprisingly hard to unstage a file. Is there a case when it's not a simple git reset my-file away?
  • ajross 15y ago
    Indeed no. That's exactly what git reset does: "copy entries from <commit> to the index". I got that from the unusably bad man page. It was the first sentence.
    • djacobs 15y ago
      My question was a rhetorical one :)
      • ajross 15y ago
        I know. But you were needlessly agreeable. I thought some salt needed to be rubbed into the GP post.
    • _ikke_ 15y ago
      And in every git status message.
  • tspiteri 15y ago
    Yes there is. When you have a new repository without any commits, there is no HEAD, so you can't unstage by resetting. mkdir try cd try git init touch file git add file git status Still, the git status command shows you what you need to do to unstage.
  • phillmv 15y ago
    I forget my exact edge case. Something to do with wanting to unstage a folder, or unstaging a folder while wanting to preserve work in some of the files.
• andreyvit 15y ago
  > for someone who doesn't understand git internals Looks like that's the difference. As someone who does understand Git internals, everything seems perfectly logical and consistent to me. Perhaps it's the same with the person you are replying to. And really, using Git without understanding the internals is a suicide, quite a few people broke their repos and asked me to recover them. The internals are very easy to learn.
  • phillmv 15y ago
    No. I should not have to understand how git works internally in order for me to use it. This is called usability.
• pyre 15y ago
  > I can `checkout remote-name/branch` but I have to > `push remote-name branch` So I can use the same command in svn/cvs to switch branches and publish changes? > Deleting a local branch is `branch -D` but deleting a > remote branch is (I still can't fucking believe it) > `push remote :branch`. It's not that hard to understand. Most git commands only affect the local repo, but git-push and git-remote are used to affect the remote repo. It makes sense not to break that convention because some people feel it should be organized differently. In any case, writing to remote repos was never part of the core design of git. It was designed to be a distributed group of people that would pull down remote branches, make changes, and then submit pull requests to the code maintainer (or use the various 'email patch' commands). Remember that it was developed with Linux kernel development in mind, where there is a hierarchy of developers responsible for sections of the codebase.
  • phillmv 15y ago
    >So I can use the same command in svn/cvs to switch branches and publish changes? No, it's about the notation for remotes and branches. It's confusing that sometimes when I refer to a branch I call it remote/branch and other times I call it remote branch. It would've been way more consistent if it were always remote/branch. As a result, git push sometimes gets confusing. Suppose I'm on staging. I then say, git push heroku staging:master (push the staging branch to the master branch on heroku) whereas git push staging:heroku/master is imho easier to understand.
    • pyre 15y ago
      > git push heroku staging:master Without the shortcuts, this command would be: git push heroku refs/heads/staging:refs/heads/master "refs/heads/master" is literally the branch location in the $GIT_DIR on the remote. You could do something like: git push heroku staging:refs/personal/phillmv/staging to stick the branch in a non-standard location, or you could do: git push ssh://hostname/path/to/repo staging:staging or: git push ~pyre/work/repo staging:pillmv-staging to push to a location that you don't have specifically defined as a remote. E.g. % cd /tmp % mkdir test1 test2 % pushd test1 % git init . Initialized empty Git repository in /tmp/test1/.git/ % popd % pushd test2 % git init . Initialized empty Git repository in /tmp/test2/.git/ % git ci --allow-empty -m 'ini commit' [master (root-commit) 54ec2a3] ini commit % git push ../test1 master:test2-master Counting objects: 2, done. Writing objects: 100% (2/2), 168 bytes, done. Total 2 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (2/2), done. To ../test1 * [new branch] master -> test2-master