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:16:35 GMT
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