cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benn Mapes <benn.ma...@gmail.com>
Subject Re: Cordova CLI merge, new branch, INFRA ticket
Date Tue, 04 Jun 2013 18:41:07 GMT
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