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:16:17 GMT
Er, I screwed up the clone URL there, but you know what I mean.


On Wed, May 29, 2013 at 11:15 AM, Braden Shepherdson <braden@chromium.org>wrote:

> 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