I've bumped the INFRA ticket[1], I'll keep this thread up to date with any changes there.
Braden On Sat, Jun 1, 2013 at 6:36 PM, Filip Maj <f...@adobe.com> wrote: > Option 2! Let's move forward and get this sorted. > > On 5/29/13 1:17 PM, "Jesse MacFadyen" <purplecabb...@gmail.com> wrote: > > >I am liking option 2 now. Seems easy enough. > > > >Cheers, > > Jesse > > > >Sent from my iPhone5 > > > >On 2013-05-29, at 9:06 AM, Michal Mocny <mmo...@chromium.org> wrote: > > > >For the record, I don't mind a reclone, so long as there are no negative > >repercussions, ie, (1) its not called master2 and (2) there is no way for > >anyone to shoot us in the foot if they forget to re-clone properly and > >start doing merges/pushes/whatever. > > > >So, if (2) fails loudly thats my preference. Otherwise, I don't mind (4) > >but others might, and I hate (3) more than (1) :) > > > >-Michal > > > > > >On Wed, May 29, 2013 at 11:51 AM, Braden Shepherdson > ><bra...@chromium.org>wrote: > > > >> This would be an example of "continuing to pay the price for not being > >> willing to re-clone 1, 3, 6, 12 months ago." We can avoid all of that > >> nonsense with three lines. > >> > >> Braden > >> > >> > >> On Wed, May 29, 2013 at 11:38 AM, Michal Mocny <mmo...@chromium.org> > >> wrote: > >> > >>> Can we go with (1) and still keep master2 around (perhaps rename it to > >>> something sensible) so that we can still get full history but with one > >>> level of indirection: > >>> - The mega commit could have a commit message such as "THIS WAS A HACKY > >>> MERGE, FOR REAL HISTORY LOOK IN THE OLD_FUTURE BRANCH" > >>> - When you bit blame and see that as the commit responsible, you know > >>>you > >>> have to git blame again in the other branch > >>> > >>> -Michal > >>> > >>> > >>> On Wed, May 29, 2013 at 11:22 AM, Ian Clelland <iclell...@google.com> > >>> wrote: > >>> > >>>> SInce 2 and 3 both require re-cloning the repository, I'd much rather > >> go > >>>> with 2, and rename the branches appropriately. > >>>> > >>>> > >>>> On Wed, May 29, 2013 at 11:11 AM, Brian LeRoux <b...@brian.io> wrote: > >>>> > >>>>> 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. > >> > >
