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 Wed, 12 Jun 2013 20:59:31 GMT
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" <benn.mapes@gmail.com> 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
><braden@chromium.org>wrote:
>
>> Let's see how quickly they react to the new ticket.
>>
>> Braden
>>
>>
>> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fil@adobe.com> wrote:
>>
>> > My intuition is we'll need to bump the infra guys on irc..
>> >
>> > On 6/10/13 1:16 PM, "Braden Shepherdson" <braden@chromium.org> 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
>> > ><braden@chromium.org>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 <benn.mapes@gmail.com>
>> > wrote:
>> > >>
>> > >>> I'm fine with option 2, lets get this done.
>> > >>>
>> > >>>
>> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fil@adobe.com>
wrote:
>> > >>>
>> > >>> > SGTM
>> > >>> >
>> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <braden@chromium.org>
>> > 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 <fil@adobe.com>
>>wrote:
>> > >>> > >
>> > >>> > >> 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