Hi folks,
See question from subject line. How can I merge a pull request without adding a new commit stating the merge? Is there some kind of ff or cherry-pick available through front end?
Cheers, Frank
Am 13.12.2011 09:24, schrieb Frank Lanitz:
Hi folks,
See question from subject line. How can I merge a pull request without adding a new commit stating the merge? Is there some kind of ff or cherry-pick available through front end?
Cheers, Frank
It'll automatically fast-forward if it's possible. For that, the branch should be rebased onto the branch you merge into.
However, don't rebase other people work yourself.
Best regards.
Can I be given a push access to the plugins repository? github user - cesspit
Regards, Alexander
On 12/15/11 2:41 PM, Frank Lanitz wrote:
Am 15.12.2011 10:46, schrieb Alexander Petukhov:
Can I be given a push access to the plugins repository? github user - cesspit
done.
Cheers, Frank
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Great, Thanks!
Regards, Alexander
See question from subject line. How can I merge a pull request without adding a new commit stating the merge? Is there some kind of ff or cherry-pick available through front end?
Hi,
You can't do a cherry pick or rebase through the front-end. I think adding this 'merge pull request' commit is a good idea, since it shows more information about where the commit came from.
But if you want, you can use 'git rebase' to avoid the merge commit. In the case of my 'gitignore' branch, you could have run the following commands:
git remote add ndbroadbent git:// github.com/ndbroadbent/geany-plugins.git git fetch ndbroadbent git rebase ndbroadbent/gitignore git remote rm ndbroadbent
Cheers, Nathan B
Am 13.12.2011 09:51, schrieb Nathan Broadbent:
See question from subject line. How can I merge a pull request without adding a new commit stating the merge? Is there some kind of ff or cherry-pick available through front end?
You can't do a cherry pick or rebase through the front-end. I think adding this 'merge pull request' commit is a good idea, since it shows more information about where the commit came from.
OK. So I assume its best practice also on github to do so?
But if you want, you can use 'git rebase' to avoid the merge commit. In the case of my 'gitignore' branch, you could have run the following commands:
git remote addndbroadbent git://github.com/ndbroadbent/geany-plugins.git http://github.com/ndbroadbent/geany-plugins.git git fetch ndbroadbent git rebase ndbroadbent/gitignore git remote rm ndbroadbent
Yepp. This I was aware of. Just wondeirng, wehther it can be done via github.
Cheers, Frank
You can't do a cherry pick or rebase through the front-end. I think adding this 'merge pull request' commit is a good idea, since it shows more information about where the commit came from.
OK. So I assume its best practice also on github to do so?
Yes, this is a best practice. It's also a best practice to add a 'merge' commit when merging in a feature branch, so that the branch's diversion is retained.
Github's network graph [1] and gitk [2] are great tools for viewing this history, and you shouldn't worry too much about making the history as 'linear' as possible.
[1] https://github.com/geany/geany-plugins/network [2] http://lwn.net/Articles/140350/
Best regards, Nathan B
Am 13.12.2011 10:33, schrieb Nathan Broadbent:
You can't do a cherry pick or rebase through the front-end. I think adding this 'merge pull request' commit is a good idea, since it shows more information about where the commit came from.
OK. So I assume its best practice also on github to do so?
Yes, this is a best practice. It's also a best practice to add a 'merge' commit when merging in a feature branch, so that the branch's diversion is retained.
Github's network graph [1] and gitk [2] are great tools for viewing this history, and you shouldn't worry too much about making the history as 'linear' as possible.
OK. got it ;) Just want to keep a clean line :D
And another question: Is github allowing to do an automatic rebase for forks? E.g. I have forked geany-plugins into my namespace https://github.com/frlan/geany-plugins and want to keep it up to date. Do I need to to it locally with git remote --add etc. or is there any gui for?
Cheers, Frank
And another question: Is github allowing to do an automatic rebase for forks? E.g. I have forked geany-plugins into my namespace https://github.com/frlan/geany-plugins and want to keep it up to date. Do I need to to it locally with git remote --add etc. or is there any gui for?
It's not possible to keep a fork up to date automatically. Any changes on your fork would start to produce merge conflicts that can't be resolved automatically. Also, there isn't too much benefit in having your own fork of the code, apart from having a place to store experimental branches that you don't want on the main repository. In that case, you should just delete the master branch from your fork and track the master branch from geany/geany-plugins.
Best regards, Nathan B
Le 13/12/2011 10:33, Nathan Broadbent a écrit :
You can't do a cherry pick or rebase through the front-end. I think adding this 'merge pull request' commit is a good idea, since it shows more information about where the commit came from.
OK. So I assume its best practice also on github to do so?
Yes, this is a best practice. It's also a best practice to add a 'merge' commit when merging in a feature branch, so that the branch's diversion is retained.
Github's network graph [1] and gitk [2] are great tools for viewing this history, and you shouldn't worry too much about making the history as 'linear' as possible.
While I agree that when there are more than one commit in a branch it shouldn't be rebased to keep the branch history, I don't agree when it's a single commit like [1] or even [2].
When it's a single commit, I think it only adds junk to the history, making it less readable. And I don't see what we gain with the merge message in such situations:
1) we don't care it was a GitHub pull request and not a format-patch; 2) the branch name shouldn't be required, the commit should be enough; 3) the patch contains authoring information anyway; 4) etc.
So IMHO it's better for single-commit patches (which should generally be quite small BTW) NOT to have the merge commit.
Regards, Colomban
[1] https://github.com/geany/geany/commit/903e69b388b935cfb135312a3a76b04608133a... [2] https://github.com/geany/geany/commit/8f280ed884721a0a1c75462e428b9bcffb3ac5...