11–20 of 32 posts
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.
If you use "git rebase -i" a lot, you should give the "autosquash" option a try. Basically, it enables "commit --fixup " that will display the commits in the correct order the next time you rebase. (A bit hard to explain, sorry)
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.
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).
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.
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.
That way, when I pull from origin, I'm pulling from whatever the official origin repository is; when I pull from another named repo, it's named after whose repo it is.
It's also frequently the case that I've cloned from upstream before ever forking the repo on GitHub. It's only once I have any changes I need to make that I create a fork and add my own remote.
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.
"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!
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.
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.
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.
"Never Work on Master" - yes! "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…