cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@google.com>
Subject Re: Cordova CLI merge, new branch, INFRA ticket
Date Wed, 29 May 2013 15:22:45 GMT
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