Hi folks,
During the last weeks I merged a couple of pull requests into geany-plugins. During this work I found it a bit annoying not finding a easy way to pull the pull request directly and test it locally and maybe add it to me git repo. Is there any direct way on doing this instead of going to offerer's github page and clone the complete repo?
Cheers, Frank
On 31/12/2011 17:31, Frank Lanitz wrote:
Hi folks,
During the last weeks I merged a couple of pull requests into geany-plugins. During this work I found it a bit annoying not finding a easy way to pull the pull request directly and test it locally and maybe add it to me git repo. Is there any direct way on doing this instead of going to offerer's github page and clone the complete repo?
$ git remote add -f foo git://github.com/foo/geany-plugins.git $ git merge foo/master
How about that?
On Sat, Dec 31, 2011 at 9:04 PM, Chow Loong Jin hyperair@ubuntu.com wrote:
On 31/12/2011 17:31, Frank Lanitz wrote:
Hi folks,
During the last weeks I merged a couple of pull requests into geany-plugins. During this work I found it a bit annoying not finding a easy way to pull the pull request directly and test it locally and maybe add it to me git repo. Is there any direct way on doing this instead of going to offerer's github page and clone the complete repo?
$ git remote add -f foo git://github.com/foo/geany-plugins.git $ git merge foo/master
Hi Frank,
When you get pull requests from lots of people adding each of them as a remote can be tedious.
Instead github docs suggest using the patch file as input to git am, see far down on the page on sending pull requests.
Cheers Lex
On 12/31/2011 01:31 AM, Frank Lanitz wrote:
Hi folks,
During the last weeks I merged a couple of pull requests into geany-plugins. During this work I found it a bit annoying not finding a easy way to pull the pull request directly and test it locally and maybe add it to me git repo. Is there any direct way on doing this instead of going to offerer's github page and clone the complete repo?
I'm going to take a few minutes to go through it in order to document, in exchange *YOU must post this on the Wiki* (after testing) :)
Ok, you have your "official" `geany-plugins` repository from doing:
$ git clone git@github.com:geany/geany-plugins.git $ cd geany-plugins/
Then say you want to check out pull request #7[1], it's from user `cushy007` on his/her fork, so:
$ git remote add -f \ cushy007 https://github.com/cushy007/geany-plugins.git
Now you have their remote and have fetched their branches (I think). Then, in this case the requester is working straight on the `master` branch (tsk tsk), so you need to pull it into a different local branch, so maybe:
$ git checkout --track -b cushy007-master cushy007/master
Which says "checkout a new branch named `cushy007-master` from the remote `cushy007` and branch `master` and track it.
Now you can try out the changes and make some fixes, maybe with new commits. If it's out of date with the main `master` branch, you can rebase it on top (which will probably make the Pull Request feature not realize you've "accepted" the pull request on Github):
$ git rebase master [hopefully not fix conflicts]
But this will change the history compared to the Pull Requester's history, so ideally you will not do this and worst case there will be a merge commit (I don't really understand this but it seems to be how it works).
Then get back to the main `master` branch when you're done and merge this Pull Request in:
$ git checkout master $ git merge cushy007-master
Sometimes if the pull request is not really usable, like the author is not specified, or there's lots of noise, you can just pull in their branch as above, and then switch to the master branch and cherry pick their specific commit:
$ git checkout master $ git cherry-pick e6a41b574fdbed04fc5c582d90b26d8d727898dd
Which will strip that commit out of their branch and apply it to master (ideally). Then if you need to set the author properly or make changes, you can just do:
[make changes] $ git commit --amend --author "Real Proper Author auth@email.org"
Which will again probably clobber their history, but they should've made a better patch :)
Then just push it as normal to the main repository:
$ git push origin master
Finally, go to Github to see if the Pull Request was automatically closed or whether you should close it manually, noting any applicable commits in the comments.
At the end, if you don't think you'll use `cushy007`'s remote any more, you can remove it (though it doesn't hurt to leave it):
$ git remote rm cushy007
P.S. I'm not a Git master, I just kind of walked through this while writing and using my few experiences with pull requests, so it's probably not 100% the best way.
Cheers, Matthew Brush
Am 31.12.2011 13:03, schrieb Matthew Brush:
Now you can try out the changes and make some fixes, maybe with new commits. If it's out of date with the main `master` branch, you can rebase it on top (which will probably make the Pull Request feature not realize you've "accepted" the pull request on Github):
$ git rebase master [hopefully not fix conflicts]
Please, DO NOT EVER rebase other people's work if you're going to push it into the main repo. It breaks their history and thus all of their clones. And it probably, as mentioned, breaks github pull request handling as well.
FWIW, you can also pull directly into master by doing "git pull cushy007/master" when you're on master.
Instead, merge or ask the requester to update his pull request.
See: https://lwn.net/Articles/328436/
Best regards.
On 12/31/2011 05:45 AM, Thomas Martitz wrote:
Am 31.12.2011 13:03, schrieb Matthew Brush:
Now you can try out the changes and make some fixes, maybe with new commits. If it's out of date with the main `master` branch, you can rebase it on top (which will probably make the Pull Request feature not realize you've "accepted" the pull request on Github):
$ git rebase master [hopefully not fix conflicts]
Please, DO NOT EVER rebase other people's work if you're going to push it into the main repo. It breaks their history and thus all of their clones. And it probably, as mentioned, breaks github pull request handling as well.
If they're working on a topic branch (which they should be), once their topical changes are committed to master, they have only to do:
$ git branch -D my_pull_requested_branch $ git pull origin master # to get the "real" new changes
And they still get attribution and the history isn't littered with sloppy commits :)
I could be mistaken though, like I said, not a Git expert.
Cheers, Matthew Brush
Hi,
Le 31/12/2011 14:45, Thomas Martitz a écrit :
Am 31.12.2011 13:03, schrieb Matthew Brush:
Now you can try out the changes and make some fixes, maybe with new commits. If it's out of date with the main `master` branch, you can rebase it on top (which will probably make the Pull Request feature not realize you've "accepted" the pull request on Github):
$ git rebase master [hopefully not fix conflicts]
Please, DO NOT EVER rebase other people's work if you're going to push it into the main repo. It breaks their history and thus all of their clones. And it probably, as mentioned, breaks github pull request handling as well.
ppl should NEVER send work on the forked project's master if they don't want to get into troubles with such things. It's not the upstream work to take care not to mess *forks'* histories. If you mess up on a fork's master and plan to keep it up-to-date, be prepared to get ugly and even hard-to-deal-with merges.
Anyway if you work on the master branch, it'll never be in *real* sync with upstream (e.g. there will be at least some merge commits) so it will be a pain for user to track both anyways.
So again, IMHO the upstream should not care about what the forked repo will have to do post-apply and only do what it thinks is the best for them -- which can include merging and rebasing.
FWIW, you can also pull directly into master by doing "git pull cushy007/master" when you're on master.
Instead, merge or ask the requester to update his pull request.
I'll try to read this, thanks for the link. (Though, yet I haven't read the article, it looks like Linus opinion on how Linux fork should be managed for it to pull them, which may or may not apply to everyone)
Cheers, Colomban
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 31 Dec 2011 04:03:56 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
I'm going to take a few minutes to go through it in order to document, in exchange *YOU must post this on the Wiki* (after testing) :)
I started testing and really seems to work well. Will add it to wiki upcoming days. Today I wont write documentation as its New Year's Day ... ;D
Cheers, Frank