cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Cordova CLI merge, new branch, INFRA ticket
Date Tue, 04 Jun 2013 17:51:41 GMT
SGTM

On 6/4/13 10:44 AM, "Braden Shepherdson" <braden@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 <fil@adobe.com> wrote:
>
>> Thanks for taking that on Braden
>>
>> On 6/3/13 10:15 AM, "Braden Shepherdson" <braden@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
>> >> ><braden@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
>><mmocny@chromium.org>
>> >> >> wrote:
>> >> >>
>> >> >>> Can we go with (1) and still keep master2 around (perhaps rename
>>it
>> >>to
>> >> >>> something sensible) so that we can still get full history but
>>with
>> >>one
>> >> >>> level of indirection:
>> >> >>> - The mega commit could have a commit message such as "THIS
WAS A
>> >>HACKY
>> >> >>> MERGE, FOR REAL HISTORY LOOK IN THE OLD_FUTURE BRANCH"
>> >> >>> - When you bit blame and see that as the commit responsible,
you
>> >>know
>> >> >>>you
>> >> >>> have to git blame again in the other branch
>> >> >>>
>> >> >>> -Michal
>> >> >>>
>> >> >>>
>> >> >>> On Wed, May 29, 2013 at 11:22 AM, Ian Clelland
>> >><iclelland@google.com>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> SInce 2 and 3 both require re-cloning the repository, I'd
much
>> >>rather
>> >> >> go
>> >> >>>> with 2, and rename the branches appropriately.
>> >> >>>>
>> >> >>>>
>> >> >>>> On Wed, May 29, 2013 at 11:11 AM, Brian LeRoux <b@brian.io>
>>wrote:
>> >> >>>>
>> >> >>>>> ya the rename easiest
>> >> >>>>>
>> >> >>>>> On Wed, May 29, 2013 at 8:00 AM, Braden Shepherdson
<
>> >> >>> braden@chromium.org
>> >> >>>>>
>> >> >>>>> wrote:
>> >> >>>>>> I'll keep this thread up to date with INFRA's responses.
>> >> >>>>>>
>> >> >>>>>> I asked INFRA about options and their implications.
These are
>>the
>> >> >>> four
>> >> >>>>>> options I described, after I was informed that
our original
>> >>request
>> >> >>>> would
>> >> >>>>>> actually require everyone to re-clone the repo.
>> >> >>>>>>
>> >> >>>>>> 1. Check out master, delete all the files, copy
in all the
>>files
>> >> >>> from
>> >> >>>>>> master2, check them all in. This keep the branching
the same,
>>and
>> >> >> no
>> >> >>>> one
>> >> >>>>>> would need to re-clone. But it also makes the history
nearly
>> >> >> useless
>> >> >>>>> before
>> >> >>>>>> that point. I dislike this option, but it's there.
>> >> >>>>>>
>> >> >>>>>> 2. Rename master to old_master or similar, and
rename master2
>>to
>> >> >>>> master.
>> >> >>>>>> Since everyone is re-cloning anyway, this is possible.
Keeps
>>the
>> >> >> name
>> >> >>>>>> consistent. This might be nasty if someone tries
to merge
>>between
>> >> >> an
>> >> >>>> old
>> >> >>>>>> master and the new master. Unless git can notice
that things
>>are
>> >> >>> wrong
>> >> >>>>> and
>> >> >>>>>> they should re-clone.
>> >> >>>>>>
>> >> >>>>>> 3. My original request to move HEAD. Exposes the
master2 name
>>and
>> >> >>>>> requires
>> >> >>>>>> everyone to use it. Still requires a re-clone.
>> >> >>>>>>
>> >> >>>>>> 4. Abandon the repository and recreate it under
a new name,
>> >>pushing
>> >> >>>> only
>> >> >>>>>> master2 as the new master. Requires a re-clone
and changing
>>the
>> >> >> name.
>> >> >>>>>> Probably not, but it's an option.
>> >> >>>>>>
>> >> >>>>>> What do people think? I'm most partial to 2, since
it
>>preserves
>> >>the
>> >> >>>>> master
>> >> >>>>>> name and it's hard to avoid recloning.
>> >> >>>>>>
>> >> >>>>>> Braden
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On Tue, May 28, 2013 at 8:07 PM, Jesse
>><purplecabbage@gmail.com>
>> >> >>>> wrote:
>> >> >>>>>>
>> >> >>>>>>> What is the resolution on this?
>> >> >>>>>>>
>> >> >>>>>>> My opinion: History is in the past, move on.
>> >> >>>>>>> I think it's okay if it is history is messy,
or even if has a
>> >>few
>> >> >>>>> duplicate
>> >> >>>>>>> commits.  Tangles and all.
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> @purplecabbage
>> >> >>>>>>> risingj.com
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On Fri, May 24, 2013 at 7:05 AM, Braden Shepherdson
<
>> >> >>>>> braden@chromium.org
>> >> >>>>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>> I think so, but only if we're prepared
to keep the tangled
>> >> >> history
>> >> >>>> and
>> >> >>>>>>>> duplicate about 30 commits. Several mistakes
were made with
>>the
>> >> >>>>> branching
>> >> >>>>>>>> and rebasing of things on master, and there's
a lot of
>> >> >> duplication
>> >> >>>> and
>> >> >>>>>>>> confusion in the history.
>> >> >>>>>>>>
>> >> >>>>>>>> When you get in this morning, I can show
you the whiteboard
>> >> >>> diagram
>> >> >>>> of
>> >> >>>>>>> the
>> >> >>>>>>>> long version above, and then you can look
at the histories
>>of
>> >> >>> master
>> >> >>>>> and
>> >> >>>>>>>> master2 on GitX. I think you'll agree it's
worth moving
>>forward
>> >> >>> with
>> >> >>>>>>>> master2.
>> >> >>>>>>>>
>> >> >>>>>>>> Braden
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> On Thu, May 23, 2013 at 11:16 PM, Andrew
Grieve <
>> >> >>>> agrieve@chromium.org
>> >> >>>>>>>>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>> Could we merge master2 into master
with:
>> >> >>>>>>>>>
>> >> >>>>>>>>> git merge --strategy-option=theirs
master2
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> On Thu, May 23, 2013 at 6:19 PM, Braden
Shepherdson <
>> >> >>>>>>> braden@chromium.org
>> >> >>>>>>>>>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>>> tl;dr version: cordova-cli now
has a master2 branch that
>> >> >>> should
>> >> >>>> be
>> >> >>>>>>>>> treated
>> >> >>>>>>>>>> as master going forward. DO NOT
use master or future
>> >> >> anymore.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Short version:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> - I tried to merge future and master.
>> >> >>>>>>>>>> - I couldn't because the history
is a train wreck. The
>> >> >>> morbidly
>> >> >>>>>>> curious
>> >> >>>>>>>>>> should see [2].
>> >> >>>>>>>>>> - Ian and I dug through the history,
and played CSI until
>>we
>> >> >>>>> figured
>> >> >>>>>>>> out
>> >> >>>>>>>>>> what had happened, and found a
sensible way to
>>reconstruct a
>> >> >>>> sane
>> >> >>>>>>>> master
>> >> >>>>>>>>>> branch.
>> >> >>>>>>>>>> - This branch merged fairly neatly
with future.
>> >> >>>>>>>>>> - It is now committed as the new
branch master2.
>> >> >>>>>>>>>> - The original master branch is
deprecated.
>> >> >>>>>>>>>> - I have filed an INFRA ticket[1]
to get them to point
>>HEAD
>> >> >> at
>> >> >>>>>>> master2,
>> >> >>>>>>>>> and
>> >> >>>>>>>>>> delete the old master branch.
>> >> >>>>>>>>>> - Use master2 from now on. DO NOT
touch the old master or
>> >> >>> future
>> >> >>>>>>>> branches
>> >> >>>>>>>>>> anymore.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> I'll keep the list updated on the
state of the INFRA
>>ticket.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Braden
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> [1] https://issues.apache.org/jira/browse/INFRA-6302
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> [2] Long version:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> A long time ago, I forked cli's
master to create future. I
>> >> >>>>> committed
>> >> >>>>>>> a
>> >> >>>>>>>>>> half-dozen changes or so. Sometime
later, a 2.7.x branch
>>was
>> >> >>>>> forked
>> >> >>>>>>>> /from
>> >> >>>>>>>>>> future/. Several changes were made
here. Later it was
>>merged
>> >> >>>> back
>> >> >>>>> in,
>> >> >>>>>>>> /to
>> >> >>>>>>>>>> master/. The same changes were
later rebased onto master
>>and
>> >> >>>>>>> committed
>> >> >>>>>>>>>> again, duplicating them. Then this
branch was merged with
>> >> >>> master
>> >> >>>>>>> again,
>> >> >>>>>>>>>> creating a /third/ copy of the
changes originally from
>>this
>> >> >>>> 2.7.x
>> >> >>>>>>>> branch.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Meanwhile, some of the changes
from future were reverted
>>by
>> >> >>> hand
>> >> >>>>> (as
>> >> >>>>>>>>>> opposed to with git revert) in
master.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Finally some new changes were made
to future and master.
>>It
>> >> >>>> looks,
>> >> >>>>>>>>>> according to git, like there are
only these changes on the
>> >> >>>> future
>> >> >>>>>>>> branch,
>> >> >>>>>>>>>> since the earlier ones were merged
by accident some time
>> >> >> ago.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> When I came along and tried to
merge master and future in
>> >> >>> either
>> >> >>>>>>>>> direction,
>> >> >>>>>>>>>> or rebase in either direction,
those older future changes
>> >> >>> stayed
>> >> >>>>>>>> deleted,
>> >> >>>>>>>>>> because according to git they were
made on the same
>>branch.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Moral of the story: Don't take
a branch off master (like
>> >> >>>> future),
>> >> >>>>>>> fork
>> >> >>>>>>>>> it,
>> >> >>>>>>>>>> commit to it, and then merge it
back to master. That's
>>what
>> >> >>>>> started
>> >> >>>>>>>> most
>> >> >>>>>>>>> of
>> >> >>>>>>>>>> the insanity, because now future
is partially merged into
>> >> >>> master
>> >> >>>>> even
>> >> >>>>>>>>>> though it's not being treated that
way.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> I need a drink.
>> >> >>
>> >>
>> >>
>>
>>


Mime
View raw message