release/2.8.1a about pg HOT 7 CLOSED

I could easily rebase my recent patches to the new release branch, in order to get them off the current 2.8.1 branch and simplify the head of 2.8.1. That might make it easier to work out the rest of the commits. If you want me to go ahead and do that, let me know.

from pg.

Go ahead.

Take care,

Mike

from pg.

OK, I think I have straightened things out. It took me quite a while to get a complete handle on what what what, but I have it worked out now, and have fixed up the release/2.8.1 branch so that it is a hot-fix branch (that is, it branches from master and has no pulls from develop). I did this by rebasing most of the original release/2.8.1 branch. Luckily, most of the commits where not pulls from other people's branches, so it was pretty linear. The tricky part was to undo a merge of a preliminary version of 2.8.1 into develop about half way along. (That was made more confusing by the fact that GitHub's network viewer was showing overlapping lines -- and of the same color no less -- that made the paths unclear.)

In any case, I was able to rebase in two pieces around that merge. The hard part was making sure that everything important from develop that was on the original release/2.8.1 branch was included in the new one. That's what took me the longest to figure out. (And I discovered that git diff and GitHub's compare function don't do what I thought. More on this later.)

Fortunately, there were only two changes due to that merge that weren't already in master (from which the new release/2.8.1 is branched), so I could cherry-pick those into the hotfix. There was a later merge of develop into release/2.8.1 that brought one file from Kelly Black into release/2.8.1. It didn't look like a hot-fix type of change, and Kelly had only made a pull request into develop, so I left that one out for now. It would be easy to cherry-pick that into the release, if you wanted me to.

The only other difference between the new and old versions of release/2.8.1 is an extra blank line in PGessaymacros.pl. I didn't bother to fix that.

Note, however, that the VERSION file in release/2.8.1 currently reads develop (I kept that since that was in the old release/2.8.1 branch, due to the merge into develop). I'm not sure whether you want that to be changed now or if that comes just before making the official release.

I still have a private copy of the old branch if we need it back for any reason. At this point, most of the commits that were on that branch are now duplicated due to the rebasing, and have fallen back into their original branches in Mike's and Geoff's repos. Mike, I would suggest deleting your master and develop branches and checking our new copies (as tracking branches from openwebwork). That should prevent these older unneeded commits from reappearing in the history later. Your release/2.8 branch can also be deleted, as the one change it contains was rebased. Geoff, your devmerge branch looks like it can be removed.

I think the head of the repo now looks cleaner, and I hope it will help make future updates easier. I did the last few changes on release/2.8.1 as merge with --no-ff so they look like loops; this is what bug fixes on a release branch should look like, so I did this as examples of that.

Now I will work on documenting the branching model and release processes.

from pg.

Thanks for this. The network graphs do look more sane. I'm not actually that concerned about the graphs, but I feel like if we get them under control we might have fewer surprises when merging.

Is the next step to do a pull request from 2.8.1 into master and then eventually merge that?

from pg.

Just for information's sake I want to point out a couple of things that I noticed as I was working on this.

First, when release/2.8 was made, (i.e., pull request #40 was merged), there should been a second pull into develop (either by hand or via another pull request). That would bring develop into synch with whatever changes were done along the release/2.8 branch since it was split from develop. (There does seem to be one at the 2.7 release, though it is done by merging master with develop, while I would recommend merging the release branch to develop instead.)

Second, the separation between develop and release/2.8 was pretty good, with only one major cross over at pull request #66 on October 6th, which brought develop into release/2.8 (the merged branch seem to have split off develop several commits earlier). This makes a6c7b95 the common ancestor between release/2.8 and develop, rather than the point at which release/2.8 was split from develop.

Third, there was one similar merging of release/2.8.1 and develop (this time 2.8.1 into develop), which I discusses in my previous post. This one was less problematic, but still some work to straighten out.

Finally, once the last few months were straightened out, things looked a lot better, and it became clear that we have mostly been doing pretty well with the branching and merging, so it may not be as hard to move to the new approach than I originally thought. So that was encouraging.

from pg.

Is the next step to do a pull request from 2.8.1 into master and then eventually merge that?

Yes, that would make sense, and follows the established pattern, since this looks like a release, even though it is technically a hot fix. Normally a hot fix would get pulled quickly, but Mike may want to leave this one a little longer like other release pull requests.

I'm not actually that concerned about the graphs, but I feel like if we get them under control we might have fewer surprises when merging.

One of the reasons it is helpful to have the topology of the graph more readable is that it will help make it clear that the branching is correct when a pull request comes in (e.g., a hotfix branches from master, a bugfix branches from a release or develop branch, etc.) Trying to unravel the complicated interconnections that were in the graph earlier was a real pain (it took me two solid days to get it figured out). Having the branching managed correctly will simplify that considerably, and that will make the graph cleaner, and that will make getting the right branching easier, so it is a feed-back loop. It should also make it easier to track what changes actually are involved in any particular feature or branch; this was quite difficult with the earlier tree.

from pg.

I mentioned above that the GitHub compare feature didn't do what I expected it to. Here's what I mean by that.

I had expected the comparison to represent to be a "diff" between the two branches (essentially what would need to be changed in one to make it the other). This would reflect the changes made when the one is merged into the other. This would be the result of

 git diff commit1 commit2

It turns out that this is not at all what GitHub's compare does. It uses

git diff commit1...commit2

and the dots make a big difference. This means find the common ancestor for the two commits, and show the differences in the files from all the commits from that point up to commit2. This is certainly useful, but not at all the same thing, which is why I was confused by the output from compare earlier when I was trying to understand about the two files that were different in the webwork2 tree. I misunderstood what the comparison was doing.

This difference-from-the-common-point is actually very useful, and part of what I needed to straighten out the release/2.8.1 branch. I just didn't know you could get it this way.

Some other useful commands:

git diff --name-status commit1 commit2

Just the names and statuses of the files with differences

git diff --name-status commit...commit2

Just the names and statuses of the commits from the common ancestor along the branch up to commit2.

git log --oneline commit1...commit2

one line log messages with SHA numbers for all the commits from the common ancestor up to commit2.

git merge-base commit1 commit2

The SHA of the common ancestor for the two commits.

git show commit

The commit details for the commit (useful for finding out what commit is returned by git merge-base)

from pg.