cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Cordova CLI merge, new branch, INFRA ticket
Date Wed, 12 Jun 2013 21:04:04 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message