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:15:42 GMT
This is what I was afraid the list would say. Since two people have said to
go with option 1 (never mind the history, just delete and replace
everything on master) now, I will ask: why?

There are two scenarios: whether or not you have outstanding changes.

If you have outstanding changes, you're going to have a bad time merging
them anyway, since many files will change.

If you don't have outstanding changes, then re-cloning looks like this:
cd ..
rm -rf cordova-cli
git clone https://git-wip-us.apache.org/repos/asf/cordova-plugman.git
which is hardly an involved and painful process.

If we do this delete/recreate of every file, the big change becomes a black
hole. It becomes impossible to git blame across it, and difficult to look
at the log or to bisect. Every file will have changed at this point. We are
almost deleting all previous history of the repo and beginning again with a
"initial import" commit. I view that as a much steeper price, which we will
never stop paying, than asking a dozen people with cordova-cli checked out
to delete and re-clone it, once.

Braden



On Wed, May 29, 2013 at 11:06 AM, Jeffrey Heifetz
<jheifetz@blackberry.com>wrote:

> I'd go with tangled history over forced re-clone.
>
> On 13-05-29 11: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.
> >> > > >
> >> > >
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message