5 ms·

There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine.

There is no doubt that a bunch of the general commands are really poorly named, or mixed together. `git checkout branch` means switch to a branch - that's fine. But `git checkout filename` means "undo changes to the file". What? That's totally insane. `git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you use `git checkout -b new-branch-name`. Yes, a third separate use for git checkout. Why not (e.g.) `git branch -c new-branch-name` with a config option to make `-c` the default if you want it? If you rebase and push, it tells you to do a `git pull` to "fix" it, when in every workflow I've ever done, you want to add a `-f` and push away, just be aware that you are intentionally overwriting the remote branch.

npteljes 5y ago
And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.
- u801e 5y ago
  Are you referring to the git branch command? As far as I'm aware, you don't have to specify the name of the remote branch when creating a new local branch. And when you push to the remote, a branch with the same name is created by default. You would have to specify the remote branch name when running git push if you wanted a different name for the remote branch.
  - npteljes 5y ago
    My env doesn't do this. Here's what I did: git checkout -b test git push And I got "fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test" But in this situation, we actually push with "git push -u origin branchname". After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a push, and I got the same error message.
    - u801e 5y ago
      Have you tried running: git push origin HEAD In both Github and Github Enterprise, that command will create a branch with the same name on the remote.
      - npteljes 5y ago
        Works like a charm, thanks!
    - CRConrad 5y ago
      AIUI the problem there wasn't with the branch name, but that the "-origin" bit -- the reference for where to push to / pull from -- was missing. The -u parameter someone else suggested apparently sets that at the same time as pushing/pulling, so it combines the effect of "--set-upstream" suggested in the error message you got and then push/pull. (A bit like "checkout -b newbranchname" combines creating and then switching to a branch; there is some consistency to the UI, but it's weird and spotty.) I've almost never had this problem; nearly all branches I've come across usually "know all by themselves" where their remote is. I suspect they inherit it from a global or repository-level setting that might be missing from your setup. Have you tried executing that "--set-upstream" it suggests? Maybe that sets it for the whole repo, or have you had to repeat it for each branch (like the "-u" parameter for the push seems to imply)? Or maybe, even if you have the remote set correctly on the repo level, branches just somehow don't "inherit" that...? Idunno, maybe some magic setting missing. Aha, one further possibility: If you set the remote on the "master" (or "main") branch, maybe branches branched off from that (and others branched off from those, etc) "inherit" the remote setting? Finally: Creating a git repo by cloning in stead of from scratch (git clone in stead of git init) automagically sets the remote for the master branch of the newly cloned repo to the master of the repo it was cloned from. Maybe, if this is how it works, that's why it's always worked for me: I've worked mainly with cloned repositories, and my branches are almost always -- albeit sometimes indirectly -- branched, ultimately, from "master". Anyway, I think somewhere among all that there should be something that fixes your problem once and for all (i.e. for all future branches once it's correctly set for a repo). I'm sure your problem isn't standard behaviour. HTH!
- deleted 5y ago
  [deleted]
- lmm 5y ago
  > And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that. You can fix this by doing `git config --global push.default current`.
RvdV 5y ago
New commands 'git switch' (git switch -c for new branch) and ' git restore' address exactly that issue and are available on newer git versions, so it's being worked on! I do agree with the second example. Pulling and merging with remote after a rebase makes a terrible mess!
cerved 5y ago
Git checkout branch means change the entire working tree to the reflect the state of the branch and git checkout file, checkout the state of that file in HEAD. Both commands to the same thing, change the state of your working tree to reflect a point checked into version control. It sounds like you are unaware of git switch branch and git switch -c new-branch
- Vinnl 5y ago
  Just a tip: when teaching people, the readable alias is easier to remember and understand, i.e. git switch --create new-branch
  - riquito 5y ago
    It was a good example: it was obvious by the name of the branch and he/she was teaching the real word use case
  - wstone 5y ago
    Thank you. It seems silly but my first parse was "-c(heckout)" but that comes from not using "switch" yet; I need to rewire my brain from "checkout".
mdaniel 5y ago
> But `git checkout filename` means "undo changes to the file". What? That's totally insane. Heh, and I'll do you one better: it's unstaged changes, so it won't put the file back to the HEAD version 100% of the time >:-)
ufo 5y ago
By the way, I recommend using `push --force-with-lease `instead of `push --force`. This way it doesn't destroy the remote changes if someone else pushed while you weren't looking.

npteljes 5y ago

And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that.

u801e 5y ago
Are you referring to the git branch command? As far as I'm aware, you don't have to specify the name of the remote branch when creating a new local branch. And when you push to the remote, a branch with the same name is created by default. You would have to specify the remote branch name when running git push if you wanted a different name for the remote branch.
- npteljes 5y ago
  My env doesn't do this. Here's what I did: git checkout -b test git push And I got "fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test" But in this situation, we actually push with "git push -u origin branchname". After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a push, and I got the same error message.
  - u801e 5y ago
    Have you tried running: git push origin HEAD In both Github and Github Enterprise, that command will create a branch with the same name on the remote.
    - npteljes 5y ago
      Works like a charm, thanks!
  - CRConrad 5y ago
    AIUI the problem there wasn't with the branch name, but that the "-origin" bit -- the reference for where to push to / pull from -- was missing. The -u parameter someone else suggested apparently sets that at the same time as pushing/pulling, so it combines the effect of "--set-upstream" suggested in the error message you got and then push/pull. (A bit like "checkout -b newbranchname" combines creating and then switching to a branch; there is some consistency to the UI, but it's weird and spotty.) I've almost never had this problem; nearly all branches I've come across usually "know all by themselves" where their remote is. I suspect they inherit it from a global or repository-level setting that might be missing from your setup. Have you tried executing that "--set-upstream" it suggests? Maybe that sets it for the whole repo, or have you had to repeat it for each branch (like the "-u" parameter for the push seems to imply)? Or maybe, even if you have the remote set correctly on the repo level, branches just somehow don't "inherit" that...? Idunno, maybe some magic setting missing. Aha, one further possibility: If you set the remote on the "master" (or "main") branch, maybe branches branched off from that (and others branched off from those, etc) "inherit" the remote setting? Finally: Creating a git repo by cloning in stead of from scratch (git clone in stead of git init) automagically sets the remote for the master branch of the newly cloned repo to the master of the repo it was cloned from. Maybe, if this is how it works, that's why it's always worked for me: I've worked mainly with cloned repositories, and my branches are almost always -- albeit sometimes indirectly -- branched, ultimately, from "master". Anyway, I think somewhere among all that there should be something that fixes your problem once and for all (i.e. for all future branches once it's correctly set for a repo). I'm sure your problem isn't standard behaviour. HTH!
deleted 5y ago
[deleted]
lmm 5y ago
> And if I create a new branch locally, why must I specify what name I'd use for it on the remote? Why would I like an other name I wonder? It's fantastic that it can do this, but the default should be the branch name I'm using and that's that. You can fix this by doing `git config --global push.default current`.

RvdV 5y ago

New commands 'git switch' (git switch -c for new branch) and ' git restore' address exactly that issue and are available on newer git versions, so it's being worked on! I do agree with the second example. Pulling and merging with remote after a rebase makes a terrible mess!

cerved 5y ago

Git checkout branch means change the entire working tree to the reflect the state of the branch and git checkout file, checkout the state of that file in HEAD. Both commands to the same thing, change the state of your working tree to reflect a point checked into version control. It sounds like you are unaware of git switch branch and git switch -c new-branch

Vinnl 5y ago
Just a tip: when teaching people, the readable alias is easier to remember and understand, i.e. git switch --create new-branch
- riquito 5y ago
  It was a good example: it was obvious by the name of the branch and he/she was teaching the real word use case
- wstone 5y ago
  Thank you. It seems silly but my first parse was "-c(heckout)" but that comes from not using "switch" yet; I need to rewire my brain from "checkout".

mdaniel 5y ago

> But `git checkout filename` means "undo changes to the file". What? That's totally insane. Heh, and I'll do you one better: it's unstaged changes, so it won't put the file back to the HEAD version 100% of the time >:-)

ufo 5y ago

By the way, I recommend using `push --force-with-lease `instead of `push --force`. This way it doesn't destroy the remote changes if someone else pushed while you weren't looking.