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 17:44:36 GMT
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