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