Closed xaosfiftytwo closed 8 years ago
Yes; it generates a fair number of merge commits, which are kind of annoying. Rebasing on master before merging should get rid out that:
git checkout $branch
git rebase master
git checkout master
git merge --ff-only $branch
I like getting the PR notifications in the event stream though :)
Sorry, guys. I am still a bit shakey on using git. Will do what you advised in future.
I wasn't concerned with the merge commits; to me a PR means discussion. When you merge your PR straight away, this kind of defeats the purpose of opening it in the first place.
Agreed, Jente. Learned my lesson. Won't merge a PR immediately in future. This begs the question 'How long to wait for a reaction?'
I think a few days is reasonable.
I was wondering about this myself, being new to GitHub, and dev workflow in general. Your saying that updating your own repo with a commit can be done without discussion. It's logged, so anyone can file an issue after that.
A Pull Request is different, your asking for your updates to be added to someone else's repo. Is that right, more or less?
^ This PR crap is a Github invention anyway (or seems so). The classical case would be to post a bunch of patches to a mailing list and ask for them to be merged. If you have commit access to the repo, you normally wouldn't do that unless you'd prefer to hear some feedback on the change first.
Just don't force-push:
git push --force
and everything stays fixable.
@2ion, Don't package bunsen-utilities version 8.6.6-1 yet (should you feel inclined to) Just noticed that my code refactoring of bl-exit left out the possibility to call bl-exit from the command line, or from a menu with command-line options --logout, --suspend, etc...
Will let you know when it is corrected.
What is the point of creating pull requests if you merge them right away?