{"thread":{"id":"9584","subject":"How to do a reverse rebase?","startedAt":"2007-08-20T05:32:37Z","lastAt":"2007-08-20T10:39:43Z","messageCount":5,"participants":["linux@horizon.com","Shawn O. Pearce","Junio C Hamano","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51041","messageId":"20070820053237.9349.qmail@science.horizon.com","threadId":"9584","inReplyTo":null,"subject":"How to do a reverse rebase?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-08-20T05:32:37Z","receivedAt":"2007-08-20T05:32:37Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"Okay, this is picayune whining, but when you've fixed all the big\nbugs...\n\nI don't want to rebase HEAD on *that*, but rather rebase *that*\non top of the current HEAD.\n\nSometimes I have a little debug hack on a branch by itself, and I\ndiscover that I need it again, so I want to rebase it on top of\ncurrent development.\n\nBut there's been a LOT of development in the meantime.  And if I do\n\ngit-rebase HEAD debug_hack\n\ngit first checks out debug_hack.  This takes a while and, more\nimportantly, every file modified in HEAD...debug_hack has its timestamp\ntouched and make(1) insists on recompiling it.\n\nI want to only modify the three files that are touched on the debug_hack\nbranch, so my recompile times aren't too long.\n\nCurrently, when I remember, I'll use git-cherry-pick and manually\nrename branches.\n\nIs there an easier way?  Or should I just learn StGit?\n"},{"id":"51043","messageId":"20070820055809.GZ27913@spearce.org","threadId":"9584","inReplyTo":"20070820053237.9349.qmail@science.horizon.com","subject":"Re: How to do a reverse rebase?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-20T05:58:09Z","receivedAt":"2007-08-20T05:58:09Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"linux@horizon.com wrote:\n> I don't want to rebase HEAD on *that*, but rather rebase *that*\n> on top of the current HEAD.\n...\n> Currently, when I remember, I'll use git-cherry-pick and manually\n> rename branches.\n> \n> Is there an easier way?\n\nI don't think so.  To do the merge of those files we need a working\ndirectory to operate in; that working directory is the one you have.\nIt sounds like what you want is this:\n\n\told=`git symbolic-ref HEAD` &&\n\tgit checkout HEAD^0 &&\n\tgit cherry-pick debug_hack &&\n\tgit branch -f debug_hack HEAD &&\n\tgit checkout $old\n\nWhat's really needed is to avoid switching to the branch, as\nyou mentioned.  Instead switch to the --onto (implied or given\nby user).  That way you can avoid updating a lot of files in the\nworking directory for no (compelling) reason.  Looking at the part of\ngit-rebase.sh that is affected by this (l.284-322) this is probably\nnot that difficult to improve.  Just a little bit of work to keep\ntrack of everything.\n\nOf course `git-rebase -i` is a completely different implementation,\nso now you are also talking about l.409-480 of that.  Ick.\n\n> Or should I just learn StGit?\n\nProbably.  It handles patch stacks easier than core Git.  Or so I'm\ntold.  I find `git rebase -i` good enough for my needs, but it going\nfirst to the debug_hack branch, then to the onto does sort of suck.\n\n-- \nShawn.\n"},{"id":"51049","messageId":"7vr6ly90li.fsf@gitster.siamese.dyndns.org","threadId":"9584","inReplyTo":"20070820055809.GZ27913@spearce.org","subject":"Re: How to do a reverse rebase?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-20T06:33:29Z","receivedAt":"2007-08-20T06:33:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n>> Is there an easier way?\n>\n> I don't think so.  To do the merge of those files we need a working\n> directory to operate in; that working directory is the one you have.\n\nActually, if the rebase is really tine compared to the\ndifferences between the branches, we _could_ do that without\nusing the real work tree.\n\nPrepare a \"for rebase\" index, with an empty temporary directory\nas the work tree, and use the merge machinery to do the\nnecessary per-path and contents merge all inside that temporary\ndirectory.  As the merge machiery is designed to be usable\ninside an empty directory and treat \"missing\" work tree files as\nif they are unchanged since index, the checkout in this\ntemporary directory would be kept to the minimum.\n"},{"id":"51074","messageId":"46C963B7.7ABF2944@eudaptics.com","threadId":"9584","inReplyTo":"20070820053237.9349.qmail@science.horizon.com","subject":"Re: How to do a reverse rebase?","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-08-20T09:49:43Z","receivedAt":"2007-08-20T09:49:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"linux@horizon.com wrote:\n> I don't want to rebase HEAD on *that*, but rather rebase *that*\n> on top of the current HEAD.\n> \n> Sometimes I have a little debug hack on a branch by itself, and I\n> discover that I need it again, so I want to rebase it on top of\n> current development.\n> \n> But there's been a LOT of development in the meantime.  And if I do\n> \n> git-rebase HEAD debug_hack\n> \n> git first checks out debug_hack.  This takes a while and, more\n> importantly, every file modified in HEAD...debug_hack has its timestamp\n> touched and make(1) insists on recompiling it.\n\nHeh. For the same reason I also want 'git merge --into that'.\n\nI often hack on a topic branch until it has the right shape. One of the\nchanges touches a central file that triggers a complete recompile.\n\nNow I want to merge the topic into master (which did not change this\ncentral file since the merge-base). Currently, I must checkout master,\nwhich touches the file, but if there existed 'merge --into' it could get\naway without touching the file.\n\n-- Hannes\n"},{"id":"51078","messageId":"20070820103943.6046.qmail@science.horizon.com","threadId":"9584","inReplyTo":"20070820055809.GZ27913@spearce.org","subject":"Re: How to do a reverse rebase?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-08-20T10:39:43Z","receivedAt":"2007-08-20T10:39:43Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> I don't think so.  To do the merge of those files we need a working\n> directory to operate in; that working directory is the one you have.\n> It sounds like what you want is this:\n\n>\told=`git symbolic-ref HEAD` &&\n>\tgit checkout HEAD^0 &&\n>\tgit cherry-pick debug_hack &&\n>\tgit branch -f debug_hack HEAD &&\n>\tgit checkout $old\n\nEr, actually, I don't want the messing about with $old.\nAt the end of the day, I want to be on the tip of the rebased\nwork.\n\nThe problem is that git-cherry-pick only oves a single comit,\nso if I have a stack, it's annoying.\n\nIt's more like:\n\tgit checkout HEAD^0 &&\n\tfor i in `git-rev-list --reverse ..debug_hack`; do\n\t\tgit-cherry-pick $i\n\tdone &&\n\tgit branch -D debug_hack &&\n\tgit checkout -b debug_hack\n"}]}