3 ms·

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 dedi

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.
- planb 5y ago
  Thank you . I guess this is obvious, but I never thought about it and was never sure when to use which one. Now it makes sense.
- greatgib 5y ago
  I think you give a general explanation of what you would like the reason to be but it does not match the commands: git fetch origin main git rebase -i origin/main Git push origin localBranch:remoteBranch For example, why not: git push origin/remoteBranch localBranch (And if you want to preserve saying that slash is just for local, you could say: origin:remoteBranch)

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.

planb 5y ago
Thank you . I guess this is obvious, but I never thought about it and was never sure when to use which one. Now it makes sense.
greatgib 5y ago
I think you give a general explanation of what you would like the reason to be but it does not match the commands: git fetch origin main git rebase -i origin/main Git push origin localBranch:remoteBranch For example, why not: git push origin/remoteBranch localBranch (And if you want to preserve saying that slash is just for local, you could say: origin:remoteBranch)