cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Cordova CLI merge, new branch, INFRA ticket
Date Sat, 01 Jun 2013 22:36:08 GMT
Option 2! Let's move forward and get this sorted.

On 5/29/13 1:17 PM, "Jesse MacFadyen" <purplecabbage@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 <mmocny@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
><braden@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 <mmocny@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 <iclelland@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 <
>>> braden@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 <purplecabbage@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 <
>>>>> braden@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 <
>>>> agrieve@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 <
>>>>>>> braden@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.
>>


Mime
View raw message