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