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