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 <f...@adobe.com> wrote: > Cheers! > > On 6/12/13 2:04 PM, "Michal Mocny" <mmo...@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 <f...@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.ma...@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 > >> ><bra...@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 <f...@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" <bra...@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 > >> >> > ><bra...@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.ma...@gmail.com> > >> >> > wrote: > >> >> > >> > >> >> > >>> I'm fine with option 2, lets get this done. > >> >> > >>> > >> >> > >>> > >> >> > >>> On Tue, Jun 4, 2013 at 10:51 AM, Filip Maj <f...@adobe.com> > >>wrote: > >> >> > >>> > >> >> > >>> > SGTM > >> >> > >>> > > >> >> > >>> > On 6/4/13 10:44 AM, "Braden Shepherdson" > >><bra...@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 <f...@adobe.com> > >> >>wrote: > >> >> > >>> > > > >> >> > >>> > >> Thanks for taking that on Braden > >> >> > >>> > >> > >> >> > >>> > >> On 6/3/13 10:15 AM, "Braden Shepherdson" > >> >><bra...@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 <f...@adobe.com > > > >> >> wrote: > >> >> > >>> > >> > > >> >> > >>> > >> >> Option 2! Let's move forward and get this sorted. > >> >> > >>> > >> >> > >> >> > >>> > >> >> On 5/29/13 1:17 PM, "Jesse MacFadyen" < > >> >> purplecabb...@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 < > >> >> mmo...@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 > >> >> > >>> > >> >> ><bra...@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 > >> >> > >>> > >><mmo...@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 > >> >> > >>> > >> >><iclell...@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 > >> >>< > >> >> > >>> > >> >> >>> bra...@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 > >> >> > >>> > >><purplecabb...@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 < > >> >> > >>> > >> >> >>>>> bra...@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 < > >> >> > >>> > >> >> >>>> agri...@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 < > >> >> > >>> > >> >> >>>>>>> bra...@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. > >> >> > >>> > >> >> >> > >> >> > >>> > >> >> > >> >> > >>> > >> >> > >> >> > >>> > >> > >> >> > >>> > >> > >> >> > >>> > > >> >> > >>> > > >> >> > >>> > >> >> > >> > >> >> > >> > >> >> > > >> >> > > >> >> > >> > >> > >
