ya the rename easiest
On Wed, May 29, 2013 at 8:00 AM, Braden Shepherdson <bra...@chromium.org> wrote: > I'll keep this thread up to date with INFRA's responses. > > I asked INFRA about options and their implications. These are the four > options I described, after I was informed that our original request would > actually require everyone to re-clone the repo. > > 1. Check out master, delete all the files, copy in all the files from > master2, check them all in. This keep the branching the same, and no one > would need to re-clone. But it also makes the history nearly useless before > that point. I dislike this option, but it's there. > > 2. Rename master to old_master or similar, and rename master2 to master. > Since everyone is re-cloning anyway, this is possible. Keeps the name > consistent. This might be nasty if someone tries to merge between an old > master and the new master. Unless git can notice that things are wrong and > they should re-clone. > > 3. My original request to move HEAD. Exposes the master2 name and requires > everyone to use it. Still requires a re-clone. > > 4. Abandon the repository and recreate it under a new name, pushing only > master2 as the new master. Requires a re-clone and changing the name. > Probably not, but it's an option. > > What do people think? I'm most partial to 2, since it preserves the master > name and it's hard to avoid recloning. > > Braden > > > On Tue, May 28, 2013 at 8:07 PM, Jesse <purplecabb...@gmail.com> wrote: > >> 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. >> > > > >> > > >> > >>
