Cheers! On 6/12/13 2:04 PM, "Michal Mocny" <[email protected]> wrote:
>That sounds right, I'll see about poking Braden to peek too. > > >On Wed, Jun 12, 2013 at 4:59 PM, Filip Maj <[email protected]> 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" <[email protected]> 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 >> ><[email protected]>wrote: >> > >> >> Let's see how quickly they react to the new ticket. >> >> >> >> Braden >> >> >> >> >> >> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <[email protected]> wrote: >> >> >> >> > My intuition is we'll need to bump the infra guys on irc.. >> >> > >> >> > On 6/10/13 1:16 PM, "Braden Shepherdson" <[email protected]> >>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 >> >> > ><[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. >> >> > >>> > >> >> >> >> >> > >>> > >> >> >> >> > >>> > >> >> >> >> > >>> > >> >> >> > >>> > >> >> >> > >>> > >> >> > >>> > >> >> > >>> >> >> > >> >> >> > >> >> >> > >> >> > >> >> >> >>
