That sounds right, I'll see about poking Braden to peek too.
On Wed, Jun 12, 2013 at 4:59 PM, Filip Maj <f...@adobe.com> wrote: > Replied, but would be good for others to take a peak at this thread as I > am not 100% sure that my answers are correct.. > > On 6/12/13 1:18 PM, "Benn Mapes" <benn.ma...@gmail.com> wrote: > > >What are we doing about https://issues.apache.org/jira/browse/INFRA-6302? > > > >I think they're afraid of messing things up for us. Does someone want to > >answer his questions? (I'm not sure what the correct approach is...) > > > > > >On Mon, Jun 10, 2013 at 1:27 PM, Braden Shepherdson > ><bra...@chromium.org>wrote: > > > >> Let's see how quickly they react to the new ticket. > >> > >> Braden > >> > >> > >> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <f...@adobe.com> wrote: > >> > >> > 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. > >> > >>> > >> >> >> > >> > >>> > >> >> > >> > >>> > >> >> > >> > >>> > >> > >> > >>> > >> > >> > >>> > > >> > >>> > > >> > >>> > >> > >> > >> > >> > >> > > >> > > >> > >
