Re: [Geany-devel] Just a stupid github question: How to merge a pull request with fast forward?
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 add ndbroadbent 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Just a stupid github question: How to merge a pull request with fast forward?
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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Just a stupid github question: How to merge a pull request with fast forward?
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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Just a stupid github question: How to merge a pull request with fast forward?
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/903e69b388b935cfb135312a3a76b04608133a4e [2] https://github.com/geany/geany/commit/8f280ed884721a0a1c75462e428b9bcffb3ac527 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
