{"thread":{"id":"18247","subject":"[RFC] rerere to recreate topic branches","startedAt":"2009-03-10T09:32:00Z","lastAt":"2009-03-10T10:18:40Z","messageCount":2,"participants":["Uwe Kleine-König","Ingo Molnar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"107557","messageId":"20090310093200.GA12931@pengutronix.de","threadId":"18247","inReplyTo":null,"subject":"[RFC] rerere to recreate topic branches","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2009-03-10T09:32:00Z","receivedAt":"2009-03-10T09:32:00Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nIngo sent a similar mail some time ago[1], that's why I Cc: him.\n\nFor TopGit I want something similar as Ingo for -tip (I think): recreate\na branch with a cleaned up history but without throwing away merge\nresolutions.\n\nI think most points from Ingo's mail are already addressed.  Let's see\nif my mail is equally successful :-)\n\nOne step that wasn't in Ingo's list, but I consider nice is the\nfollowing workflow:\n\n\texport GIT_RR_CACHE=$(mktemp -d)\n\tgit rerere add-to-cache-from origin..$branch_to_rebuild\n\tscript doing the actual rebuild\n\ntogether with rerere.autocommit=true.  Even though rerere is not save in\ngeneral, this workflow seems fine.  I think with this approach sharing\nthe rr-cache isn't an issue anymore and merge conflicts that need manual\nwork should be quite rare, even if you do it for the first time.\n\nI just found contrib/rerere-train.sh, which already addresses a part of\nmy plan.\n\nOne of my further goals is to do as much transformation without touching\nthe working copy (to gain speed and comfort).  For that I would need git\nmerge to operate on an index, only and only fall back to using the\nworking copy if manual intervention is needed.\n\nI have to admit that up to now I didn't look into the corresponding\ncode, so consider this mail (only) as starter to collect ideas and\ncomments.\n\nBest regards\nUwe\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/85176/\n\n-- \nPengutronix e.K.                              | Uwe Kleine-König            |\nIndustrial Linux Solutions                    | http://www.pengutronix.de/  |\n"},{"id":"107561","messageId":"20090310101840.GA21234@elte.hu","threadId":"18247","inReplyTo":"20090310093200.GA12931@pengutronix.de","subject":"Re: [RFC] rerere to recreate topic branches","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2009-03-10T10:18:40Z","receivedAt":"2009-03-10T10:18:40Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:\n\n> Hello,\n> \n> Ingo sent a similar mail some time ago[1], that's why I Cc: \n> him.\n\n> [1] http://thread.gmane.org/gmane.comp.version-control.git/85176/\n\nJust a few generic comments - i have written that mail 8 months \nago.\n\nSince then our -tip workflow has shifted in the direction of \nwhat i'd call an \"append-mostly delta integration\" workflow.\n\nWhen i wrote that mail we used to do daily full reintegrations \nof 100-200 topic branches using git-rerere, but that was not \nreally feasible in the long run for two reasons:\n\n - back then a full integration took up to 30 minutes with over \n   a 100 branches and on a fast box - if it was all \n   problem-free.\n\n   [ It's much faster now both due to the speedups Git has done,\n     due to smarter scripting we do and due to me using an SSD \n     to host the -tip repo. ]\n\n - the full integration itself 'locked' the whole repo for a \n   long time. The old integration branch was destroyed and a new \n   one constructued - with 1000-2000 commits. This was fragile \n   in a number of ways.\n\n - if there was any problem during the integration (a bad \n   conflict resolution) it often had to be repeated which easily \n   pushed the time to do the integration to over an hour.\n\nSo full integration of 1000-2000 commits spread out into 100+ \ntopic branches required a lot of concentration and even then it \nwas too fragile.\n\nSo now we do full reintegrations only about every two weeks, \nplus we do finegrained per commit and per pull \"delta \nintegrations\" that is based on:\n\n DELTA_BRANCHES=$(git branch --no-merged | cut -c3-)\n git merge $DELTA_BRANCHES\n\nPlus we have the same finegrained topical setup that allows the \nspecific isolation of gone-bad topics without the collateral \ndamage of them holding the full tree and other contributors \nhostage.\n\nSo when a topic goes bad i dont revert nor do i destroy those \ncommits - i just rewind/reset the integration branch to before \nthe bad topic merge point, exclude the topic from \ndelta-integration (add it to a blacklist) and re-run the delta \nintegration and notify the people who caused the breakage. It's \nabout 30 seconds to do so there's no noticeable workflow hickup.\n\nWhen the fix comes in 1-2 days later, the 'bad' topic branch is \nreactivated and gets picked up by delta integration.\n\nSo all in one, delta integration is a lot less stressful in \npractice, and undo is possible and easy, as most of the \nbreakages are in fresh commits.\n\nIt's also very fast:\n\n earth4:~/tip> time todo-merge-all \n searching for updated branches ...\n excluded branches: core/kill-the-BKL tracing/dump-tracer\n Updated branches: tracing/ftrace\n merging tracing/ftrace ... Merge made by recursive.           \n  kernel/trace/trace_workqueue.c |   14 +++++++-------\n  1 files changed, 7 insertions(+), 7 deletions(-)\n merging linus ... ... merge done.                             \n\n real\t0m5.402s\n user\t0m5.002s\n sys\t0m0.445s\n\nEven though there are more than 400 branches it has to check, \n100 of which are active (==carry new commits relative to Linus's \nlatest kernel tree).\n\n\tIngo\n"}]}