Re: [boost] [github] default PR destination

On 01/08/2014 03:27 AM, Cox, Michael wrote:

On Sun, Jan 5, 2014 at 8:44 AM, Peter A. Bigot wrote:

...

On 01/05/2014 09:34 AM, Peter A. Bigot wrote:

...

On 01/05/2014 08:50 AM, Peter Dimov wrote:

...

Peter A. Bigot wrote:

...

The last one (regex) I did off master, and I expect that most future ones will also be off master.

What is a developer supposed to do with a pull request against master?

Pull the branch to a local repository, merge it into develop, test it, and reject or approve it. Normal git practice: see https://help.github.com/articles/merging-a-pull-request under "Merging locally".

If master and develop do not share commits (as I believe they will not under git-flow):

I noticed that there are some submodules where develop is based on master, i.e. if you run "git branch --contains master", both master and develop are output. Most of them, like you say, show master and develop to be distinct. Won't that be a problem when trying to merge from develop to master?

I am not sure how much it matters, if any what branches is listed by "git branch --contains master". Apply/commit, merge from other remote tracking branches, or pull contributions such as GitHub PRs to develop as they where applied to trunk in SVN. It make a lot of sense for all maintainers to maintain public devlop head as the point they expect every contributor to base their contribution upon. Every other long running or deferred work not expected to go into next release should be put into feature branches. I am not familiar with pulling GitHub PR, but I expect it to be possible to merge localy and commit, then before pushing to GitHub make the assessment whether it should be put in a feature branch or stay in develop, if it need to go in a feature branch you may make the feature branch at the new commit and reset develop head to previous commit. git checkout -b feature/PR-id-descriprion git checkout develop git reset HEAD^ this is very simple to do, understand, and verify correctness of what you do using some GUIs, e.g. using "gitk" tool that come with git distribution. In gitk right click the commits description to select "create new branch here" and "reset develop to this" commands. You see the result immediately in the commit tree and know it is what you want before pushing to GitHub. Note, if you want gitk to show more than current branch, use gitk --all, or create/edit view in menu. Don't underestimate gitk based on looks, it is actually very elegant and powerful to use if you try it a bit. It is up to the maintainer to merge submodule releases only into master. Thus it make no sense in general to base contributions on master as develop may contain a lot of stuff for next release. I would vote strongly for always using develop head as base for contributions.

Just for grins, I took the accumulator submodule in which master and develop don't share commits and tried to locally rebase develop onto master. Unfortunately, the rebase failed early, but the few files I looked at have the same change trying to be applied on both sides, i.e. the lines between >>>> and ==== were the same as the lines between ==== and <<<<<. Any idea why that's the case?

no initial merge in git has been performed yet for accumulators: https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint so I don't really know what to expect. And I don't know if we should care much as it is not fair to git to expect much specific when trying to blindly merge to disjoint trees.

It looks like develop might be able to be "reconnected" to master (at least in accumulator), but it would take someone who understands the code and history of changes.

yes, this needs to be done with some special care as you indicate to help Git perform sensible automatic of merge later. -- Bjørn