cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Cordova CLI merge, new branch, INFRA ticket
Date Mon, 10 Jun 2013 20:27:35 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message