What is the resolution on this? My opinion: History is in the past, move on. I think it's okay if it is history is messy, or even if has a few duplicate commits. Tangles and all.
@purplecabbage risingj.com On Fri, May 24, 2013 at 7:05 AM, Braden Shepherdson <bra...@chromium.org>wrote: > I think so, but only if we're prepared to keep the tangled history and > duplicate about 30 commits. Several mistakes were made with the branching > and rebasing of things on master, and there's a lot of duplication and > confusion in the history. > > When you get in this morning, I can show you the whiteboard diagram of the > long version above, and then you can look at the histories of master and > master2 on GitX. I think you'll agree it's worth moving forward with > master2. > > Braden > > > On Thu, May 23, 2013 at 11:16 PM, Andrew Grieve <agri...@chromium.org > >wrote: > > > Could we merge master2 into master with: > > > > git merge --strategy-option=theirs master2 > > > > > > On Thu, May 23, 2013 at 6:19 PM, Braden Shepherdson <bra...@chromium.org > > >wrote: > > > > > tl;dr version: cordova-cli now has a master2 branch that should be > > treated > > > as master going forward. DO NOT use master or future anymore. > > > > > > Short version: > > > > > > - I tried to merge future and master. > > > - I couldn't because the history is a train wreck. The morbidly curious > > > should see [2]. > > > - Ian and I dug through the history, and played CSI until we figured > out > > > what had happened, and found a sensible way to reconstruct a sane > master > > > branch. > > > - This branch merged fairly neatly with future. > > > - It is now committed as the new branch master2. > > > - The original master branch is deprecated. > > > - I have filed an INFRA ticket[1] to get them to point HEAD at master2, > > and > > > delete the old master branch. > > > - Use master2 from now on. DO NOT touch the old master or future > branches > > > anymore. > > > > > > I'll keep the list updated on the state of the INFRA ticket. > > > > > > Braden > > > > > > [1] https://issues.apache.org/jira/browse/INFRA-6302 > > > > > > [2] Long version: > > > > > > A long time ago, I forked cli's master to create future. I committed a > > > half-dozen changes or so. Sometime later, a 2.7.x branch was forked > /from > > > future/. Several changes were made here. Later it was merged back in, > /to > > > master/. The same changes were later rebased onto master and committed > > > again, duplicating them. Then this branch was merged with master again, > > > creating a /third/ copy of the changes originally from this 2.7.x > branch. > > > > > > Meanwhile, some of the changes from future were reverted by hand (as > > > opposed to with git revert) in master. > > > > > > Finally some new changes were made to future and master. It looks, > > > according to git, like there are only these changes on the future > branch, > > > since the earlier ones were merged by accident some time ago. > > > > > > When I came along and tried to merge master and future in either > > direction, > > > or rebase in either direction, those older future changes stayed > deleted, > > > because according to git they were made on the same branch. > > > > > > Moral of the story: Don't take a branch off master (like future), fork > > it, > > > commit to it, and then merge it back to master. That's what started > most > > of > > > the insanity, because now future is partially merged into master even > > > though it's not being treated that way. > > > > > > I need a drink. > > > > > >