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 <[email protected]>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 <[email protected]> wrote: > >> I'm fine with option 2, lets get this done. >> >> >> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <[email protected]> wrote: >> >> > SGTM >> > >> > On 6/4/13 10:44 AM, "Braden Shepherdson" <[email protected]> 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 <[email protected]> wrote: >> > > >> > >> Thanks for taking that on Braden >> > >> >> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" <[email protected]> >> 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 <[email protected]> wrote: >> > >> > >> > >> >> Option 2! Let's move forward and get this sorted. >> > >> >> >> > >> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <[email protected]> >> > >>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 <[email protected]> >> > 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 >> > >> >> ><[email protected]>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 >> > >><[email protected]> >> > >> >> >> 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 >> > >> >><[email protected]> >> > >> >> >>> 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 <[email protected]> >> > >>wrote: >> > >> >> >>>> >> > >> >> >>>>> ya the rename easiest >> > >> >> >>>>> >> > >> >> >>>>> On Wed, May 29, 2013 at 8:00 AM, Braden Shepherdson < >> > >> >> >>> [email protected] >> > >> >> >>>>> >> > >> >> >>>>> 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 >> > >><[email protected]> >> > >> >> >>>> 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 < >> > >> >> >>>>> [email protected] >> > >> >> >>>>>>>> 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 < >> > >> >> >>>> [email protected] >> > >> >> >>>>>>>>> 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 < >> > >> >> >>>>>>> [email protected] >> > >> >> >>>>>>>>>> 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. >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >
