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 Wed, 29 May 2013 15:51:24 GMT
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