Sam, is there a difference between
git push --set-upstream origin master
git push -u origin master
personally I always used the first one like in the video but on GitHub, after creating a repo they are suggesting the second one
There is no difference at all no—in fact
-u is just shorthand for
To see this you can get help on the push command:
$ git push --help
Here, you’ll see that they are synonyms:
git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
[-u | --set-upstream] [--push-option=<string>]
[--no-verify] [<repository> [<refspec>...]]
and if you scroll down:
For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-
pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1).
That’s good to know - and tells us how to interpret that otherwise cryptic -u in the help. perhaps you discuss help details in later sessions. I’ve already noted that you can shorten options to the lowest number of chars that makes the option unambiguous, but you don’t seem to be able to shorten git command verbs. Sounds like git aliases will be useful.
One minor addition: when you sign in with your name and password for the initial push it apparently sudo’s you for an hour so you have to wait to use the token. Seems like you’d want to be able to logout of sudo on occasion. I tried just logging out on the github website but that didn’t cause the next push to prompt me again. Is there ever a practical need to cancel sudo (to login as a different user perhaps? ) Is there a simple way to do that?
Although I don’t discuss
git help in the next course, there is a video on aliases—hopefully that’ll be helpful to you.
I’m a little confused about what you mean about sudo and being unable to use the token? I’ll confess that I’ve always used git-over-ssh and only switched to https for this series, since that’s what GitHub recommends.
Basically, I copied the video and did the first push, and entered my name and pwd when prompted. At that point(as best as I can remember) the successful response said something like “we’ve sudo’d you you for an hour.” I then created a token as you had done and did the second push. You got a second prompt and were able to enter your token. I didn’t get any prompt. In hindsight I don’t think it had anything to do with sudo - I can still push a day later. I guess OS X automatically entered my pwd credentials from the keychain. I thought I had done exactly what you had, but had you done something like removing github from your keychain so that you were prompted the second time and could thus enter the token instead of a pwd?
Ah—apologies—now I understand.
The only reason I had to create a token in GitHub was because I use 2-factor-authentication with GitHub. That means that when I log in to GitHub on the web, I have to use a one-time-password. Therefore, when I login with git at the command line, I have to use that specially-generated token (sometimes called an app-specific password).
If you don’t use 2FA, then you can use your GitHub password at the command line, and won’t need to generate the token.
You’re correct that it has nothing to do with sudo mode on GitHub—that just means that you can make changes to your GitHub account without it repeatedly asking for your password.
Hope that clears it up for you you
Amazing series Sam, just one question there is an important difference between “git commit” and “git commit -m “commentary””?
Thanks in advance.
@sam_vp @samdavies Can you please help with this when you get a chance? Thank you - much appreciated! :]
Glad you enjoyed the series—I hope it’ll be useful to you in the future.
-m flag allows you to provide the commit message on the command line, so
$ commit -m "commentary"
immediately commits the staged changes, with a commit message of
-m flag, git will open your text editor after you execute the
git commit command so that you can construct your message.
Generally, I think it’s better to not use the
-m flag, as this allows you to construct a more in-depth commit message. However, I used
-m extensively in the course as it makes the teaching flow simpler.
Hope that answers your question
Thank you so much @samdavies That definitely helps a lot, I’ll keep in this course and then to the advanced techniques because your way to teach is great