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 Wed, 12 Jun 2013 21:11:27 GMT
Cheers!

On 6/12/13 2:04 PM, "Michal Mocny" <mmocny@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 <fil@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" <benn.mapes@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
>> ><braden@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 <fil@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" <braden@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
>> >> > ><braden@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
>><benn.mapes@gmail.com>
>> >> > wrote:
>> >> > >>
>> >> > >>> I'm fine with option 2, lets get this done.
>> >> > >>>
>> >> > >>>
>> >> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <fil@adobe.com>
>>wrote:
>> >> > >>>
>> >> > >>> > 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