{"thread":{"id":"17188","subject":"rebase -p confusion in 1.6.1","startedAt":"2009-01-15T10:39:33Z","lastAt":"2009-01-18T04:02:26Z","messageCount":28,"participants":["Sitaram Chamarty","Johannes Schindelin","Stephan Beyer","Michael J Gruber","Stephen Haberman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"100556","messageId":"slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net","threadId":"17188","inReplyTo":null,"subject":"rebase -p confusion in 1.6.1","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-15T10:39:33Z","receivedAt":"2009-01-15T10:39:33Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"Hello all,\n\nWhile trying to understand \"rebase -p\", I came across some\nvery unexpected behaviour that made me throw in the towel\nand ask for help!\n\nThe outputs I got really confused me.  Before the \"rebase\n-p\", the tree looked like\n    \n    * 78ffda9... (refs/heads/work) b4\n    * be1e3a4... b3\n    *   cd8d893... Merge branch 'master' into work\n    |\\\n    | * 0153c27... (refs/heads/master) a4\n    | * 74f4387... a3\n    * | f1b0c1c... b2\n    * | 2e202d0... b1\n    |/\n    * b37ae36... a2\n    * ed1e1bc... a1\n\nBut afterward, this is what it looks like -- all the \"b\"\ncommits are gone!\n\n    * 0153c27... (refs/heads/work, refs/heads/master) a4\n    * 74f4387... a3\n    * b37ae36... a2\n    * ed1e1bc... a1\n\nWhat did I do wrong/misunderstand?\n\nHere's how to recreate.  Note that \"testci\" is a shell\nfunction and \"lg\" is a git alias.  They are, respectively,\n(1) testci() { for i; do echo $i > $i; git add $i; git commit -m $i; done; }\n(2) git config alias.lg log --graph --pretty=oneline --abbrev-commit --decorate\n\n    git init\n    testci a1 a2\n    git checkout -b work\n    testci b1 b2\n    git checkout master\n    testci a3 a4\n    git checkout work\n    git merge master\n    testci b3 b4\n    git --no-pager lg   # graph before rebase -p\n    git rebase -p master\n    git --no-pager lg   # graph after rebase -p\n"},{"id":"100577","messageId":"alpine.DEB.1.00.0901151429440.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T13:34:02Z","receivedAt":"2009-01-15T13:34:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Sitaram Chamarty wrote:\n\n> While trying to understand \"rebase -p\", I came across some\n> very unexpected behaviour that made me throw in the towel\n> and ask for help!\n>\n> [... some script with some aliases ...]\n\nI turned this into a proper test case (to show what would be most helpful \nif you report bugs like this in the future).\n\nIf nobody beats me to it, I'll work on it tonight.\n\n-- snipsnap --\n t/t3409-rebase-preserve-merges.sh |   28 ++++++++++++++++++++++++++++\n 1 files changed, 28 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh\nindex e6c8327..5e2128c 100755\n--- a/t/t3409-rebase-preserve-merges.sh\n+++ b/t/t3409-rebase-preserve-merges.sh\n@@ -92,4 +92,32 @@ test_expect_success '--continue works after a conflict' '\n \t)\n '\n \n+test_commit () {\n+\t: > \"$1\" &&\n+\tgit add \"$1\" &&\n+\ttest_tick &&\n+\tgit commit -m \"$1\" \"$1\"\n+}\n+\n+test_expect_success 'test case from Sitaram' '\n+\n+\tgit checkout master &&\n+\ttest_commit a1 &&\n+\tgit checkout -b work &&\n+\ttest_commit b1 &&\n+\tgit checkout master &&\n+\ttest_commit a3 &&\n+\tgit checkout work &&\n+\tgit merge master &&\n+\ttest_commit b3 &&\n+\techo before: &&\n+\tgit log --graph --pretty=oneline --decorate --abbrev-commit &&\n+\ttest -f b3 &&\n+\tgit rebase -p master &&\n+\techo after: &&\n+\tgit log --graph --pretty=oneline --decorate --abbrev-commit &&\n+\ttest -f b3\n+\n+'\n+\n test_done\n"},{"id":"100578","messageId":"20090115133808.GA10045@leksak.fem-net","threadId":"17188","inReplyTo":"slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-01-15T13:38:08Z","receivedAt":"2009-01-15T13:38:08Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi Sitaram,\n\nSitaram Chamarty wrote:\n> The outputs I got really confused me.  Before the \"rebase\n> -p\", the tree looked like\n>     \n>     * 78ffda9... (refs/heads/work) b4\n>     * be1e3a4... b3\n>     *   cd8d893... Merge branch 'master' into work\n>     |\\\n>     | * 0153c27... (refs/heads/master) a4\n>     | * 74f4387... a3\n>     * | f1b0c1c... b2\n>     * | 2e202d0... b1\n>     |/\n>     * b37ae36... a2\n>     * ed1e1bc... a1\n> \n> But afterward, this is what it looks like -- all the \"b\"\n> commits are gone!\n> \n>     * 0153c27... (refs/heads/work, refs/heads/master) a4\n>     * 74f4387... a3\n>     * b37ae36... a2\n>     * ed1e1bc... a1\n> \n> What did I do wrong/misunderstand?\n\nHmm, you are rebasing onto master which is merged into the branch you\nwant to rebase. So, I think the correct output should be the same like\ngit rebase without -p, ie\n\n* 1337bee... (refs/heads/work) b4\n* deadbee... b3\n* badbeef... b2\n* fa1afe1... b1\n* 0153c27... (refs/heads/master) a4\n* 74f4387... a3\n* b37ae36... a2\n* ed1e1bc... a1\n\nThis is because master is already merged into work and a preserved\nmerge will see that everything is already merged in.\n\nWell, so I think you've discovered a bug.\n\n> (2) git config alias.lg log --graph --pretty=oneline --abbrev-commit --decorate\n\nFunny, I have exactly the same alias, but named \"logk\".\n\n>     git init\n>     testci a1 a2\n>     git checkout -b work\n>     testci b1 b2\n>     git checkout master\n>     testci a3 a4\n>     git checkout work\n>     git merge master\n>     testci b3 b4\n>     git --no-pager lg   # graph before rebase -p\n>     git rebase -p master\n>     git --no-pager lg   # graph after rebase -p\n\nThanks and regards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"100579","messageId":"496F3C99.1040800@drmicha.warpmail.net","threadId":"17188","inReplyTo":"slrngmu4j5.e1u.sitaramc@sitaramc.homelinux.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-01-15T13:39:37Z","receivedAt":"2009-01-15T13:39:37Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Sitaram Chamarty venit, vidit, dixit 15.01.2009 11:39:\n> Hello all,\n> \n> While trying to understand \"rebase -p\", I came across some\n> very unexpected behaviour that made me throw in the towel\n> and ask for help!\n> \n> The outputs I got really confused me.  Before the \"rebase\n> -p\", the tree looked like\n>     \n>     * 78ffda9... (refs/heads/work) b4\n>     * be1e3a4... b3\n>     *   cd8d893... Merge branch 'master' into work\n>     |\\\n>     | * 0153c27... (refs/heads/master) a4\n>     | * 74f4387... a3\n>     * | f1b0c1c... b2\n>     * | 2e202d0... b1\n>     |/\n>     * b37ae36... a2\n>     * ed1e1bc... a1\n> \n> But afterward, this is what it looks like -- all the \"b\"\n> commits are gone!\n> \n>     * 0153c27... (refs/heads/work, refs/heads/master) a4\n>     * 74f4387... a3\n>     * b37ae36... a2\n>     * ed1e1bc... a1\n> \n> What did I do wrong/misunderstand?\n> \n> Here's how to recreate.  Note that \"testci\" is a shell\n> function and \"lg\" is a git alias.  They are, respectively,\n> (1) testci() { for i; do echo $i > $i; git add $i; git commit -m $i; done; }\n> (2) git config alias.lg log --graph --pretty=oneline --abbrev-commit --decorate\n> \n>     git init\n>     testci a1 a2\n>     git checkout -b work\n>     testci b1 b2\n>     git checkout master\n>     testci a3 a4\n>     git checkout work\n>     git merge master\n>     testci b3 b4\n>     git --no-pager lg   # graph before rebase -p\n>     git rebase -p master\n>     git --no-pager lg   # graph after rebase -p\n> \n\nFirst of all: git 1.6.0.6 gives you the unchanged graph after using\nrebase -i -p (git 1.6.1 adds -i behind you back and sets up a dummy\neditor). In any case, git rebase should not simply eat those commits -\neither leave them alone or rewrite them. git bisect says\n\nd80d6bc146232d81f1bb4bc58e5d89263fd228d4 is first bad commit\ncommit d80d6bc146232d81f1bb4bc58e5d89263fd228d4\nAuthor: Stephen Haberman <stephen@exigencecorp.com>\nDate:   Wed Oct 15 02:44:39 2008 -0500\n\n    rebase-i-p: do not include non-first-parent commits touching UPSTREAM\n\nso I'll cc the bad guy ;)\n\nSecond, what result do you expect? If the merge is to be preserved then\nb1, b2 can't be simply ripped out - or else you get the linear structure\nwhich rebase without '-p' delivers. The merge base (as returned by git\nmerge-base) between work and master is a4, i.e. master, so that the\nexpected result with '-p' is the one from 1.6.0.6 (unchanged graph).\n\nCheers,\nMichael\n"},{"id":"100586","messageId":"20090115135518.GB10045@leksak.fem-net","threadId":"17188","inReplyTo":"496F3C99.1040800@drmicha.warpmail.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-01-15T13:55:18Z","receivedAt":"2009-01-15T13:55:18Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> First of all: git 1.6.0.6 gives you the unchanged graph after using\n> rebase -i -p.\n\nThis is true and it is a far better behavior than now, but I think it's\nnot the expected behavior. (I have written about the behavior I'd expect\nin another reply to the original mail.)\n\nAlso\n\n\tgit rebase -i -p master\n\nshould do the same as\n\n\tgit rebase -i -p --onto master master\n\nor am I wrong?\n\nBut the latter does\n\n\t$ git rebase --onto master -i -p master\n\tfatal: Needed a single revision\n\tInvalid base\n\ninstead of resulting in an unchanged graph.\n(Tested with 1.5.6.5, the only other version I have installed besides\nmy master branch)\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"100589","messageId":"alpine.DEB.1.00.0901151448120.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"20090115133808.GA10045@leksak.fem-net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T13:58:54Z","receivedAt":"2009-01-15T13:58:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Stephan Beyer wrote:\n\n> Hmm, you are rebasing onto master which is merged into the branch you \n> want to rebase. So, I think the correct output should be the same like \n> git rebase without -p, ie\n> \n> * 1337bee... (refs/heads/work) b4\n> * deadbee... b3\n> * badbeef... b2\n> * fa1afe1... b1\n> * 0153c27... (refs/heads/master) a4\n> * 74f4387... a3\n> * b37ae36... a2\n> * ed1e1bc... a1\n> \n> This is because master is already merged into work and a preserved\n> merge will see that everything is already merged in.\n\nI guess the problem is that the list shown in the editor says 'noop'.  \nThis does not happen without -p, so something is borked in the commit \nlisting with -p.\n\nWhich is no wonder: the code after line 652 in git-rebase--interactive.sh \nthat handles -p is utterly incomprehensible.\n\nRemember: there is code that is so simple that it has no obvious flaws, \nand there is code that is so complicated that it has no obvious flaws.\n\nIMO (and I said so much back then), it was the biggest mistake of the \nwhole patch series that it was so intrusive and changed everything.  It's \nnot like I did not warn anybody.\n\nThe point is: you could _easily_ handle -p with _almost the same_ \nrev-list command; you'd just have to make sure that --no-merges is \nskipped.\n\nAnd then you only have to make sure that the current commit is the \n(possibly rewritten version of the) first parent of the next commit to \npick.\n\nCiao,\nDscho\n"},{"id":"100595","messageId":"496F44AC.2060607@drmicha.warpmail.net","threadId":"17188","inReplyTo":"20090115135518.GB10045@leksak.fem-net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-01-15T14:14:04Z","receivedAt":"2009-01-15T14:14:04Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:\n> Hi,\n> \n>> First of all: git 1.6.0.6 gives you the unchanged graph after using\n>> rebase -i -p.\n> \n> This is true and it is a far better behavior than now, but I think it's\n> not the expected behavior. (I have written about the behavior I'd expect\n> in another reply to the original mail.)\n\nYep, I think -p should preserve only merges in side branches (and\ntherefore produce what you suggest, and what you get without -p). If it\npreserves all merges then there is nothing to rewrite here.\n\nBTW: How does the sequencer based rebase do in this case, and what's the\ngeneral status? If it's about to be integrated we can do without the\npresent script...\n\nMichael\n"},{"id":"100597","messageId":"alpine.DEB.1.00.0901151518520.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"496F44AC.2060607@drmicha.warpmail.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T14:25:45Z","receivedAt":"2009-01-15T14:25:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Michael J Gruber wrote:\n\n> Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:\n> \n> >> First of all: git 1.6.0.6 gives you the unchanged graph after using\n> >> rebase -i -p.\n> > \n> > This is true and it is a far better behavior than now, but I think it's\n> > not the expected behavior. (I have written about the behavior I'd expect\n> > in another reply to the original mail.)\n> \n> Yep, I think -p should preserve only merges in side branches\n\nyou mean everything in master..work?\n\n> (and therefore produce what you suggest, and what you get without -p). \n> If it preserves all merges then there is nothing to rewrite here.\n\nThe merge _is_ outside of master, so I do not understand what the heck you \nare talking about.\n\nThe more I think about it, I think it's possible I broke it with the \nintroduction of the \"noop\".\n\nHowever, there could be a _different_ test case where the current -p \nhandling shows the same error.  Dunno.\n\nCiao,\nDscho\n"},{"id":"100599","messageId":"20090115144050.GD10045@leksak.fem-net","threadId":"17188","inReplyTo":"496F44AC.2060607@drmicha.warpmail.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-01-15T14:40:50Z","receivedAt":"2009-01-15T14:40:50Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Michael J Gruber wrote:\n> BTW: How does the sequencer based rebase do in this case,\n\nThis was the first thing I checked :-)\nI had to rework the rebase -i -p code for sequencer a bit, but this\ncase was not something I had thought about (although it may not be\ntoo seldom), so I'm glad it comes up now.\n\nThe result is that it eats the commits a3 and a4. (But at least it does\nthe same with and without --onto master.) :-)\nI think it's not too hard to fix.\n\n> and what's the general status?\n\nI'm currently highly motivated to get it done soon and I hope that it\ngets into pu or next before the end of January.\n\nDepending on how productive I am over the weekend and depending on how\nmany further bugs (often hidden in such special cases) I find, it\ncould be sent to the list next week.\n\n> If it's about to be integrated we can do without the\n> present script...\n\nI think it will take some time and some discussions on the list until\nit will be integrated.  I remember, for example, Dscho, who has, since\nit had first come up, always been opposed to the mark-reset /\nmark-reset-merge scheme (in rebase -i -p, at least).\nOther users said \"Wow, this is much more flexible.\" ...\nand this is perhaps only one thing that can lead to some bigger\ndiscussion.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"100601","messageId":"496F4BF0.6020805@drmicha.warpmail.net","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901151518520.3586@pacific.mpi-cbg.de","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-01-15T14:45:04Z","receivedAt":"2009-01-15T14:45:04Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 15.01.2009 15:25:\n> Hi,\n> \n> On Thu, 15 Jan 2009, Michael J Gruber wrote:\n> \n>> Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:\n>>\n>>>> First of all: git 1.6.0.6 gives you the unchanged graph after using\n>>>> rebase -i -p.\n>>> This is true and it is a far better behavior than now, but I think it's\n>>> not the expected behavior. (I have written about the behavior I'd expect\n>>> in another reply to the original mail.)\n>> Yep, I think -p should preserve only merges in side branches\n> \n> you mean everything in master..work?\n> \n>> (and therefore produce what you suggest, and what you get without -p). \n>> If it preserves all merges then there is nothing to rewrite here.\n> \n> The merge _is_ outside of master, so I do not understand what the heck you \n> are talking about.\n\nEasy Dscho, easy ;)\n[meaning \"take it such...\"]\n\nI'm not sure what -p is supposed to do:\n\nA) Should it preserve all merge commits which it would need to rewrite?\nThat is lot to ask. Previous behaviour (intended or not) seemed to be to\ndo nothing in this case where the merge connects master and work.\n\nB) Should it preserve only merges in side branches? I seem to mean by\nthat branches where the parents are on work and other branches but not\non master.\n\nSo at least on my side there is confusion about the intention behind\n'-p' (say design goal), and therefore about the expectation.\n\n> The more I think about it, I think it's possible I broke it with the \n> introduction of the \"noop\".\n> \n> However, there could be a _different_ test case where the current -p \n> handling shows the same error.  Dunno.\n\nIt certainly worked after the noop introduction before the r-i-p series,\nbut not any more after. \"worked\" meaning it at least didn't leave out\ncommits in this case (but reproduced the existing DAG). I'm getting the\nimpression you suggest R.I.P. for r-i-p series ;) Fine with me...\n\nCheers,\nMichael\n"},{"id":"100603","messageId":"slrngmujc4.sf.sitaramc@sitaramc.homelinux.net","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901151429440.3586@pacific.mpi-cbg.de","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-15T14:51:48Z","receivedAt":"2009-01-15T14:51:48Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n\n> I turned this into a proper test case (to show what would be most helpful \n> if you report bugs like this in the future).\n\nThanks.  I'll keep that in mind.\n\nWhat is the significance of test_tick?  I can see what it is\ndoing, but am trying to understand why.\n\nRegards,\n\nSitaram\n"},{"id":"100607","messageId":"slrngmuk2h.sf.sitaramc@sitaramc.homelinux.net","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901151448120.3586@pacific.mpi-cbg.de","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-15T15:03:45Z","receivedAt":"2009-01-15T15:03:45Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Remember: there is code that is so simple that it has no obvious flaws, \n> and there is code that is so complicated that it has no obvious flaws.\nI've always heard the first part as \"obviously no flaws\"...\n"},{"id":"100610","messageId":"20090115150913.GE10045@leksak.fem-net","threadId":"17188","inReplyTo":"slrngmujc4.sf.sitaramc@sitaramc.homelinux.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-01-15T15:09:13Z","receivedAt":"2009-01-15T15:09:13Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Sitaram Chamarty wrote:\n> On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> \n> > I turned this into a proper test case (to show what would be most helpful \n> > if you report bugs like this in the future).\n> \n> Thanks.  I'll keep that in mind.\n> \n> What is the significance of test_tick?  I can see what it is\n> doing, but am trying to understand why.\n\nWhen you run the test case a second, third, fourth time, the commit\ntimes would be all different without test_tick. This is bad for\nbugfixing when you need to inspect the test case repo a little\nfurther. (When the commit times change, the commit ids change,\ntoo.)\nSo setting the time and counting it artificially up is nice\nto get the same SHAs over and over.\n\nRegards,\n  Stephan\n\n-- \nStephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F\n"},{"id":"100611","messageId":"slrngmukm6.sf.sitaramc@sitaramc.homelinux.net","threadId":"17188","inReplyTo":"496F3C99.1040800@drmicha.warpmail.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-15T15:14:14Z","receivedAt":"2009-01-15T15:14:14Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-15, Michael J Gruber <git@drmicha.warpmail.net> wrote:\n> Second, what result do you expect? If the merge is to be preserved then\n\nI don't know.  I did this while trying to understand where\nand how \"-p\" makes a difference.  If there's anything you\ncan point me to that explains rebase -p, especially from a\n\"here's where it comes useful\" point of view, I'd appreciate\nit.\n"},{"id":"100612","messageId":"slrngmul47.sf.sitaramc@sitaramc.homelinux.net","threadId":"17188","inReplyTo":"20090115150913.GE10045@leksak.fem-net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-15T15:21:43Z","receivedAt":"2009-01-15T15:21:43Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-15, Stephan Beyer <s-beyer@gmx.net> wrote:\n> Sitaram Chamarty wrote:\n>> What is the significance of test_tick?  I can see what it is\n>> doing, but am trying to understand why.\n\n> So setting the time and counting it artificially up is nice\n> to get the same SHAs over and over.\n\nI should have been clearer...\n\nI was trying to understand why the \"counting up\" part is\nneeded.\n\nRegards,\n\nSitaram\n"},{"id":"100625","messageId":"alpine.DEB.1.00.0901151658060.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"496F4BF0.6020805@drmicha.warpmail.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T16:04:55Z","receivedAt":"2009-01-15T16:04:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Michael J Gruber wrote:\n\n> I'm not sure what -p is supposed to do:\n> \n> A) Should it preserve all merge commits which it would need to rewrite?\n> That is lot to ask. Previous behaviour (intended or not) seemed to be to\n> do nothing in this case where the merge connects master and work.\n> \n> B) Should it preserve only merges in side branches? I seem to mean by\n> that branches where the parents are on work and other branches but not\n> on master.\n\nThe intention was this:\n\n\t$ git rebase -p master\n\nwould need to rewrite _all_ commits that are in \"master..\".  All of them, \nincluding the merge commits.\n\nThe fact that I implemented it as \"-i -p\" is only due to technical \nreasons; I know (ahem, now I should put that into the past tense) the code \nbase pretty well.\n\nAn additional shortcut was to avoid rewriting commits when they did not \nneed rewriting.  IOW if the commit-to-pick has only parents that were \n_not_ rewritten, we can avoid cherry-picking or merging, and just reset \n--hard <original commit>.\n\nThere was a problem, though; for some reason, the code as I did it fscked \nup the order of the commits when -p was specified.  Therefore, rewritten \ncommits had the wrong parents.\n\nI thought it should be easy to fix, but then I got a job that I actually \nlike, so my Git time budget was tremendously reduced.\n\n> > The more I think about it, I think it's possible I broke it with the \n> > introduction of the \"noop\".\n> \n> It certainly worked after the noop introduction before the r-i-p series, \n> but not any more after.\n\nUmm... which rebase -i -p series do you mean?  \"noop\" was introduced \npretty recently if my Alzheimered brain does not fool me.\n\nCiao,\nDscho\n"},{"id":"100627","messageId":"slrngmuoq8.3u2.sitaramc@sitaramc.homelinux.net","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901151658060.3586@pacific.mpi-cbg.de","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-15T16:24:40Z","receivedAt":"2009-01-15T16:24:40Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n\n> The intention was this:\n>\n> \t$ git rebase -p master\n>\n> would need to rewrite _all_ commits that are in \"master..\".  All of them, \n> including the merge commits.\n\nI went hog wild with all sorts of test cases and my head is\nspinning, but -- even when things happen more predictably,\nI'm unable to make \"rebase -p\" carry an evil merge over.\nThe \"evil\" part stays behind.\n\nI'm not sure if that is intentional or not, or (more likely)\nmy brain has become addled and I missed something somewhere.\n\nRegards,\n\nSitaram\n"},{"id":"100629","messageId":"alpine.DEB.1.00.0901151739520.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"20090115144050.GD10045@leksak.fem-net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T16:43:00Z","receivedAt":"2009-01-15T16:43:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Stephan Beyer wrote:\n\n> Michael J Gruber wrote:\n> > If it's about to be integrated we can do without the\n> > present script...\n> \n> I think it will take some time and some discussions on the list until it \n> will be integrated.  I remember, for example, Dscho, who has, since it \n> had first come up, always been opposed to the mark-reset / \n> mark-reset-merge scheme (in rebase -i -p, at least). Other users said \n> \"Wow, this is much more flexible.\" ... and this is perhaps only one \n> thing that can lead to some bigger discussion.\n\nWow, much more flexible.  Except that you should not need this kind of \nflexibility.  If you need to do something complicated, it would be better \nto use \"rebase -i -p\" for the parts that do _not_ need to pick _other_ \nparents than are recorded in the commits.\n\nAnd then you do an \"edit\" (or \"pause\" or whatever), and cherry-pick/merge \n_explicitely_ what you want.\n\nFurther, keep in mind that not only is that flexibility of dubitable value \nto the most users, it is also confusing, _and_ it adds code that is so \nrarely exercized that bugs can lurk in there for years... as you can \nexperience right now.\n\nSo no, nothing has changed, I find that mark idea still horrible, \nhorrible, horrible.\n\nCiao,\nDscho\n"},{"id":"100631","messageId":"alpine.DEB.1.00.0901151751580.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"slrngmuoq8.3u2.sitaramc@sitaramc.homelinux.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T16:53:53Z","receivedAt":"2009-01-15T16:53:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n\n\nif you would like me to respond to your questions in the future, it is \nmandatory to keep me in the Cc: list.\n\n\n\nOn Thu, 15 Jan 2009, Sitaram Chamarty wrote:\n\n> On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> \n> > The intention was this:\n> >\n> > \t$ git rebase -p master\n> >\n> > would need to rewrite _all_ commits that are in \"master..\".  All of them, \n> > including the merge commits.\n> \n> I went hog wild with all sorts of test cases and my head is\n> spinning, but -- even when things happen more predictably,\n> I'm unable to make \"rebase -p\" carry an evil merge over.\n> The \"evil\" part stays behind.\n> \n> I'm not sure if that is intentional or not, or (more likely)\n> my brain has become addled and I missed something somewhere.\n\nYes, this is intentional.\n\n\tInstead of ignoring merges, try to recreate them.\n\nThat means it tries to recreate them.  Not that it is successful.  And not \neven that it realizes when it failed.\n\nHth,\nDscho\n"},{"id":"100632","messageId":"496F6AC3.7050704@drmicha.warpmail.net","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901151658060.3586@pacific.mpi-cbg.de","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-01-15T16:56:35Z","receivedAt":"2009-01-15T16:56:35Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 15.01.2009 17:04:\n...\n>>> The more I think about it, I think it's possible I broke it with the \n>>> introduction of the \"noop\".\n>> It certainly worked after the noop introduction before the r-i-p series, \n>> but not any more after.\n> \n> Umm... which rebase -i -p series do you mean?  \"noop\" was introduced \n> pretty recently if my Alzheimered brain does not fool me.\n\nThis one introduced noop:\n\ncommit ff74126c03a8dfd04e7533573a5c420f2a7112ac\nAuthor: Johannes Schindelin <Johannes.Schindelin@gmx.de>\nDate:   Fri Oct 10 13:42:12 2008 +0200\n\n    rebase -i: do not fail when there is no commit to cherry-pick\n\nThis is the bad one from bisect:\n\ncommit d80d6bc146232d81f1bb4bc58e5d89263fd228d4\nAuthor: Stephen Haberman <stephen@exigencecorp.com>\nDate:   Wed Oct 15 02:44:39 2008 -0500\n\n    rebase-i-p: do not include non-first-parent commits touching UPSTREAM\n\nIt's the last one in a longer series. And that series is after the noop\nintroduction.\n\nMichael\n"},{"id":"100640","messageId":"alpine.DEB.1.00.0901151918320.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"496F6AC3.7050704@drmicha.warpmail.net","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T18:18:43Z","receivedAt":"2009-01-15T18:18:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Michael J Gruber wrote:\n\n> Johannes Schindelin venit, vidit, dixit 15.01.2009 17:04:\n> ...\n> >>> The more I think about it, I think it's possible I broke it with the \n> >>> introduction of the \"noop\".\n> >> It certainly worked after the noop introduction before the r-i-p series, \n> >> but not any more after.\n> > \n> > Umm... which rebase -i -p series do you mean?  \"noop\" was introduced \n> > pretty recently if my Alzheimered brain does not fool me.\n> \n> This one introduced noop:\n> \n> commit ff74126c03a8dfd04e7533573a5c420f2a7112ac\n> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n> Date:   Fri Oct 10 13:42:12 2008 +0200\n> \n>     rebase -i: do not fail when there is no commit to cherry-pick\n> \n> This is the bad one from bisect:\n> \n> commit d80d6bc146232d81f1bb4bc58e5d89263fd228d4\n> Author: Stephen Haberman <stephen@exigencecorp.com>\n> Date:   Wed Oct 15 02:44:39 2008 -0500\n> \n>     rebase-i-p: do not include non-first-parent commits touching UPSTREAM\n> \n> It's the last one in a longer series. And that series is after the noop\n> introduction.\n\nOhhh....\n\nThanks,\nDscho\n"},{"id":"100642","messageId":"slrngmuvn1.7q3.sitaramc@sitaramc.homelinux.net","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901151751580.3586@pacific.mpi-cbg.de","subject":"Re: rebase -p confusion in 1.6.1","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-15T18:22:25Z","receivedAt":"2009-01-15T18:22:25Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n\n> if you would like me to respond to your questions in the future, it is \n> mandatory to keep me in the Cc: list.\n\nOK.  [Is that the list convention too?]\n\n> On Thu, 15 Jan 2009, Sitaram Chamarty wrote:\n\n>> I'm unable to make \"rebase -p\" carry an evil merge over.\n>> The \"evil\" part stays behind.\n>> \n>> I'm not sure if that is intentional or not, or (more likely)\n>> my brain has become addled and I missed something somewhere.\n>\n> Yes, this is intentional.\n>\n> \tInstead of ignoring merges, try to recreate them.\n>\n> That means it tries to recreate them.  Not that it is successful.  And not \n> even that it realizes when it failed.\n\nIs a conflicted merge that was resolved by making a change\nthat was in neither parent, an evil merge?\n\nRegardless, I suspect rebase -p will not be able to carry\nsuch a merge over.\n\nBut if it won't carry over the evil in an evil merge, what\nother uses are there for \"rebase -p\" as opposed to rebase?\nSeems to me that the DAG may be different but the tree you\nend up with is the same then.\n\nI'm sure someone has a blog post or a bookmark or an article\nor something they wrote long ago about \"rebase -i -p\".\nAnyone?\n"},{"id":"100889","messageId":"alpine.DEB.1.00.0901180041180.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"cover.1232233454.git.stephen@exigencecorp.com","subject":"Re: [PATCH] do not drop commits before the merge base","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-17T23:41:49Z","receivedAt":"2009-01-17T23:41:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Jan 2009, Stephen Haberman wrote:\n\n> [... no patch, despite the subject...]\n\nYou probably wanted to use -n --cover-letter...\n\nCiao,\nDscho\n"},{"id":"100891","messageId":"alpine.DEB.1.00.0901180041540.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"a524993b13ee586cf0e8fbd3b6459ccd6767c6d8.1232233454.git.stephen@exigencecorp.com","subject":"Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-17T23:51:36Z","receivedAt":"2009-01-17T23:51:36Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Jan 2009, Stephen Haberman wrote:\n\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index c8b0861..e800e07 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -604,11 +604,18 @@ first and then run 'git rebase --continue' again.\"\n>  \t\t\t\techo $ONTO > \"$REWRITTEN\"/$c ||\n>  \t\t\t\t\tdie \"Could not init rewritten commits\"\n>  \t\t\tdone\n> +\t\t\t# Along with the merge bases, look at the first commit's\n> +\t\t\t# parent (which may be before the merge base) and mark it\n> +\t\t\t# as rewritten to ONTO\n> +\t\t\tFIRST=\"$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)\"\n> +\t\t\tfor p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2)\n> +\t\t\tdo\n> +\t\t\t\techo $ONTO > \"$REWRITTEN/$p\"\n> +\t\t\tdone\n\nAFAICT this is wrong.  You have no guarantee whatsoever that the output of\n\n\t$ git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1\n\nhas any parents at all.  Take for example a coolest-merge-ever, i.e. a \nmerge of an independent project.\n\nInstead, what you _actually_ are looking for are the boundary objects of \n$UPSTREAM..$HEAD, which would be easy to get at.\n\nHowever, I have a strong feeling that just piling onto the current code \nwill not fix the underlying issues.\n\nCiao,\nDscho\n"},{"id":"100892","messageId":"20090117181146.906a6bf3.stephen@exigencecorp.com","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901180041540.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2009-01-18T00:11:46Z","receivedAt":"2009-01-18T00:11:46Z","isPatch":true,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> > +\t\t\t# Along with the merge bases, look at the first commit's\n> > +\t\t\t# parent (which may be before the merge base) and mark it\n> > +\t\t\t# as rewritten to ONTO\n> > +\t\t\tFIRST=\"$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)\"\n> > +\t\t\tfor p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2)\n> > +\t\t\tdo\n> > +\t\t\t\techo $ONTO > \"$REWRITTEN/$p\"\n> > +\t\t\tdone\n> \n> AFAICT this is wrong.  You have no guarantee whatsoever that the output of\n> \n> \t$ git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1\n> \n> has any parents at all.  Take for example a coolest-merge-ever, i.e. a \n> merge of an independent project.\n> \n> Instead, what you _actually_ are looking for are the boundary objects\n> of $UPSTREAM..$HEAD,\n\nAgreed.\n\n> which would be easy to get at.\n\nThat would be great, but I'm not seeing it, obviously. Suggestions\nwould be appreciated.\n\n> However, I have a strong feeling that just piling onto the current\n> code will not fix the underlying issues.\n\nAlso agreed.\n\nSo...not that it really matters, but did my patches go out to the git\nlist or not? It looks like both Johannes and I got them from the cc\nentries.\n\nI tried to use format-patch and the files looked great, cc's including\nMichael, Stephan, and Sitaram. Then I ran send-email with the three\nfiles as arguments and it stripped all the cc's but Johannes and\nmyself. Then I got all three delivered due to my cc entry, but I didn't\nsee any entries arrive from the list even though the cc-delivered\ncopies all had \"To: git@vger.kernel.org\" in them (and that is what I\nhad pasted into the send-email prompt). I guess I did something wrong\nbut it's frustrating to not know what it was.\n\n- Stephen\n"},{"id":"100893","messageId":"alpine.DEB.1.00.0901180108480.3586@pacific.mpi-cbg.de","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901180041540.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-18T00:19:39Z","receivedAt":"2009-01-18T00:19:39Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 18 Jan 2009, Johannes Schindelin wrote:\n\n> However, I have a strong feeling that just piling onto the current code \n> will not fix the underlying issues.\n\nBTW just to clarify what I mean by \"underlying issues\": if you say \"git \nrebase -i\" in Sitaram's test case, you will see the two commits -- as \nexpected.\n\nHowever, if you add \"-p\", all of a sudden you will only see \"noop\".  IMO \nthere is no excuse that the code can hide them at all.  If the commits are \nreachable from HEAD but not from $UPSTREAM, they have to be in the list.  \nAs simple as that.\n\nAnother thing that I find horribly wrong: there is a \"touch \n$REWRITTEN/sha1\".  There was a simple design in the beginning: the files \nin $REWRITTEN are actually a mapping from old SHA-1 (file name) to new \nSHA-1 (content).  This was broken, without any good explanation.\n\nCiao,\nDscho\n"},{"id":"100914","messageId":"20090117215751.60ade90a.stephen@exigencecorp.com","threadId":"17188","inReplyTo":"alpine.DEB.1.00.0901180108480.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2009-01-18T03:57:51Z","receivedAt":"2009-01-18T03:57:51Z","isPatch":true,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> > However, I have a strong feeling that just piling onto the current\n> > code will not fix the underlying issues.\n> \n> BTW just to clarify what I mean by \"underlying issues\": if you say\n> \"git rebase -i\" in Sitaram's test case, you will see the two commits\n> -- as expected.\n> \n> However, if you add \"-p\", all of a sudden you will only see \"noop\".\n> IMO there is no excuse that the code can hide them at all.  If the\n> commits are reachable from HEAD but not from $UPSTREAM, they have to\n> be in the list.  As simple as that.\n\nAgreed--the rewritten-parent probing being rooted at the merge bases\nwas not good enough.\n\n> Another thing that I find horribly wrong: there is a \"touch\n> $REWRITTEN/sha1\".  There was a simple design in the beginning: the\n> files in $REWRITTEN are actually a mapping from old SHA-1 (file name)\n> to new SHA-1 (content).  This was broken, without any good\n> explanation.\n\nPerhaps it is not \"good\", but the explanation a blank REWRITTEN/sha1 is\nused a marker during the probe phase that this commit will be rewritten.\nSo when looking at any of its children commits, they should be rewritten\nif a REWRITTEN/parentSha1 exists. Then as the rewriting actually happens,\nthey get filled in with the new sha1. I cribbed this approach from\nStephan's sequencer rewrite of rebase-i-p.\n\nIf you want a different data structure, be it file based, or bash/list\nbased, or whatever, to track \"this commit will eventually be rewritten\nbut we haven't gotten there yet\" during the probe, then we could go back\nto leaving REWRITTEN/sha1 alone until after the sha1 commit has been\nrebased.\n\nI'm open to suggestions.\n\nAlso, as you seem to realize, the current bug stems from not knowing how\nto initialize the rewritten data structure. For Sitaram's case, the\nfirst commit is behind any of the merge bases, so marking its parents\n(if they exist) as rewritten to ONTO seems reasonable.\n\nIf there are no parents, as you point out, I added a \"-o sha1 = FIRST\"\nthat should also get the ball rolling. It's another hack, but does this\naddress your concern until a large refactoring happens?\n\n-------------------------- git-rebase--interactive.sh --------------------------\nindex c8b0861..8740d9f 100755\n@@ -604,11 +604,18 @@ first and then run 'git rebase --continue' again.\"\n \t\t\t\techo $ONTO > \"$REWRITTEN\"/$c ||\n \t\t\t\t\tdie \"Could not init rewritten commits\"\n \t\t\tdone\n+\t\t\t# Along with the merge bases, look at the first commit's\n+\t\t\t# parent (which may be before the merge base) and mark it\n+\t\t\t# as rewritten to ONTO\n+\t\t\tFIRST=\"$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)\"\n+\t\t\tfor p in $(git rev-list --parents -1 $FIRST | cut -d' ' -f2)\n+\t\t\tdo\n+\t\t\t\techo $ONTO > \"$REWRITTEN/$p\"\n+\t\t\tdone\n \t\t\t# No cherry-pick because our first pass is to determine\n \t\t\t# parents to rewrite and skipping dropped commits would\n \t\t\t# prematurely end our probe\n \t\t\tMERGES_OPTION=\n-\t\t\tfirst_after_upstream=\"$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)\"\n \t\telse\n \t\t\tMERGES_OPTION=\"--no-merges --cherry-pick\"\n \t\tfi\n@@ -629,12 +636,12 @@ first and then run 'git rebase --continue' again.\"\n \t\t\t\tpreserve=t\n \t\t\t\tfor p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)\n \t\t\t\tdo\n-\t\t\t\t\tif test -f \"$REWRITTEN\"/$p -a \\( $p != $UPSTREAM -o $sha1 = $first_after_upstream \\)\n+\t\t\t\t\tif test -f \"$REWRITTEN\"/$p -a $p != $UPSTREAM\n \t\t\t\t\tthen\n \t\t\t\t\t\tpreserve=f\n \t\t\t\t\tfi\n \t\t\t\tdone\n-\t\t\t\tif test f = \"$preserve\"\n+\t\t\t\tif test f = \"$preserve\" -o $sha1 = $FIRST\n \t\t\t\tthen\n \t\t\t\t\ttouch \"$REWRITTEN\"/$sha1\n \t\t\t\t\techo \"pick $shortsha1 $rest\" >> \"$TODO\"\n\n(I'm adding the other 3 cc's back after my failed patch attempt\nstripped them out--sorry, guys.)\n\n- Stephen\n"},{"id":"100916","messageId":"20090117220226.8f0d1960.stephen@exigencecorp.com","threadId":"17188","inReplyTo":"20090117215751.60ade90a.stephen@exigencecorp.com","subject":"Re: [PATCH] rebase -p: seed first commit in case it's before the merge bases.","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2009-01-18T04:02:26Z","receivedAt":"2009-01-18T04:02:26Z","isPatch":true,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> Perhaps it is not \"good\", but the explanation a blank REWRITTEN/sha1 is\n> used a marker during the probe phase that this commit will be rewritten.\n> So when looking at any of its children commits, they should be rewritten\n> if a REWRITTEN/parentSha1 exists.\n\nUgh, fixing several typos:\n\nPerhaps it is not \"good\", but the explanation /is that/ a blank\nREWRITTEN/sha1 is used /as/ a marker during the probe phase that this\ncommit will be rewritten. So when looking at any of its children\ncommits, /the children/ should be rewritten if a REWRITTEN/parentSha1\nexists.\n\nSorry about that.\n\n- Stephen\n"}]}