Hi Eric, On Wed, 8 Apr 2009, Eric Blake wrote:
> According to Eric Blake on 4/8/2009 7:19 AM: > > OK, I'll take some time today to mock up an approach, taking notes of what > > I did to make explaining it easier, and post the results to my clone at > > http://repo.or.cz/w/bison/ericb.git for review. If you like how it looks, > > we can then push it to savannah. Thanks for taking the time to do this. I get the concept now, and I may like to try it in the future. However... > But to date, we haven't done that. So we need a > one-time merge to establish that each older branch is a subset of the > newer; here, the merge --strategy=ours says to make the merge but change > no file contents (otherwise we would get merge conflicts). This is a > one-time operation, if we subsequently follow the branch paradigm. > > $ git merge --strategy=ours branch-2.4.2 > Already up-to-date. > $ git checkout master > Switched to branch "master" > $ git merge --strategy=ours branch-2.5 > Merge made by ours. I don't like the effect this has on git log for our current branches. Too many commits show up duplicated, and some log entries don't make sense for master. Once branch-2.4.2 and branch-2.5 become inactive, we'll have a fresh start at this approach, and maybe we can get it right then. In the meantime, would you push your patch separately to each of those branches? I can do it if you're busy. Thanks for your help. I've definitely learned more about git.
