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 Mon, 03 Jun 2013 17:16:23 GMT
Thanks for taking that on Braden

On 6/3/13 10:15 AM, "Braden Shepherdson" <braden@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 <fil@adobe.com> wrote:
>
>> 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