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. > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > >
