Hello, I'm trying to compare Boost.Python's develop branch with master, to decide how to proceed. I was naively assuming that develop would regularly be rebased so it's easy to merge patches. However, https://github.com/boostorg/python/branches/active indicates develop is "276 commits ahead". How is that possible ? How did previous maintainers keep the develop branch in sync with master ? How is this handled in other Boost libraries ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 28.06.2015 21:57, Stefan Seefeld wrote:
Hello,
I'm trying to compare Boost.Python's develop branch with master, to decide how to proceed. I was naively assuming that develop would regularly be rebased so it's easy to merge patches. However, https://github.com/boostorg/python/branches/active indicates develop is "276 commits ahead". How is that possible ? How did previous maintainers keep the develop branch in sync with master ? How is this handled in other Boost libraries ?
It is normal that develop is ahead of master because all active development is supposed to happen in develop (or in separate branches that are merged into develop). When stable and tested, develop is merged into master. However, in your case I can see that develop is 73 commits behind master as well. This is what normally should not happen. It means that someone committed directly to master. I guess you will have to review these commits and cherry-pick them to develop and then merge develop to master.
On 28/06/15 03:25 PM, Andrey Semashev wrote:
On 28.06.2015 21:57, Stefan Seefeld wrote:
Hello,
I'm trying to compare Boost.Python's develop branch with master, to decide how to proceed. I was naively assuming that develop would regularly be rebased so it's easy to merge patches. However, https://github.com/boostorg/python/branches/active indicates develop is "276 commits ahead". How is that possible ? How did previous maintainers keep the develop branch in sync with master ? How is this handled in other Boost libraries ?
It is normal that develop is ahead of master because all active development is supposed to happen in develop (or in separate branches that are merged into develop). When stable and tested, develop is merged into master.
That's all theory, which I think I understand. Unfortunately theory and practice are only the same in theory...
However, in your case I can see that develop is 73 commits behind master as well. This is what normally should not happen. It means that someone committed directly to master. I guess you will have to review these commits and cherry-pick them to develop and then merge develop to master.
Why cherry-pick ? If master is the Golden Standard, everything should be rebased on that, no ? (Trying to rebase "develop" to current "master" stops at a commit from 2006, so it seems this rebasing has never been done before. And likewise for the other direction: As I reported, there are 276 commits in develop that haven't been merged to master, which must have accumulated over many release cycles. I wonder what the best strategy is to fix this, even incrementally... Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Why cherry-pick ? If master is the Golden Standard, everything should be rebased on that, no ?
I don't know about others, but I never rebase. What I do is commit to develop and merge --no-ff to master. At the beginning, master and develop weren't in sync and there were no merge points, so what I did was to cherry-pick commits until git diff master..develop reported no differences, then merge.
On 28 Jun 2015 at 15:42, Stefan Seefeld wrote:
I wonder what the best strategy is to fix this, even incrementally...
Personally speaking, I'd install a copy of Jenkins and get it running a fully battery of unit tests for all your targets, so Python 2.x and Python 3.x on clang, GCC and MSVC. I'd then write a script which pulls individual commits from master into develop (or the other way round), testing each in turn, stopping when a merge fails and emailing you. You then keep at it laboriously until it's merged. With a bit of luck, most of the commits in master are also in develop, and it's just that git doesn't realise. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Hi Stefan, Am Sonntag, 28. Juni 2015, 15:42:56 schrieb Stefan Seefeld:
On 28/06/15 03:25 PM, Andrey Semashev wrote:
On 28.06.2015 21:57, Stefan Seefeld wrote:
However, in your case I can see that develop is 73 commits behind master as well. This is what normally should not happen. It means that someone committed directly to master. I guess you will have to review these commits and cherry-pick them to develop and then merge develop to master.
Why cherry-pick ? If master is the Golden Standard, everything should be rebased on that, no ? (Trying to rebase "develop" to current "master" stops at a commit from 2006, so it seems this rebasing has never been done before. And likewise for the other direction: As I reported, there are 276 commits in develop that haven't been merged to master, which must have accumulated over many release cycles.
It seems that the "release" and "trunk" branches were out of sync in good 'ol svn times.
I wonder what the best strategy is to fix this, even incrementally...
There is a sample cleanup session documented at https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint which somewhat covers your case. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On Sun, Jun 28, 2015 at 1:57 PM, Stefan Seefeld
Hello,
I'm trying to compare Boost.Python's develop branch with master, to decide how to proceed. I was naively assuming that develop would regularly be rebased so it's easy to merge patches. However, https://github.com/boostorg/python/branches/active indicates develop is "276 commits ahead". How is that possible ? How did previous maintainers keep the develop branch in sync with master ? How is this handled in other Boost libraries ?
I think this is an artifact of it never having been merged before (since the Git transition). If you actually look at the differences between branches, they are not that severe (though still substantial). I was able to perform the merge myself, from a local copy of develop to a new branch that I had made off of master, and there were only a couple conflicts and around 60 changed files. https://github.com/boostorg/python/compare/master...teeks99:master_merge I believe this is what the merge *should* look like. In the five conflicts that I had to resolve there were a couple things that never made it to develop (I'm not sure how that happened), but they seem to be dealing with Visual Studio 2003....so no longer supported stuff. If we do this merge, we should then merge back into develop: https://github.com/teeks99/python/compare/develop...teeks99:master_merge Tom
participants (6)
-
Andrey Semashev -
Jürgen Hunold -
Niall Douglas -
Peter Dimov -
Stefan Seefeld -
Tom Kent