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 Tue, 04 Jun 2013 18:46:14 GMT
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