"Updating Master to Reflect Trunk" - (ignoring the "trunk" misnomer, that's been addressed by other comments). I've recently started taking a step to make this relatively unnecessary. I delete my local master branch. It has made my workflow a lot cleaner!
(a) I never accidentally work on master anymore.
(b) I never have to switch to master to pull the latest from the remote.
(c) One less thing to keep in sync and clutter my repo.
Basically, I can now just do `git fetch origin` periodically to get updates from the remote, and then anytime I want to rebase or make a new branch or whatever, I refer to origin/master instead of master. And you can always `git checkout origin/master` if you want. It's the best!
Isn't it more reasonable to say "never work on master if you're collaborating". If I use Git to manage a single script that only I work on, I don't see the need to create a branch.
If you use "git rebase -i" a lot, you should give the "autosquash" option a try. Basically, it enables "commit --fixup <commit>" that will display the commits in the correct order the next time you rebase. (A bit hard to explain, sorry)
Personally it seems faster to work with the rebate -i todo list than to search the log for a commit message retype it with "fixup,". And hope I got the message right.
Trunk is normally called origin in git nomenclature.
git push -f needs a big red box round it, not as a normal thing to do.
If you want to fix a pushed commit, do a new commit! If you keep pushing dodgy commits, try waiting between committing and pushing, or get better at reviewing your changes.
Trunk is normally called origin in git nomenclature.
Pedantically, when you refer to "origin", you're referring to the default branch for the remote named "origin" (i.e. the branch referred to by refs/remotes/origin/HEAD after cloning).
This is typically master, but not necessarily. In fact, you can update refs/remotes/origin/HEAD to point to any branch under refs/remotes/origin via "git remote set-head". (It's also possible that the remote repo's HEAD was something other than master when you cloned.)
If you want to be explicit, use origin/master, or refs/remotes/origin/master to be more explicit still.
The same applies for other remotes you may have configured in the same repo.
A related concept is the @{u}/@{upstream} token. Git resolves this token from the currently checked-out branch's configuration. e.g., if master is checked out (i.e. HEAD is refs/heads/master), git checks in .git/config for branch.master.remote and branch.master.merge and uses those to determine the upstream branch. In this example, those would typically be branch.master.remote=origin and branch.master.merge=refs/heads/master, which git resolves to refs/remotes/origin/master.
Finally, @{upstream} can be configured via git branch --set-upstream-to=... (in older versions of git the more confusing and now deprecated --set-upstream was used).
Thanks for the comments Richard. Since Github uses origin as user's fork of the project, I was trying to distinguish the project's main repository and the user's fork. Admittedly, after seeing comments from other people, trunk probably isn't the best name for it.
Agreed, git push -f has caused a lot of grief because of git newbies. So in my workplace its considered a cardinal sin except under some special circumstances. It needs a really big RED box around it.
"If you fork a repository on Github, clone the repository with the ssh link. Otherwise, you will have to authenticate with Github each time you push a branch."
That's false. The credentials are cached after the first time you type them in, provided you are using a new enough version of Git ( >= 1.8.3 I believe).
Not necessarily for 'Interested in Open Source', seems like tips to anyone who isn't using a repo alone.
I don't get it the part 'Updating Master to Reflect Trunk'. What is trunk? I remember trunk from the SVN days (trunk, tag, branches) but nowadays with git I don't see this terminology anymore. Comparing to SVN trunk is the master branch. Maybe I missed something, but I don't get it this trunk remote.
Also I would put a more flashy warning on amending something that is already pushed.
Using rebase relative to HEAD can be tricky, and as others have mentioned, force pushing a branch is not usually a good idea.
When you are ready to submit a pull request, instead of rebasing the branch you have already pushed to origin, create a new branch called your_branch_name-final (I usually call the original branch -wip for for work in progress). Then, before pushing this branch to origin, run git rebase -i upstream/master.
I wish he would add one more since he mentioned github - don't fork unless you actually need to. I see way too many forks of projects on github with no significant changes. If you have a bug fix make it on the same repo and then submit a pull request with your changes. Forks are for adding new features, making major changes, or if the original author is no longer maintaining the project.
"Otherwise, you will have to authenticate with Github each time you push a branch."
It is possible to easily automate HTTP authentication in git by including the credentials on a .netrc file in your home directory. It should look something like:
Whenever I'm working on an OS project and I happen to open a file with white space or unnecessary blank lines, I delete them and send them the changes with my PR. Highly suggest it.
It annoys me too. If you do a git diff against the sha1 of a completely empty tree, you can see all of the whitespace errors that have been checked into a repository:
$ git diff --check $(git hash-object -t tree /dev/null)
...although many projects frown upon whitespace-only commits since they screw with `git blame`.
[+] [-] sandyarmstrong|12 years ago|reply
"Updating Master to Reflect Trunk" - (ignoring the "trunk" misnomer, that's been addressed by other comments). I've recently started taking a step to make this relatively unnecessary. I delete my local master branch. It has made my workflow a lot cleaner!
(a) I never accidentally work on master anymore.
(b) I never have to switch to master to pull the latest from the remote.
(c) One less thing to keep in sync and clutter my repo.
Basically, I can now just do `git fetch origin` periodically to get updates from the remote, and then anytime I want to rebase or make a new branch or whatever, I refer to origin/master instead of master. And you can always `git checkout origin/master` if you want. It's the best!
[+] [-] vsbuffalo|12 years ago|reply
[+] [-] agumonkey|12 years ago|reply
[+] [-] emillon|12 years ago|reply
[+] [-] ollysb|12 years ago|reply
[1] https://coderwall.com/p/hh-4ea
[+] [-] DigitalJack|12 years ago|reply
[+] [-] richardwhiuk|12 years ago|reply
git push -f needs a big red box round it, not as a normal thing to do.
If you want to fix a pushed commit, do a new commit! If you keep pushing dodgy commits, try waiting between committing and pushing, or get better at reviewing your changes.
[+] [-] js2|12 years ago|reply
Pedantically, when you refer to "origin", you're referring to the default branch for the remote named "origin" (i.e. the branch referred to by refs/remotes/origin/HEAD after cloning).
This is typically master, but not necessarily. In fact, you can update refs/remotes/origin/HEAD to point to any branch under refs/remotes/origin via "git remote set-head". (It's also possible that the remote repo's HEAD was something other than master when you cloned.)
If you want to be explicit, use origin/master, or refs/remotes/origin/master to be more explicit still.
The same applies for other remotes you may have configured in the same repo.
A related concept is the @{u}/@{upstream} token. Git resolves this token from the currently checked-out branch's configuration. e.g., if master is checked out (i.e. HEAD is refs/heads/master), git checks in .git/config for branch.master.remote and branch.master.merge and uses those to determine the upstream branch. In this example, those would typically be branch.master.remote=origin and branch.master.merge=refs/heads/master, which git resolves to refs/remotes/origin/master.
Finally, @{upstream} can be configured via git branch --set-upstream-to=... (in older versions of git the more confusing and now deprecated --set-upstream was used).
[+] [-] markberger|12 years ago|reply
[+] [-] mataug|12 years ago|reply
[+] [-] culp|12 years ago|reply
[+] [-] alessioalex|12 years ago|reply
That's false. The credentials are cached after the first time you type them in, provided you are using a new enough version of Git ( >= 1.8.3 I believe).
[+] [-] talles|12 years ago|reply
I don't get it the part 'Updating Master to Reflect Trunk'. What is trunk? I remember trunk from the SVN days (trunk, tag, branches) but nowadays with git I don't see this terminology anymore. Comparing to SVN trunk is the master branch. Maybe I missed something, but I don't get it this trunk remote.
Also I would put a more flashy warning on amending something that is already pushed.
[+] [-] jtreminio|12 years ago|reply
There's a slight difference, I think. Overtime his/her mind will change to get Git better.
[+] [-] oilytheotter|12 years ago|reply
When you are ready to submit a pull request, instead of rebasing the branch you have already pushed to origin, create a new branch called your_branch_name-final (I usually call the original branch -wip for for work in progress). Then, before pushing this branch to origin, run git rebase -i upstream/master.
[+] [-] ianstallings|12 years ago|reply
[+] [-] jedbrown|12 years ago|reply
This is one way in which 'git send-email' is lighter weight and more convenient, provided all involved know how to use it.
[+] [-] aikinai|12 years ago|reply
It is possible to easily automate HTTP authentication in git by including the credentials on a .netrc file in your home directory. It should look something like:
machine example.com login username_here password password_here
Of course it's unfortunate that you have to have your password in plain text, but it works.
[+] [-] bradleyland|12 years ago|reply
1) No password stored in plain text
2) Still secure without having to enter your password every time
[+] [-] duggieawesome|12 years ago|reply
Whenever I'm working on an OS project and I happen to open a file with white space or unnecessary blank lines, I delete them and send them the changes with my PR. Highly suggest it.
[+] [-] elasticdog|12 years ago|reply