My intuition is we'll need to bump the infra guys on irc.. On 6/10/13 1:16 PM, "Braden Shepherdson" <bra...@chromium.org> wrote:
>Since it's been nearly two weeks with no movement despite a bump, I've >closed the old INFRA ticket and opened a new one[1] stating that we intend >to move forward with option 2. > >Braden > >[1] https://issues.apache.org/jira/browse/INFRA-6374 > > >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson ><bra...@chromium.org>wrote: > >> Waiting on INFRA. I've already told them that we want to go with 2. >> >> Braden >> >> >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <benn.ma...@gmail.com> wrote: >> >>> I'm fine with option 2, lets get this done. >>> >>> >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <f...@adobe.com> wrote: >>> >>> > SGTM >>> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <bra...@chromium.org> wrote: >>> > >>> > >I did some experimenting on my local disk to see what would happen >>>if >>> we >>> > >did go with option 2. It's pretty sane and safe: >>> > > >>> > >- If someone re-clones as requested, all is well. >>> > > >>> > >- If someone doesn't re-clone, then there are two cases: >>> > > - Merging the old local master against the new remote master: >>> Massive >>> > >conflicts; should remind people that there was something about this >>> repo. >>> > > - Pushing the old local master to the new remote master: Fails >>> because >>> > >it's not a fast-forward merge. >>> > > >>> > >So that's pretty okay. It would take real effort to resolve these >>> > >conflicts >>> > >and try to push the result. No one is likely to do that, and they >>>still >>> > >can't cause lasting damage unless it's a committer. All the >>>committers >>> are >>> > >aware of this problem, and getting that huge conflict is likely to >>> remind >>> > >them of this. >>> > > >>> > >Braden >>> > > >>> > > >>> > >On Mon, Jun 3, 2013 at 1:16 PM, Filip Maj <f...@adobe.com> wrote: >>> > > >>> > >> Thanks for taking that on Braden >>> > >> >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" <bra...@chromium.org> >>> wrote: >>> > >> >>> > >> >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. >>> > >> >> >> >>> > >> >> >>> > >> >> >>> > >> >>> > >> >>> > >>> > >>> >> >>
