Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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.

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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 <br...@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" <br...@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 <pu...@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.
>>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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
<jh...@blackberry.com>wrote:

> I'd go with tangled history over forced re-clone.
>
> On 13-05-29 11:00 AM, "Braden Shepherdson" <br...@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 <pu...@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.
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

Looks like Fil got it right. I tried to rename and delete the old master
branch originally, and got the same error. Good catch from them about the
Github mirrors; I agree with Fil that deleting and recreating them is the
safe thing. But they might have outstanding PRs and bugs, so that's an
unfortunate complication.

Braden


On Wed, Jun 12, 2013 at 5:11 PM, Filip Maj <fi...@adobe.com> wrote:

> Cheers!
>
> On 6/12/13 2:04 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >That sounds right, I'll see about poking Braden to peek too.
> >
> >
> >On Wed, Jun 12, 2013 at 4:59 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> Replied, but would be good for others to take a peak at this thread as I
> >> am not 100% sure that my answers are correct..
> >>
> >> On 6/12/13 1:18 PM, "Benn Mapes" <be...@gmail.com> wrote:
> >>
> >> >What are we doing about
> >>https://issues.apache.org/jira/browse/INFRA-6302?
> >> >
> >> >I think they're afraid of messing things up for us. Does someone want
> >>to
> >> >answer his questions? (I'm not sure what the correct approach is...)
> >> >
> >> >
> >> >On Mon, Jun 10, 2013 at 1:27 PM, Braden Shepherdson
> >> ><br...@chromium.org>wrote:
> >> >
> >> >> Let's see how quickly they react to the new ticket.
> >> >>
> >> >> Braden
> >> >>
> >> >>
> >> >> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >>
> >> >> > My intuition is we'll need to bump the infra guys on irc..
> >> >> >
> >> >> > On 6/10/13 1:16 PM, "Braden Shepherdson" <br...@chromium.org>
> >>wrote:
> >> >> >
> >> >> > >Since it's been nearly two weeks with no movement despite a bump,
> >> >>I've
> >> >> > >closed the old INFRA ticket and opened a new one[1] stating that
> >>we
> >> >> intend
> >> >> > >to move forward with option 2.
> >> >> > >
> >> >> > >Braden
> >> >> > >
> >> >> > >[1] https://issues.apache.org/jira/browse/INFRA-6374
> >> >> > >
> >> >> > >
> >> >> > >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
> >> >> > ><br...@chromium.org>wrote:
> >> >> > >
> >> >> > >> Waiting on INFRA. I've already told them that we want to go
> >>with 2.
> >> >> > >>
> >> >> > >> Braden
> >> >> > >>
> >> >> > >>
> >> >> > >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes
> >><be...@gmail.com>
> >> >> > wrote:
> >> >> > >>
> >> >> > >>> I'm fine with option 2, lets get this done.
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com>
> >>wrote:
> >> >> > >>>
> >> >> > >>> > SGTM
> >> >> > >>> >
> >> >> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson"
> >><br...@chromium.org>
> >> >> > wrote:
> >> >> > >>> >
> >> >> > >>> > >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 <fi...@adobe.com>
> >> >>wrote:
> >> >> > >>> > >
> >> >> > >>> > >> Thanks for taking that on Braden
> >> >> > >>> > >>
> >> >> > >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson"
> >> >><br...@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
> >> >> > >>> > >> >> ><br...@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
> >> >> > >>> > >><mm...@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
> >> >> > >>> > >> >><ic...@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
> >> >> > >>> > >><pu...@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.
> >> >> > >>> > >> >> >>
> >> >> > >>> > >> >>
> >> >> > >>> > >> >>
> >> >> > >>> > >>
> >> >> > >>> > >>
> >> >> > >>> >
> >> >> > >>> >
> >> >> > >>>
> >> >> > >>
> >> >> > >>
> >> >> >
> >> >> >
> >> >>
> >>
> >>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Filip Maj <fi...@adobe.com>]

Cheers!

On 6/12/13 2:04 PM, "Michal Mocny" <mm...@chromium.org> wrote:

>That sounds right, I'll see about poking Braden to peek too.
>
>
>On Wed, Jun 12, 2013 at 4:59 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Replied, but would be good for others to take a peak at this thread as I
>> am not 100% sure that my answers are correct..
>>
>> On 6/12/13 1:18 PM, "Benn Mapes" <be...@gmail.com> wrote:
>>
>> >What are we doing about
>>https://issues.apache.org/jira/browse/INFRA-6302?
>> >
>> >I think they're afraid of messing things up for us. Does someone want
>>to
>> >answer his questions? (I'm not sure what the correct approach is...)
>> >
>> >
>> >On Mon, Jun 10, 2013 at 1:27 PM, Braden Shepherdson
>> ><br...@chromium.org>wrote:
>> >
>> >> Let's see how quickly they react to the new ticket.
>> >>
>> >> Braden
>> >>
>> >>
>> >> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fi...@adobe.com> wrote:
>> >>
>> >> > My intuition is we'll need to bump the infra guys on irc..
>> >> >
>> >> > On 6/10/13 1:16 PM, "Braden Shepherdson" <br...@chromium.org>
>>wrote:
>> >> >
>> >> > >Since it's been nearly two weeks with no movement despite a bump,
>> >>I've
>> >> > >closed the old INFRA ticket and opened a new one[1] stating that
>>we
>> >> intend
>> >> > >to move forward with option 2.
>> >> > >
>> >> > >Braden
>> >> > >
>> >> > >[1] https://issues.apache.org/jira/browse/INFRA-6374
>> >> > >
>> >> > >
>> >> > >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
>> >> > ><br...@chromium.org>wrote:
>> >> > >
>> >> > >> Waiting on INFRA. I've already told them that we want to go
>>with 2.
>> >> > >>
>> >> > >> Braden
>> >> > >>
>> >> > >>
>> >> > >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes
>><be...@gmail.com>
>> >> > wrote:
>> >> > >>
>> >> > >>> I'm fine with option 2, lets get this done.
>> >> > >>>
>> >> > >>>
>> >> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com>
>>wrote:
>> >> > >>>
>> >> > >>> > SGTM
>> >> > >>> >
>> >> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson"
>><br...@chromium.org>
>> >> > wrote:
>> >> > >>> >
>> >> > >>> > >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 <fi...@adobe.com>
>> >>wrote:
>> >> > >>> > >
>> >> > >>> > >> Thanks for taking that on Braden
>> >> > >>> > >>
>> >> > >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson"
>> >><br...@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 <fi...@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
>> >> > >>> > >> >> ><br...@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
>> >> > >>> > >><mm...@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
>> >> > >>> > >> >><ic...@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
>> >> > >>> > >><pu...@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.
>> >> > >>> > >> >> >>
>> >> > >>> > >> >>
>> >> > >>> > >> >>
>> >> > >>> > >>
>> >> > >>> > >>
>> >> > >>> >
>> >> > >>> >
>> >> > >>>
>> >> > >>
>> >> > >>
>> >> >
>> >> >
>> >>
>>
>>

Re: Cordova CLI merge, new branch, INFRA ticket

[Michal Mocny <mm...@chromium.org>]

That sounds right, I'll see about poking Braden to peek too.


On Wed, Jun 12, 2013 at 4:59 PM, Filip Maj <fi...@adobe.com> wrote:

> Replied, but would be good for others to take a peak at this thread as I
> am not 100% sure that my answers are correct..
>
> On 6/12/13 1:18 PM, "Benn Mapes" <be...@gmail.com> wrote:
>
> >What are we doing about https://issues.apache.org/jira/browse/INFRA-6302?
> >
> >I think they're afraid of messing things up for us. Does someone want to
> >answer his questions? (I'm not sure what the correct approach is...)
> >
> >
> >On Mon, Jun 10, 2013 at 1:27 PM, Braden Shepherdson
> ><br...@chromium.org>wrote:
> >
> >> Let's see how quickly they react to the new ticket.
> >>
> >> Braden
> >>
> >>
> >> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fi...@adobe.com> wrote:
> >>
> >> > My intuition is we'll need to bump the infra guys on irc..
> >> >
> >> > On 6/10/13 1:16 PM, "Braden Shepherdson" <br...@chromium.org> wrote:
> >> >
> >> > >Since it's been nearly two weeks with no movement despite a bump,
> >>I've
> >> > >closed the old INFRA ticket and opened a new one[1] stating that we
> >> intend
> >> > >to move forward with option 2.
> >> > >
> >> > >Braden
> >> > >
> >> > >[1] https://issues.apache.org/jira/browse/INFRA-6374
> >> > >
> >> > >
> >> > >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
> >> > ><br...@chromium.org>wrote:
> >> > >
> >> > >> Waiting on INFRA. I've already told them that we want to go with 2.
> >> > >>
> >> > >> Braden
> >> > >>
> >> > >>
> >> > >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <be...@gmail.com>
> >> > wrote:
> >> > >>
> >> > >>> I'm fine with option 2, lets get this done.
> >> > >>>
> >> > >>>
> >> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:
> >> > >>>
> >> > >>> > SGTM
> >> > >>> >
> >> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org>
> >> > wrote:
> >> > >>> >
> >> > >>> > >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 <fi...@adobe.com>
> >>wrote:
> >> > >>> > >
> >> > >>> > >> Thanks for taking that on Braden
> >> > >>> > >>
> >> > >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson"
> >><br...@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 <fi...@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
> >> > >>> > >> >> ><br...@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
> >> > >>> > >><mm...@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
> >> > >>> > >> >><ic...@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
> >> > >>> > >><pu...@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.
> >> > >>> > >> >> >>
> >> > >>> > >> >>
> >> > >>> > >> >>
> >> > >>> > >>
> >> > >>> > >>
> >> > >>> >
> >> > >>> >
> >> > >>>
> >> > >>
> >> > >>
> >> >
> >> >
> >>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Filip Maj <fi...@adobe.com>]

Replied, but would be good for others to take a peak at this thread as I
am not 100% sure that my answers are correct..

On 6/12/13 1:18 PM, "Benn Mapes" <be...@gmail.com> wrote:

>What are we doing about https://issues.apache.org/jira/browse/INFRA-6302?
>
>I think they're afraid of messing things up for us. Does someone want to
>answer his questions? (I'm not sure what the correct approach is...)
>
>
>On Mon, Jun 10, 2013 at 1:27 PM, Braden Shepherdson
><br...@chromium.org>wrote:
>
>> Let's see how quickly they react to the new ticket.
>>
>> Braden
>>
>>
>> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>> > My intuition is we'll need to bump the infra guys on irc..
>> >
>> > On 6/10/13 1:16 PM, "Braden Shepherdson" <br...@chromium.org> wrote:
>> >
>> > >Since it's been nearly two weeks with no movement despite a bump,
>>I've
>> > >closed the old INFRA ticket and opened a new one[1] stating that we
>> intend
>> > >to move forward with option 2.
>> > >
>> > >Braden
>> > >
>> > >[1] https://issues.apache.org/jira/browse/INFRA-6374
>> > >
>> > >
>> > >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
>> > ><br...@chromium.org>wrote:
>> > >
>> > >> Waiting on INFRA. I've already told them that we want to go with 2.
>> > >>
>> > >> Braden
>> > >>
>> > >>
>> > >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <be...@gmail.com>
>> > wrote:
>> > >>
>> > >>> I'm fine with option 2, lets get this done.
>> > >>>
>> > >>>
>> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:
>> > >>>
>> > >>> > SGTM
>> > >>> >
>> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org>
>> > wrote:
>> > >>> >
>> > >>> > >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 <fi...@adobe.com>
>>wrote:
>> > >>> > >
>> > >>> > >> Thanks for taking that on Braden
>> > >>> > >>
>> > >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson"
>><br...@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 <fi...@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
>> > >>> > >> >> ><br...@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
>> > >>> > >><mm...@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
>> > >>> > >> >><ic...@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
>> > >>> > >><pu...@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.
>> > >>> > >> >> >>
>> > >>> > >> >>
>> > >>> > >> >>
>> > >>> > >>
>> > >>> > >>
>> > >>> >
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> >
>> >
>>

Re: Cordova CLI merge, new branch, INFRA ticket

[Benn Mapes <be...@gmail.com>]

What are we doing about https://issues.apache.org/jira/browse/INFRA-6302?

I think they're afraid of messing things up for us. Does someone want to
answer his questions? (I'm not sure what the correct approach is...)


On Mon, Jun 10, 2013 at 1:27 PM, Braden Shepherdson <br...@chromium.org>wrote:

> Let's see how quickly they react to the new ticket.
>
> Braden
>
>
> On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fi...@adobe.com> wrote:
>
> > My intuition is we'll need to bump the infra guys on irc..
> >
> > On 6/10/13 1:16 PM, "Braden Shepherdson" <br...@chromium.org> wrote:
> >
> > >Since it's been nearly two weeks with no movement despite a bump, I've
> > >closed the old INFRA ticket and opened a new one[1] stating that we
> intend
> > >to move forward with option 2.
> > >
> > >Braden
> > >
> > >[1] https://issues.apache.org/jira/browse/INFRA-6374
> > >
> > >
> > >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
> > ><br...@chromium.org>wrote:
> > >
> > >> Waiting on INFRA. I've already told them that we want to go with 2.
> > >>
> > >> Braden
> > >>
> > >>
> > >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <be...@gmail.com>
> > wrote:
> > >>
> > >>> I'm fine with option 2, lets get this done.
> > >>>
> > >>>
> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:
> > >>>
> > >>> > SGTM
> > >>> >
> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org>
> > wrote:
> > >>> >
> > >>> > >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 <fi...@adobe.com> wrote:
> > >>> > >
> > >>> > >> Thanks for taking that on Braden
> > >>> > >>
> > >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@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
> > >>> > >> >> ><br...@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
> > >>> > >><mm...@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
> > >>> > >> >><ic...@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
> > >>> > >><pu...@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.
> > >>> > >> >> >>
> > >>> > >> >>
> > >>> > >> >>
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> >
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

Let's see how quickly they react to the new ticket.

Braden


On Mon, Jun 10, 2013 at 4:18 PM, Filip Maj <fi...@adobe.com> wrote:

> My intuition is we'll need to bump the infra guys on irc..
>
> On 6/10/13 1:16 PM, "Braden Shepherdson" <br...@chromium.org> wrote:
>
> >Since it's been nearly two weeks with no movement despite a bump, I've
> >closed the old INFRA ticket and opened a new one[1] stating that we intend
> >to move forward with option 2.
> >
> >Braden
> >
> >[1] https://issues.apache.org/jira/browse/INFRA-6374
> >
> >
> >On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
> ><br...@chromium.org>wrote:
> >
> >> Waiting on INFRA. I've already told them that we want to go with 2.
> >>
> >> Braden
> >>
> >>
> >> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <be...@gmail.com>
> wrote:
> >>
> >>> I'm fine with option 2, lets get this done.
> >>>
> >>>
> >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:
> >>>
> >>> > SGTM
> >>> >
> >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org>
> wrote:
> >>> >
> >>> > >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 <fi...@adobe.com> wrote:
> >>> > >
> >>> > >> Thanks for taking that on Braden
> >>> > >>
> >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@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 <mm...@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
> >>> > >> >> ><br...@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
> >>> > >><mm...@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
> >>> > >> >><ic...@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
> >>> > >><pu...@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.
> >>> > >> >> >>
> >>> > >> >>
> >>> > >> >>
> >>> > >>
> >>> > >>
> >>> >
> >>> >
> >>>
> >>
> >>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Filip Maj <fi...@adobe.com>]

My intuition is we'll need to bump the infra guys on irc..

On 6/10/13 1:16 PM, "Braden Shepherdson" <br...@chromium.org> wrote:

>Since it's been nearly two weeks with no movement despite a bump, I've
>closed the old INFRA ticket and opened a new one[1] stating that we intend
>to move forward with option 2.
>
>Braden
>
>[1] https://issues.apache.org/jira/browse/INFRA-6374
>
>
>On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson
><br...@chromium.org>wrote:
>
>> Waiting on INFRA. I've already told them that we want to go with 2.
>>
>> Braden
>>
>>
>> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <be...@gmail.com> wrote:
>>
>>> I'm fine with option 2, lets get this done.
>>>
>>>
>>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:
>>>
>>> > SGTM
>>> >
>>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org> wrote:
>>> >
>>> > >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 <fi...@adobe.com> wrote:
>>> > >
>>> > >> Thanks for taking that on Braden
>>> > >>
>>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@adobe.com> wrote:
>>> > >> >
>>> > >> >> Option 2! Let's move forward and get this sorted.
>>> > >> >>
>>> > >> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
>>> > >> >> ><br...@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
>>> > >><mm...@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
>>> > >> >><ic...@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
>>> > >><pu...@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.
>>> > >> >> >>
>>> > >> >>
>>> > >> >>
>>> > >>
>>> > >>
>>> >
>>> >
>>>
>>
>>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

Since it's been nearly two weeks with no movement despite a bump, I've
closed the old INFRA ticket and opened a new one[1] stating that we intend
to move forward with option 2.

Braden

[1] https://issues.apache.org/jira/browse/INFRA-6374


On Tue, Jun 4, 2013 at 2:46 PM, Braden Shepherdson <br...@chromium.org>wrote:

> Waiting on INFRA. I've already told them that we want to go with 2.
>
> Braden
>
>
> On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <be...@gmail.com> wrote:
>
>> I'm fine with option 2, lets get this done.
>>
>>
>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:
>>
>> > SGTM
>> >
>> > On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org> wrote:
>> >
>> > >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 <fi...@adobe.com> wrote:
>> > >
>> > >> Thanks for taking that on Braden
>> > >>
>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@adobe.com> wrote:
>> > >> >
>> > >> >> Option 2! Let's move forward and get this sorted.
>> > >> >>
>> > >> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
>> > >> >> ><br...@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
>> > >><mm...@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
>> > >> >><ic...@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
>> > >><pu...@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.
>> > >> >> >>
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> >
>> >
>>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

Waiting on INFRA. I've already told them that we want to go with 2.

Braden


On Tue, Jun 4, 2013 at 2:41 PM, Benn Mapes <be...@gmail.com> wrote:

> I'm fine with option 2, lets get this done.
>
>
> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:
>
> > SGTM
> >
> > On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org> wrote:
> >
> > >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 <fi...@adobe.com> wrote:
> > >
> > >> Thanks for taking that on Braden
> > >>
> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@adobe.com> wrote:
> > >> >
> > >> >> Option 2! Let's move forward and get this sorted.
> > >> >>
> > >> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
> > >> >> ><br...@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
> > >><mm...@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
> > >> >><ic...@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
> > >><pu...@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.
> > >> >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> >
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Benn Mapes <be...@gmail.com>]

I'm fine with option 2, lets get this done.


On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fi...@adobe.com> wrote:

> SGTM
>
> On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org> wrote:
>
> >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 <fi...@adobe.com> wrote:
> >
> >> Thanks for taking that on Braden
> >>
> >> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@adobe.com> wrote:
> >> >
> >> >> Option 2! Let's move forward and get this sorted.
> >> >>
> >> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
> >> >> ><br...@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
> >><mm...@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
> >> >><ic...@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
> >><pu...@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.
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Filip Maj <fi...@adobe.com>]

SGTM

On 6/4/13 10:44 AM, "Braden Shepherdson" <br...@chromium.org> wrote:

>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 <fi...@adobe.com> wrote:
>
>> Thanks for taking that on Braden
>>
>> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@adobe.com> wrote:
>> >
>> >> Option 2! Let's move forward and get this sorted.
>> >>
>> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
>> >> ><br...@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
>><mm...@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
>> >><ic...@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
>><pu...@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.
>> >> >>
>> >>
>> >>
>>
>>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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 <fi...@adobe.com> wrote:

> Thanks for taking that on Braden
>
> On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@adobe.com> wrote:
> >
> >> Option 2! Let's move forward and get this sorted.
> >>
> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
> >> ><br...@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 <mm...@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
> >><ic...@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 <pu...@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.
> >> >>
> >>
> >>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Filip Maj <fi...@adobe.com>]

Thanks for taking that on Braden

On 6/3/13 10:15 AM, "Braden Shepherdson" <br...@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 <fi...@adobe.com> wrote:
>
>> Option 2! Let's move forward and get this sorted.
>>
>> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
>> ><br...@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 <mm...@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
>><ic...@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 <pu...@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.
>> >>
>>
>>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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 <fi...@adobe.com> wrote:

> Option 2! Let's move forward and get this sorted.
>
> On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
> ><br...@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 <mm...@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 <ic...@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 <pu...@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.
> >>
>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Filip Maj <fi...@adobe.com>]

Option 2! Let's move forward and get this sorted.

On 5/29/13 1:17 PM, "Jesse MacFadyen" <pu...@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 <mm...@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
><br...@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 <mm...@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 <ic...@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 <pu...@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.
>>

Re: Cordova CLI merge, new branch, INFRA ticket

[Jesse MacFadyen <pu...@gmail.com>]

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 <mm...@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 <br...@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 <mm...@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 <ic...@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 <pu...@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.
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Michal Mocny <mm...@chromium.org>]

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 <br...@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 <mm...@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 <ic...@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 <pu...@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.
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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 <mm...@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 <ic...@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 <pu...@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.
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Michal Mocny <mm...@chromium.org>]

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 <ic...@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 <pu...@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.
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Ian Clelland <ic...@google.com>]

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 <br...@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 <pu...@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.
> >> > > >
> >> > >
> >> >
> >>
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Brian LeRoux <b...@brian.io>]

ya the rename easiest

On Wed, May 29, 2013 at 8:00 AM, Braden Shepherdson <br...@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 <pu...@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.
>> > > >
>> > >
>> >
>>

Re: Cordova CLI merge, new branch, INFRA ticket

[Jeffrey Heifetz <jh...@blackberry.com>]

I'd go with tangled history over forced re-clone.

On 13-05-29 11:00 AM, "Braden Shepherdson" <br...@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 <pu...@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.

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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 <pu...@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.
> > > >
> > >
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Jesse <pu...@gmail.com>]

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 <br...@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.
> > >
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Braden Shepherdson <br...@chromium.org>]

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 <ag...@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.
> >
>

Re: Cordova CLI merge, new branch, INFRA ticket

[Andrew Grieve <ag...@chromium.org>]

Could we merge master2 into master with:

git merge --strategy-option=theirs master2


On Thu, May 23, 2013 at 6:19 PM, Braden Shepherdson <br...@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.
>