4 ms·

You don't need -- as much in the "git restore" example. With git checkout it may be necessary to separate the branch and the paths with "--" but since "git rest

You don't need -- as much in the "git restore" example. With git checkout it may be necessary to separate the branch and the paths with "--" but since "git restore" does not take a branch (except with -s), doing this is totally fine git restore test.txt

411111111111111 5y ago
It's usually not necessary for checkout either
- yakubin 5y ago
  Not typing it with "checkout" gets in the way of good tab completion. At work we have at least tens of thousands of branches and if I hit tab after "git checkout file_path_prefix", my shell is going to freeze for a while, while tab completion is going over remote branches.
  - Freak_NL 5y ago
    How do you end up with that many branches? It sounds like you keep every feature branch around forever. Keeping one around for a few months I get (although personally the sooner they're gone after rebasing or cherry-picking them the better), but this sounds like a full on history of every branch ever.
    - yakubin 5y ago
      If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something. (Every non-official build is made from a separate branch.)
      - Freak_NL 5y ago
        Deployed versions that need to be referred to later usually get git tagged, but those are not that much different from branches of course (they'll both show up in autocomplete as a committish object). But even then; tens of thousands of tags/branches? At that point it might be worth considering simply baking in the git commit hash into the build artefact for future reference instead of tagging every CI build with a branch/tag.
        yakubin 5y ago
        When I say "non-official", I say that it has some commits that aren't on the main branch. You need to push them somewhere, or else they're going to be lost.
      - samatman 5y ago
        You may not have much choice in the matter, but this level of complexity is where I would strongly recommend a (slightly) more complex architecture. It's apparently a business requirement to keep every branch around forever, and I'll just take your word for that. At that point, you can have an `origin` remote where work happens, and the CI can include a push to an `archive` remote which is append-only. Lets you have a development environment where the existence of a branch on origin means that it's in-play, and everything exists on archive if it proves needful.
      - danw1979 5y ago
        tags might be a more suitable way of... tagging those releases for future reference ?
        yakubin 5y ago
        https://news.ycombinator.com/item?id=28025573 https://news.ycombinator.com/item?id=28025573
  - deleted 5y ago
    [deleted]
- scotty79 5y ago
  What does -- do exactly?
  - bicolao 5y ago
    -- in git is usually used to mark the end of options. After --. --foo means an argument --foo, not the option --foo. Git checkout and a few other commands also use it to separate branch and the rest of paths, because you could specify like this git checkout branch path1 path2 git checkout path1 path2 git checkout branch # what if there's a file named "branch"? -- help disambiguates that by being between the branch and the paths, so git checkout branch -- # always checkout a branch git checkout -- path1 path2 # always checkout paths git checkout branch -- path1 path2 # same, but disable disambiguation logic
    - MawKKe 5y ago
      it is used for that purpose in many other tools as well (grep, for example)
greatgib 5y ago
Thank you very much for this info. From the article, I was thinking that it was again a stupid confusing design for the cli to requires the -- even with a dedicated command. One main issue with git is to not be consistent and logic with the comments. Always to use different way or option abbreviation for different command. For example having a space or a slash between repo and a branch in a command.
- chungy 5y ago
  -- is typically to end argument processing and to treat all further ones as files. With git-restore, it's probably only relevant if you happen to have files in your repo that begin with hyphens. A fairly unusual situation, granted, but not forbidden.
  - greatgib 5y ago
    Still does not really make sense. Because you can still quote the - if ever you had such a file, and most Unix tools have the -- optional only if you would need it. Not systematic!
    - chungy 5y ago
      How would you quote it, exactly? You have to remember that quotation marks are processed by the shell, not the program. ls -file ls "-file" Both of these commands to ls will have an argv comprised of: ls, -file
- Denvercoder9 5y ago
  > For example having a space or a slash between repo and a branch in a command. Actually, this one makes sense, once you understand the underlying model of how git works with remote repositories, which (imo) is fairly fundamental to a distributed VCS. They're different arguments (in your words, having a space) when you're accessing remote repositories and have to specify the location it should access. You can always substitute an URL for a repo in this case, and they fail if you cannot connect to the remote repository. In all other cases (having a slash), you're referencing a ref in your local repository. This is a local copy of the remote repository. That means that it always works offline, but also that it doesn't sync with the remote repository. You can also substitute another ref, such as a "local" branch.

411111111111111 5y ago

It's usually not necessary for checkout either

yakubin 5y ago
Not typing it with "checkout" gets in the way of good tab completion. At work we have at least tens of thousands of branches and if I hit tab after "git checkout file_path_prefix", my shell is going to freeze for a while, while tab completion is going over remote branches.
- Freak_NL 5y ago
  How do you end up with that many branches? It sounds like you keep every feature branch around forever. Keeping one around for a few months I get (although personally the sooner they're gone after rebasing or cherry-picking them the better), but this sounds like a full on history of every branch ever.
  - yakubin 5y ago
    If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something. (Every non-official build is made from a separate branch.)
    - Freak_NL 5y ago
      Deployed versions that need to be referred to later usually get git tagged, but those are not that much different from branches of course (they'll both show up in autocomplete as a committish object). But even then; tens of thousands of tags/branches? At that point it might be worth considering simply baking in the git commit hash into the build artefact for future reference instead of tagging every CI build with a branch/tag.
      - yakubin 5y ago
        When I say "non-official", I say that it has some commits that aren't on the main branch. You need to push them somewhere, or else they're going to be lost.
    - samatman 5y ago
      You may not have much choice in the matter, but this level of complexity is where I would strongly recommend a (slightly) more complex architecture. It's apparently a business requirement to keep every branch around forever, and I'll just take your word for that. At that point, you can have an `origin` remote where work happens, and the CI can include a push to an `archive` remote which is append-only. Lets you have a development environment where the existence of a branch on origin means that it's in-play, and everything exists on archive if it proves needful.
    - danw1979 5y ago
      tags might be a more suitable way of... tagging those releases for future reference ?
      - yakubin 5y ago
        https://news.ycombinator.com/item?id=28025573 https://news.ycombinator.com/item?id=28025573
- deleted 5y ago
  [deleted]
scotty79 5y ago
What does -- do exactly?
- bicolao 5y ago
  -- in git is usually used to mark the end of options. After --. --foo means an argument --foo, not the option --foo. Git checkout and a few other commands also use it to separate branch and the rest of paths, because you could specify like this git checkout branch path1 path2 git checkout path1 path2 git checkout branch # what if there's a file named "branch"? -- help disambiguates that by being between the branch and the paths, so git checkout branch -- # always checkout a branch git checkout -- path1 path2 # always checkout paths git checkout branch -- path1 path2 # same, but disable disambiguation logic
  - MawKKe 5y ago
    it is used for that purpose in many other tools as well (grep, for example)

greatgib 5y ago

Thank you very much for this info. From the article, I was thinking that it was again a stupid confusing design for the cli to requires the -- even with a dedicated command. One main issue with git is to not be consistent and logic with the comments. Always to use different way or option abbreviation for different command. For example having a space or a slash between repo and a branch in a command.

chungy 5y ago
-- is typically to end argument processing and to treat all further ones as files. With git-restore, it's probably only relevant if you happen to have files in your repo that begin with hyphens. A fairly unusual situation, granted, but not forbidden.
- greatgib 5y ago
  Still does not really make sense. Because you can still quote the - if ever you had such a file, and most Unix tools have the -- optional only if you would need it. Not systematic!
  - chungy 5y ago
    How would you quote it, exactly? You have to remember that quotation marks are processed by the shell, not the program. ls -file ls "-file" Both of these commands to ls will have an argv comprised of: ls, -file
Denvercoder9 5y ago
> For example having a space or a slash between repo and a branch in a command. Actually, this one makes sense, once you understand the underlying model of how git works with remote repositories, which (imo) is fairly fundamental to a distributed VCS. They're different arguments (in your words, having a space) when you're accessing remote repositories and have to specify the location it should access. You can always substitute an URL for a repo in this case, and they fail if you cannot connect to the remote repository. In all other cases (having a slash), you're referencing a ref in your local repository. This is a local copy of the remote repository. That means that it always works offline, but also that it doesn't sync with the remote repository. You can also substitute another ref, such as a "local" branch.