Er, I screwed up the clone URL there, but you know what I mean.
On Wed, May 29, 2013 at 11:15 AM, Braden Shepherdson <bra...@chromium.org>wrote: > This is what I was afraid the list would say. Since two people have said > to go with option 1 (never mind the history, just delete and replace > everything on master) now, I will ask: why? > > There are two scenarios: whether or not you have outstanding changes. > > If you have outstanding changes, you're going to have a bad time merging > them anyway, since many files will change. > > If you don't have outstanding changes, then re-cloning looks like this: > cd .. > rm -rf cordova-cli > git clone https://git-wip-us.apache.org/repos/asf/cordova-plugman.git > which is hardly an involved and painful process. > > If we do this delete/recreate of every file, the big change becomes a > black hole. It becomes impossible to git blame across it, and difficult to > look at the log or to bisect. Every file will have changed at this point. > We are almost deleting all previous history of the repo and beginning again > with a "initial import" commit. I view that as a much steeper price, which > we will never stop paying, than asking a dozen people with cordova-cli > checked out to delete and re-clone it, once. > > Braden > > > > On Wed, May 29, 2013 at 11:06 AM, Jeffrey Heifetz <jheif...@blackberry.com > > wrote: > >> I'd go with tangled history over forced re-clone. >> >> On 13-05-29 11: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. >> >> > > > >> >> > > >> >> > >> >> >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute non-public >> information. Any use of this information by anyone other than the intended >> recipient is prohibited. If you have received this transmission in error, >> please immediately reply to the sender and delete this information from >> your system. Use, dissemination, distribution, or reproduction of this >> transmission by unintended recipients is not authorized and may be unlawful. >> > >
