[Geany-devel] Just another github question: Easy way to pull pull reuqest for testing purposes?
lists.ban at xxxxx
Sat Dec 31 14:23:22 UTC 2011
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.
> See: https://lwn.net/Articles/328436/
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)
> Best regards.
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel