Develop is behind master about pg

[goehle]

Its probably because things were submitted to release/8.1 or master that
were not then submitted/pulled into develop. I know pulling release
branches into develop was part of the plan. (In a previous email today you
said I should submit the hotfix to the release branch and it would find its
way to develop when the release branch was pulled into develop.

In theory pulling from a release branch or from master into develop should
be safe. Davide probably has an idea of what should be done.

Geoff.

[goehle]

In general a good policy could be that whenever something is pulled into a
release branch, then that release branch is pulled into develop. Either
that or things that get submitted to the release branch should also be
submitted to develop.

[dpvc]

I will say more later, but wanted to get you a quick response.

At the moment develop is behind master by 39 commits.

master...develop

Yes, that is correct, and it is the result of improperly handling commits to master in the past. I straightened most of that out in January, but didn't pull master into develop because that would occur when release/2.8.1 is merged into develop after it is released. If that is imminent, then I would leave it go until then.

It seems to me that this should happen rarely.

It really should not happen at all, but can happen if hot fixes are not merged into both master and develop (or can happen if they go only to master and a release/x.y branch before that release is merged into develop).

Some of the commits are empty "merge" commits but some of them are real changes -- such as the fix that prevents printing a problem source for students when an error occurs (Made on Dec 4) -- and as far as I can tell this is not in develop although it is in release/2.8.1.

Right. It will be resolved when release/2.8.1 is merged into develop after it is released.

On the other hand that missing commit doesn't show up in the comparison

release;2.8.1...develop

release/2.8.1 seems to be clean additions to master.
master...release;2.8.1
all changes made since Jan 29.

Some of this is probably because I don't properly understand github compare.

The comparison doesn't do what you expect it does. It is not a direct comparison of the two branches. What it is is the commits on the second branch since the common point of the two branches. That means release/2.8.1...develop is the commits to the develop branch since the place where these two branches split from each other. It turns out that this is "Merge branch 'develop_init_fix' into develop" on October 6th. So the listing of commits are the ones to the develop branch from that point on. Since the commit you are talking about is on master, it would not appear in this list.

On the other hand, if you did develop...release/2.8.1, that would list the commit on the release/2.8.1 branch from that same common ancestor on October 6th.

This is the output from the command

git diff develop...release/2.8.1

You don't seem to be able to get an actual diff between two branches from GitHub, but you can from the command line

git diff develop..release/2.8.1

(notice that there are only two dots rather than three; that is what makes it a direct diff rather than a common-ancestor diff).

Merging release/2.8.1 into develop and into master (which we should do pretty soon
-- at the very least we should merge it into develop very soon )
will still leave a few commits currently in master that have not made it over to develop.

No, merging release/2.8.1 will bring everything currently in master (and release/2.8.1 that branches off the head of the master branch) into develop. Once that is done, develop will be up to date with master.

My suggestion is that one of us merge release/2.8.1 into develop right away (what could go wrong? :-) ) and then run the comparisons again to see whether develop is missing important commits that exist in master.

Because release/2.8.1 branches off master, it is considered a hotfix (normally, a release branches off develop). It is possible to merge release/2.8.1 into develop now, but it would be unusual to merge a hot fix into develop more than once. But release/2.8.1 is an unusual hotfix, so perhaps that is OK.

I am planning to spend this coming week writing up what I figured out last month (it took me my full week to unwind the webwork and pg branching last month, and so I wasn't able to write it up when I had hoped to). I know it has been too long, but the work and discussions that we had at the end of last month really helped to work out the details.