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