Am 06.12.2013 17:04 schrieb "Steven Watanabe" :

AMDG

On 12/06/2013 08:06 AM, Thomas Heller wrote:

...

I just cloned modular boost and wanted to get phoenix back on track. However, something very disturbing occured to me: The develop and master branches in the git repos (for all repos) are completely distinct from each other! How could this happen? In the case of phoenix those have, unfortunately, completely diverged from each other (content wise, commit wise, they have completely distinct commits). What's the best practice to do here? How to proceed?

In svn the branches are completely separate, and svn:mergeinfo indicates which commits have been merged from other branches.

I was hoping that the conversion script tracked and conserved this information. In the current state is close to impossible to see where those two branches might have diverged. Also, the history of the master branch of most repositories is close to useless now.

If you want to merge everything, I think git merge has an option to use the state of one branch as the result of the merge.

Yeah. I think that might be an option. Though I'm afraid of losing commits/content only available in the "to be absorbed" branch.

In Christ, Steven Watanabe

_______________________________________________ Unsubscribe & other changes:

http://lists.boost.org/mailman/listinfo.cgi/boost

Date: Fri, 6 Dec 2013 16:33:35 +0000 From: daniel@calamity.org.uk To: boost@lists.boost.org Subject: Re: [boost] [git] develop and master are two completely distinct branches

On 6 December 2013 16:20, Thomas Heller wrote:

...

I was hoping that the conversion script tracked and conserved this information. In the current state is close to impossible to see where those two branches might have diverged. Also, the history of the master branch of most repositories is close to useless now.

The history of branches/release wasn't much better. You can still use subversion to examine the old history, and find out what need to be merged. In this case:

svn mergeinfo --show-revs eligible "https://svn.boost.org/svn/boost/trunk/boost/phoenix" "https://svn.boost.org/svn/boost/branches/release/boost/phoenix" r71952 r72702 r78205 r79223 r85952

svn mergeinfo --show-revs eligible "https://svn.boost.org/svn/boost/trunk/libs/phoenix" "https://svn.boost.org/svn/boost/branches/release/libs/phoenix" r72702 r73369

Then look through the develop log to find the equivalent git revisions and decide whether they need to be merged.

Although I think I'd just create separate clones of master and develop and reconcile the differences manually and then mark it as fully merged. A graphical merge tool could help here.

If you do the following in libs/phoenix: git checkout develop git merge master git status # resolve conflicts git commit Then you'll have a point where the history of develop is based on master, which makes future merges easier. Note, at some point you can then merge develop into master, which will publish the changes in phoenix so they will be in the next release. As far as I can tell, the majority of the changes are enabling tests and adding the inline keyword. I'd imagine the goal would be to have master and develop point to the same state and go from there.

Maybe not so much for phoenix, but for some other libraries with a lot of stuff not merged to master (svn release), you may desire to get the first merge point in git some place back in history. If you find your most resent commit where the source trees in develop and master are equal or are acceptable to merge to master. Then you can do.

git checkout master git merge --no-ff <commit-sha1-you-want-to-merge-to-master> git status # resolve conflicts if any git commit -am "merged develop->master to get first git merge point"

I use the --no-ff option out of habit, as that is what I most often want to do. When merging feature branches into develop or develop into master --no-ff ensure that you get a new commit for the merge, and that the merge is not simply a fast-forward along the merged-in-branch which would include all your intermittent commits in the branch you merge to.

That worked a treat for me, many thanks, I'll see if I can add this to the Wiki as it seems to be something everyone pretty much will need to do. John.

Dave Abrahams writes:

Thomas Heller writes:

...

Am 06.12.2013 17:04 schrieb "Steven Watanabe" :

...

AMDG

On 12/06/2013 08:06 AM, Thomas Heller wrote:

...

I just cloned modular boost and wanted to get phoenix back on track. However, something very disturbing occured to me: The develop and master branches in the git repos (for all repos) are completely distinct from each other! How could this happen? In the case of phoenix those have, unfortunately, completely diverged from each other (content wise, commit wise, they have completely distinct commits). What's the best practice to do here? How to proceed?

In svn the branches are completely separate, and svn:mergeinfo indicates which commits have been merged from other branches.

I was hoping that the conversion script tracked and conserved this information. In the current state is close to impossible to see where those two branches might have diverged. Also, the history of the master branch of most repositories is close to useless now.

It could conserve it, but it couldn't represent it as merge history in Git. Git doesn't have a notion of "these commits were merged from that other branch," except in the same sense that it has a notion of files being moved or renamed: it can reconstruct that information after the fact.

Unfortunately, it doesn't use that information for "git merge," AFAIK. I'm not sure why.

There are several things you can do about this. One is to use the "git cherry" command to find commits that are not in common, but there's a more automatic way to get there, involving a rebase and a few other steps. Let me try an experiment with Phoenix and I'll post back here.

Actually I just tried the bog-standard "git merge" in both directions, and aside from the fact that Phoenix contains some insanely long lines, the conflicts look entirely tractable: https://gist.github.com/dabrahams/7848496 So I'm not sure what problem you're having.