Daniel James writes:

On 24 December 2013 13:03, Joaquin M Lopez Munoz wrote:

...

even though branch develop is indeed different from (and more recent than) the code in master (it contains changes from about one month or so intended for Boost 1.56 that weren't published when the branch master was originally created)

How did you merge? I tried checking out the old version and merging, and got a lot of merge conflicts (I think you got your merge point a little wrong, but that isn't a big problem). Did that happen for you?

At some point that happened to me, I seem to remember I reverted or something and then retried. Not completely sure, though, now the situation is as I describe, git merge --no-ff develop tells me I'm up-to-date even though branches are different.

Or maybe you used "git merge -s ours"? The "-s ours" flag on the wiki was just for creating the merge point, as it tells git to use the "ours" merge strategy, which basically performs no merge at all (roughly similar to using 'svn merge --record-only' in subversion). The text on the wiki should be clearer here.

I did -s ours as explained in "First post-svn conversion merge to master", and this seems to have gone well (commit meddage "created first merge point for Git".) It is on the second commit that I messed things up, seemingly (commit message "Merge branch 'develop'"), and to be honest I don't remember if I used -s ours (I understand I mustn't use it, but I did something wrong, maybe it was that.)

Do you want to have master identical to develop?

Yes, I want the master branch to be exactly the same aas the branch develop stands now. Thank you, Joaquín M López Muñoz Telefónica Digital

On 12/24/2013 10:24 AM, Bjørn Roald wrote:

On 12/24/2013 03:19 PM, Joaquin M Lopez Munoz wrote:

...

Yes, I want the master branch to be exactly the same aas the branch develop stands now.

Then just try it again.

git checkout master git tag bad-merge # for the paranoid needing an easy way to get back! git reset --hard 3239677c40b6e15d1bb49675cabb077460333538 git merge --no-ff develop ... check you got what you want git tag -d bad-merge # for the paranoid that now has calmed down

I don't believe that will work; 3239677 (current master) already has develop recorded as being present, so you get: llc[431]$ git merge --no-ff develop Already up-to-date. without any change. Since git-merge does not have a "-s theirs" parameter, the following does work: git checkout -b hack develop git merge master -s ours \ -m 'Merge to sync develop and master preferring develop' git checkout master git merge hack git branch -d hack git checkout develop git merge master That last two merges are fast-forward, which is fine in this case. Check the results before you push (in fact, check the results after each step so you understand what it's doing). Peter

On 12/24/2013 10:57 AM, Bjørn Roald wrote:

On 12/24/2013 05:46 PM, Peter A. Bigot wrote:

...

On 12/24/2013 10:24 AM, Bjørn Roald wrote:

...

On 12/24/2013 03:19 PM, Joaquin M Lopez Munoz wrote:

...

Yes, I want the master branch to be exactly the same aas the branch develop stands now.

Then just try it again.

git checkout master git tag bad-merge # for the paranoid needing an easy way to get back! git reset --hard 3239677c40b6e15d1bb49675cabb077460333538 git merge --no-ff develop ... check you got what you want git tag -d bad-merge # for the paranoid that now has calmed down

I don't believe that will work; 3239677 (current master) already has develop recorded as being present, so you get:

llc[431]$ git merge --no-ff develop Already up-to-date.

without any change.

Right, my bad, the reset should have been to the commit before git reset --hard 802543fd948b5cf41460addf2260693f08cf7f8d

Then git merge --no-ff develop results in conflicts because master and develop diverged in March of 2006, and both have similar changes that git can't resolve.

Since git-merge does not have a "-s theirs"

...

parameter, the following does work:

git checkout -b hack develop git merge master -s ours \ -m 'Merge to sync develop and master preferring develop' git checkout master git merge hack git branch -d hack git checkout develop git merge master

That last two merges are fast-forward, which is fine in this case. Check the results before you push (in fact, check the results after each step so you understand what it's doing).

I am sure this will work as well, but to me it is more complicated and it will leave the bad commit in history, which I am sure some will argue it should.

I'd be one of those people. At any rate, there are several solutions with different characteristics. Try them locally, and push the one you like. Peter

On 12/24/2013 05:50 PM, Joaquin M Lopez Munoz wrote:

Bjørn Roald writes:

...

On 12/24/2013 03:19 PM, Joaquin M Lopez Munoz wrote:

...

Yes, I want the master branch to be exactly the same aas the branch develop stands now.

Then just try it again.

No luck, see below,

...

git checkout master git tag bad-merge # for the paranoid needing an easy way to get back! git reset --hard 3239677c40b6e15d1bb49675cabb077460333538 git merge --no-ff develop

I got "Alredy up-to-date." here

right, see my reply to Peter on this, copy-paste error of mine. Should have been. git reset --hard 3239677c40b6e15d1bb49675cabb077460333538 I tried it out now by the way, if you do it the way I suggested you will need to deal with 4 merge conflicts as well. Probably caused by the intermittent hotfix in SVN history. You may prefer the approach Peter suggested instead as it leaves your bad merge commit in the history of the master branch if you so prefer. Note removing commits in master branch may be bad if the boost super project references it, to keep it in the history of the master branch is one way of avoiding that. -- Bjørn

Bjørn Roald writes:

On 12/24/2013 06:17 PM, Bjørn Roald wrote:

...

right, see my reply to Peter on this, copy-paste error of mine. Should have been.

git reset --hard 3239677c40b6e15d1bb49675cabb077460333538

OK, I try again. git reset --hard 802543fd948b5cf41460addf2260693f08cf7f8d

Did that, merged from develop, resolved conflicts as theirs (develop's), commited OK but push failed with git.exe push --progress "origin" master:master To https://github.com/boostorg/multi_index.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/boostorg/multi_index.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. git did not exit cleanly (exit code 1) (13510 ms @ 24/12/2013 21:09:27) Joaquín M López Muñoz Telefónica Digital

On 12/24/2013 11:04 PM, Bjørn Roald wrote:

On 12/24/2013 09:11 PM, Joaquin M Lopez Munoz wrote:

...

Bjørn Roald writes:

...

On 12/24/2013 06:17 PM, Bjørn Roald wrote:

...

right, see my reply to Peter on this, copy-paste error of mine. Should have been.

git reset --hard 3239677c40b6e15d1bb49675cabb077460333538

OK, I try again. git reset --hard 802543fd948b5cf41460addf2260693f08cf7f8d

Did that, merged from develop, resolved conflicts as theirs (develop's), commited OK but push failed with

git.exe push --progress "origin" master:master

To https://github.com/boostorg/multi_index.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/boostorg/multi_index.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

git did not exit cleanly (exit code 1) (13510 ms @ 24/12/2013 21:09:27)

It tells you that you try to do a non-trivial merge at the remote repository, and refuses to do so without some more assertion from you that that is what you want.

git push --force

or

git push -f

should do it, just use gitk or other tool to make sure the master you have locally is what you want first.

That should take care of what you desire, But you should then be worried the bad merge commit may already be referenced by somebody, and you would be subject for some heat if you break canonical boost clone or submodule update as your bad commit is not available. That may happen if git garbage collection cleans up on the remote and find nothing referencing your old commit any longer.

To prevent this you must make sure some git ref on https://github.com/boostorg/multi_index/ reference the bad commit.

You may then push your tag for the bad merge commit if you like to.

If you made the tag I suggested, do git push --tags

done. In TG i think there is a checkbox for tags in the push dialog.

You can alternatively use a branch with a obvious not to use name for this, e.g.

git checkout -b trash/bad-master-merges 3239677c4 git push

or if you made the tag as I suggested,

git checkout -b trash/bad-master-merges bad-merge git push git tag -d bad-merge # to remove the tag from local repository

A branch may be simpler to clean up in future if you like to.

Joakim, I did some tests, and realized I had overlooked an important fact. Your first merge looks bad as well. Thus simply doing a normal merge after a reset as I suggested will not do what you want. The merge depend on a sensible common ancestor, and that is what you need to establish gefore git can work its merging magic. The conversion provided no such common ancestor for the old svn trunk and release branches. I think Peters suggested procedure may be used. It will leave the failed merges in the history, but they don't make any bad changes to master, so it is probably no big deal. If you want try to set a common ancestor in the past, c564f8f5dd9e8a4520345335382008d96aff7549 [SVN r85497] on develop which is identical to 590e3d151181716f05a4daaf7f371cbde04171d7 merged [85497] from trunk [SVN r85509] on the master branch Thus they seem to be the prime candidates. You need to make a branch on one of them, e.g.: git checkout -b fix-merge 590e3d151181716f05a4daaf7f371cbde04171d7 git merge c564f8f5dd9e8a4520345335382008d96aff7549 you now have a common ancestor commit at the head of local fix-merge branch, so git merge --no-ff origin/develop does what you expect, and the new merge commit in fix-merge is identical to your develop branch head. This is what you want, I think, only you want it in the master branch, So how do we go about with that? Right now it seems like the boost super project develop branch points at the fdd4934c234de61f8d2ba22fc3465a0ac90e11c5 commit of the multi_index submodule, which is the head of multi_index's develop branch, thus there are little risk involved in moving the master branch head if you like to do that. git checkout master git checkout -b trash/bad-master git checkout master git reset --hard fix-merge git push -f If you want to ensure the bad commit stays on github server: git checkout trash/bad-master git push cleanup in local repo git branch -d fix-merge HTH -- Bjørn

Bjørn Roald writes:

Right now it seems like the boost super

...

project develop branch points at the fdd4934c234de61f8d2ba22fc3465a0ac90e11c5 commit of the multi_index submodule, which is the head of multi_index's develop branch, thus there are little risk involved in moving the master branch head if you like to do that.

is seems that was not correct, the super module points at your latest unsuccessful merge commit in master. [...]

Hi Bjørn, thanks for your guidance. At some point down the thread the details of your preocedure begin to elude my understanding :-) so I decided to go ahead with the diff-based suggestion by Daniel, which conceptually is as simple as it gets. I sincerely hope that this is just a case of a particularly inept author (me) messing things up, but the aftertaste has left me worried. Maybe the supporting pages need to be more idiot-proof than they are now. Thank you, Joaquín M López Muñoz Telefónica Digital

On 12/25/2013 7:26 AM, Bjørn Roald wrote:

On 12/25/2013 12:49 PM, Joaquin M Lopez Munoz wrote:

...

Bjørn Roald writes:

...

Right now it seems like the boost super

...

project develop branch points at the fdd4934c234de61f8d2ba22fc3465a0ac90e11c5 commit of the multi_index submodule, which is the head of multi_index's develop branch, thus there are little risk involved in moving the master branch head if you like to do that.

is seems that was not correct, the super module points at your latest unsuccessful merge commit in master. [...]

Hi Bjørn, thanks for your guidance. At some point down the thread the details of your preocedure begin to elude my understanding :-) so I decided to go ahead with the diff-based suggestion by Daniel, which conceptually is as simple as it gets.

OK, do what work best for you.

...

I sincerely hope that this is just a case of a particularly inept author (me) messing things up, but the aftertaste has left me worried. Maybe the supporting pages need to be more idiot-proof than they are now.

In fact the first merge into master from develop after the SVN to Git conversion is important to get right. If not things become confusing as Git has no sensible common ancestor for the two branches, and what merge does may surprise you.

Then this should be very carefully documented somewhere on the Wiki pages where all Boost developers can easily find it. I find it mysterious that one cannot do for one's own submodule: git checkout master git merge develop git push so evidently there is much more to this as far as Boost and git is concerned. Hopefully what needs to be done will be carefully explained somewhere for all of us git non-experts.

On 12/25/2013 12:38 PM, Bjørn Roald wrote:

On 12/25/2013 03:34 PM, Edward Diener wrote:

...

On 12/25/2013 7:26 AM, Bjørn Roald wrote:

...

...

In fact the first merge into master from develop after the SVN to Git conversion is important to get right. If not things become confusing as Git has no sensible common ancestor for the two branches, and what merge does may surprise you.

Then this should be very carefully documented somewhere on the Wiki pages where all Boost developers can easily find it.

agreed, I think it is. See below.

...

I find it mysterious that one cannot do for one's own submodule:

git checkout master git merge develop git push

so evidently there is much more to this as far as Boost and git is concerned.

Not anything other than the fact the master and develop branch as they come out of the conversion from SVN are not really set up as normal git branches would. They are just two separate branches running parallel from the infancy of the library with no interconnections in the form of recorded merges forming some common parent. Such a common parent is normally used by git merge to end the search in history for change sets that may apply to the merge.

So Git may need a bit of care and help from you the first time you merge after the conversion to find a sensible place to make such a common parent. Then that is done git will likely do as you expect.

Just doing the canonical merge you describe above as the first time merge after conversion will likely work if the head of the develop branch and the head of the master branches are in sync. If not I recommend to look in the history of develop for a better commit to do the first merge from. See link below.

...

Hopefully what needs to be done will be carefully explained somewhere for all of us git non-experts.

There is a section called "First post-svn conversion merge to master" in:

https://svn.boost.org/trac/boost/wiki/StartModMaint#Gettingreadytoworkonalib...

Is that similar to what you have in mind?

That explanation is excellent. Sorry for the noise !

On 12/24/2013 10:46 AM, Daniel James wrote:

...

Yes, I want the master branch to be exactly the same aas the branch develop stands now.

There used to be 'git merge -s theirs' for doing that, which was the opposite of 'git merge -s ours' but they removed it. I did a quick search and found a solution on stack overflow (http://stackoverflow.com/a/5211321/2434):

git diff --binary origin/develop | git apply -R --index git commit -m "Copy content from develop"

Which is at least less fuss than the other solutions.

It does make the content identical, but the resulting commit has a different SHA1 than origin/master, so leaves open the potential for future conflicts. Doing a "-s ours" merge in develop brings both content and git parentage into sync. Peter

Daniel James writes:

On 24 December 2013 16:56, Peter A. Bigot wrote:

...

On 12/24/2013 10:46 AM, Daniel James wrote:

...

git diff --binary origin/develop | git apply -R --index git commit -m "Copy content from develop"

Which is at least less fuss than the other solutions.

It does make the content identical, but the resulting commit has a different SHA1 than origin/master, so leaves open the potential for future conflicts.

No it doesn't. Merge compares the merge base (current develop), and the two heads. it doesn't care what comes between.

...

Doing a "-s ours" merge in develop brings both content and git parentage into sync.

I had thought of doing it that way, but I was trying to find a simpler method. There's already enough confusion.

So, I did as Daniel instructed and seemingly eveything's OK now in master branch. So, should I do git checkout develop git merge -s ours to sync up SHAs between master and develop, or should I leave like that? Thank you, Joaquín M López Muñoz Telefónica Digital

On 25 December 2013 11:57, Daniel James wrote:

On 25 December 2013 11:42, Joaquin M Lopez Munoz wrote:

...

So, I did as Daniel instructed and seemingly eveything's OK now in master branch. So, should I do

git checkout develop git merge -s ours

to sync up SHAs between master and develop, or should I leave like that?

You can, but you don't need "-s ours":

git checkout develop git merge master

It should be a fast-forward merge.

Oh sorry, I just remembered why I didn't suggest merging into develop. The recommended work flow is not to do fast forward merges in order to keep the two branches separate. So maybe it's best no to.

On 25 December 2013 12:06, Joaquin M Lopez Munoz wrote:

Daniel James writes:

...

On 25 December 2013 11:42, Joaquin M Lopez Munoz wrote:

...

So, I did as Daniel instructed and seemingly eveything's OK now in master branch. So, should I do

git checkout develop git merge -s ours

to sync up SHAs between master and develop, or should I leave like that?

You can, but you don't need "-s ours":

git checkout develop git merge master

It should be a fast-forward merge.

This I did, and the merge was indeed a fast-forward one, but Git refuses to do then a commit on grounds that there are no changes:

You don't need to do a commit after a fast-forward merge, as it just moves you to the latest version from the other branch. But I forgot that we're avoiding fast-forward merges, so it's probably best not to merge from master at all. You can remove all your local changes using: git checkout develop git reset origin/develop That resets the develop branch back to its state on the server. If you're only making changes on develop, merges to master shouldn't conflict. You'll also have a clean history in develop, which will be useful for looking at the history of files.