{"thread":{"id":"17344","subject":"Heads up: major rebase -i -p rework coming up","startedAt":"2009-01-24T20:25:33Z","lastAt":"2009-02-03T11:47:17Z","messageCount":27,"participants":["Johannes Schindelin","Junio C Hamano","Thomas Rast","Jakub Narebski","Sverre Rabbelier","Björn Steinbrink","Marc Branchaud","Stephen Haberman","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"101778","messageId":"alpine.DEB.1.00.0901242056070.14855@racer","threadId":"17344","inReplyTo":null,"subject":"Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-24T20:25:33Z","receivedAt":"2009-01-24T20:25:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi all,\n\nas probably everybody agrees, the code to preserve merges is a big mess \nright now.\n\nWorse, the whole concept of \"pick \" just does not fly well.\n\nSo I started a _major_ cleanup, which happens to reduce the code very \nnicely so far.\n\nIt will take a few days to flesh out, I guess, but these are the major \nideas of my work:\n\n- pick $sha1\n\n\twill only work on non-merges in the future\n\n- merge $sha1 [$sha1...] was $sha1 \"Merge ...\"\n\n\twill merge the given list of commits into the current HEAD, for \n\tthe user's reference and to keep up-to-date what was rewritten, \n\tthe original merge is shown after the keyword \"was\" (which is not \n\ta valid SHA-1, luckily)\n\n- goto $sha1\n\n\twill reset the HEAD to the given commit\n\n- $sha1'\n\n\tfor merge and goto, if a $sha1 ends in a single quote, the \n\trewritten commit is substituted (if there is one)\n\nExample:\n\nA - B - - - E \n \\ /\n C - D\n\ncould yield this TODO script:\n\n\tpick A\n\tpick C\n\tpick D\n\tgoto A'\n\tpick B\n\tmerge D' was E\n\nThis should lead to a much more intuitive user experience.\n\nI am very sorry if somebody actually scripted rebase -i -p (by setting \nGIT_EDITOR with a script), but I am very certain that this cleanup is \nabsolutely necessary to make rebase -i -p useful.\n\nAs always, I am thankful for suggestions to make this even more useful, or \neven easier to operate.\n\nCiao,\nDscho\n"},{"id":"101779","messageId":"7vpricmoda.fsf@gitster.siamese.dyndns.org","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901242056070.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-24T20:37:53Z","receivedAt":"2009-01-24T20:37:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> \tpick A\n> \tpick C\n> \tpick D\n> \tgoto A'\n> \tpick B\n> \tmerge D' was E\n>\n> This should lead to a much more intuitive user experience.\n>\n> I am very sorry if somebody actually scripted rebase -i -p (by setting \n> GIT_EDITOR with a script), but I am very certain that this cleanup is \n> absolutely necessary to make rebase -i -p useful.\n\nThree questions.\n\n- An obvious one first. How does this relate to the sequencer project (that\n seems to have gone somewhat dark?)\n\n- What's with the apostrophe? I seem to remember that you argued it would\n be enough to make \"A\" stand for the original when it is used for the\n first time and the second and later use can stand for the result of the\n last use (e.g. the \"goto A'\" above can be simply spelled as \"goto A\"),\n when I suggested to use \"mark\" in a way similar to how fast-import\n language uses it during the sequencer discussion?\n\n I am not complaining; I am just being curious why the sudden change of\n heart.\n\n- Why do you need \"merge D' was E\"? Shouldn't \"pick E\" be able to notice\n that E is a merge and decompose it into \"merge D' was E\" internally?\n\n This one I am somewhat complaining, unless your answer is \"because this\n way the user could drop some parents from the merge in the editor\".\n\n And if your answer is that, then my next question will be \"if that is\n the case, can the user be expected to easily find out which commit each\n parent SHA-1 refers to, without having more hint on the 'merge' insn\n line?\"\n"},{"id":"101782","messageId":"alpine.DEB.1.00.0901242156320.14855@racer","threadId":"17344","inReplyTo":"7vpricmoda.fsf@gitster.siamese.dyndns.org","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-24T21:04:53Z","receivedAt":"2009-01-24T21:04:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Jan 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > \tpick A\n> > \tpick C\n> > \tpick D\n> > \tgoto A'\n> > \tpick B\n> > \tmerge D' was E\n> >\n> > This should lead to a much more intuitive user experience.\n> >\n> > I am very sorry if somebody actually scripted rebase -i -p (by setting \n> > GIT_EDITOR with a script), but I am very certain that this cleanup is \n> > absolutely necessary to make rebase -i -p useful.\n> \n> Three questions.\n> \n> - An obvious one first. How does this relate to the sequencer project \n> (that seems to have gone somewhat dark?)\n\nAs far as I can see, Stephan can keep the \"mark\" command he cherishes so \nmuch, and we can still use thise syntax for rebase -i -p.\n\n> - What's with the apostrophe? I seem to remember that you argued it \n> would be enough to make \"A\" stand for the original when it is used for \n> the first time and the second and later use can stand for the result \n> of the last use (e.g. the \"goto A'\" above can be simply spelled as \n> \"goto A\"), when I suggested to use \"mark\" in a way similar to how \n> fast-import language uses it during the sequencer discussion?\n> \n> I am not complaining; I am just being curious why the sudden change of \n> heart.\n\nVery easy explanation. I got convinced by your arguments. Even if I \ncould imagine that I never use the thing without apostrophe, it is good to \nhave an obvious indicator that this is not necessarily the original \ncommit.\n\n> - Why do you need \"merge D' was E\"? Shouldn't \"pick E\" be able to \n> notice that E is a merge and decompose it into \"merge D' was E\" \n> internally?\n> \n> This one I am somewhat complaining, unless your answer is \"because \n> this way the user could drop some parents from the merge in the \n> editor\".\n\nNot only that; the user could use this to fix mismerges, i.e. by replacing \na SHA-1 with the SHA-1 (or indeed, a short name, unless it is \"was\") of \nthe branch that she _actually_ wanted to merge with.\n\n> And if your answer is that, then my next question will be \"if that is \n> the case, can the user be expected to easily find out which commit \n> each parent SHA-1 refers to, without having more hint on the 'merge' \n> insn line?\"\n\nNope.\n\nIn most cases, however, that should be plenty enough:\n\n\tmerge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next\n\nThe user does not have to guess much what 9383af1 might refer to.\n\nIn case of octopodes, or when the commit message was changed, the user has \nto open another command line and look for herself, though.\n\nCiao,\nDscho\n"},{"id":"101783","messageId":"alpine.DEB.1.00.0901242206540.14855@racer","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901242156320.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-24T21:09:36Z","receivedAt":"2009-01-24T21:09:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Jan 2009, Johannes Schindelin wrote:\n\n> > - Why do you need \"merge D' was E\"? Shouldn't \"pick E\" be able to \n> > notice that E is a merge and decompose it into \"merge D' was E\" \n> > internally?\n> > \n> > This one I am somewhat complaining, unless your answer is \"because \n> > this way the user could drop some parents from the merge in the \n> > editor\".\n> \n> Not only that; the user could use this to fix mismerges, i.e. by \n> replacing a SHA-1 with the SHA-1 (or indeed, a short name, unless it is \n> \"was\") of the branch that she _actually_ wanted to merge with.\n> \n> > And if your answer is that, then my next question will be \"if that \n> > is the case, can the user be expected to easily find out which \n> > commit each parent SHA-1 refers to, without having more hint on the \n> > 'merge' insn line?\"\n> \n> Nope.\n> \n> In most cases, however, that should be plenty enough:\n> \n> \tmerge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next\n> \n> The user does not have to guess much what 9383af1 might refer to.\n\nHeh, I think it is much easier than I thought: How about this?\n\n \tmerge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next\n\t# \\ 9383af1 Revert previous two commits\n\nObviously, for octopodes, there would be multiple \"# \\ \" \nlines...\n\nCiao,\nDscho\n"},{"id":"101788","messageId":"200901242347.23187.trast@student.ethz.ch","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901242056070.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-01-24T22:47:20Z","receivedAt":"2009-01-24T22:47:20Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Johannes Schindelin wrote:\n> Worse, the whole concept of \"pick \" just does not fly well.\n[...]\n> - merge $sha1 [$sha1...] was $sha1 \"Merge ...\"\n> \n> \twill merge the given list of commits into the current HEAD, for \n> \tthe user's reference and to keep up-to-date what was rewritten, \n> \tthe original merge is shown after the keyword \"was\" (which is not \n> \ta valid SHA-1, luckily)\n\nI really like the underlying idea. I'm not even sure if the current\nsemantics are well-defined in all cases; an explicit merge command at\nleast makes it very clear what is going on.\n\nHowever, I think the syntax as proposed above is a bit confusing in\nthe usual two-parent merge. I couldn't tell whether\n\n merge A was B\n\nwas intended to be read as \"the merge of A into the current branch\" or\n\"the merge with sha1 A\" right away, and I doubt I'll be able to tell\nwithout looking in the (rare) cases I have to invoke rebase -i -p.\n\nI can't really come up with a better replacement for 'was', so how\nabout\n\n merge A # was B \"Merge...\"\n\nwhich would make it more clear that the \"was B...\" has no effect\nwhatsoever on the merge's semantics.\n\n> A - B - - - E \n> \\ /\n> C - D\n> \n> could yield this TODO script:\n> \n> \tpick A\n> \tpick C\n> \tpick D\n> \tgoto A'\n> \tpick B\n> \tmerge D' was E\n\nI kind of wonder if it would be possible to decorate the TODO with\n'git log --graph' output, to make it easier to follow the history as\nit is built. Perhaps something like\n\n * pick A\n |\\\n * | pick B\n goto A'\n | * pick C\n | * pick D\n |/\n goto B'\n * merge D' # was E\n\nWell, maybe it's not such a good idea after all.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"101789","messageId":"7vzlhgl35z.fsf@gitster.siamese.dyndns.org","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901242156320.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-24T23:01:12Z","receivedAt":"2009-01-24T23:01:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> - What's with the apostrophe? I seem to remember that you argued it \n>> would be enough to make \"A\" stand for the original when it is used for \n>> the first time and the second and later use can stand for the result \n>> of the last use (e.g. the \"goto A'\" above can be simply spelled as \n>> \"goto A\"), when I suggested to use \"mark\" in a way similar to how \n>> fast-import language uses it during the sequencer discussion?\n>> \n>> I am not complaining; I am just being curious why the sudden change of \n>> heart.\n>\n> Very easy explanation. I got convinced by your arguments. Even if I \n> could imagine that I never use the thing without apostrophe, it is good to \n> have an obvious indicator that this is not necessarily the original \n> commit.\n\nNow that does not make much sense to me.\n\nThe reason I suggested that 'mark' would give a cleaner semantics was\nbecause in your earlier design \"A\" could either stand for the original or\nit could stand for the result of an operation that used \"A\", and there\ncould be more than one operation that uses \"A\". Explicitly naming each\nresult with a mark would give us an unambiguous way to distinguish them.\n\nI however do not think you would ever use A twice in the context of\n\"rebase -i/-p\". Cherry-picking the same commit twice to create two copies\nof them will not happen in that context.\n\nWhile trying to recreate something like this on top of a commit \"o\", you\nwould have to talk about \"A\" multiple times,...\n\n B---M\n / / \\\n ---o---A---C \\\n \\ \\ \\\n D---N-------O\n\n... but even in such a picture, after one \"pick A\", you would always want\nto refer to the result of the pick, and never the original A.\n\n pick A\n goto A'^\n pick D\n merge A' was N\n goto A'\n pick B\n goto A'\n pick C\n merge B' was M\n merge N' was O\n\nSo I am inclined to think that \"first use refers to the original, second\nand thereafter will refer to the result of the first use\" would be a good\nenough semantics for \"rebase -i/-p\", and you do not need \"A\" vs \"A'\" for\nthis.\n\nBy the way, I think this example shows that your \"goto\" might need a way\nto refer to the \"onto\" commit in some way (I just used \"A'^\" there).\n\nOn the other hand, if you are aiming to allow users to create (by editing\nthe insn file) an arbitrarily different structure like this, starting from\nthe same topology:\n\n ---o---B---C---A\n \\ \\\n A---D-------O\n\nthat is, rebasing the upper line of development into one linear sequence\nwith different patch order, while rebasing the lower line into another\nlinear sequence by rebasing D on top of A, you would need to be able to\nrefer to the two different results of \"using A\", and your \"A'\" notation\nwould not help.\n\n pick B\n pick C\n pick A\n goto B'^\n pick A\n pick D\n merge A' was O\n\nThe last \"merge A' was O\" is done while on the result of applying D on top\nof the result of applying A on the lower line, and wants to call the tip\nof the upper line by referring it as \"the result of applying A\". \n\nBut there are two results from applying A, and I do not think you can\navoid 'mark', even though you for some reason seem to hate it.\n\nIf this kind of transformation is outside the scope of your redesign\n(which I think is a sensible design decision), I do not see why you would\nneed \"A vs A'\".\n\nYou either need the full power of 'mark', or \"A is original until it is\nused, and then the one and only one result once it is used,\"; nothing in\nbetween like \"A vs A'\" would make much sense.\n"},{"id":"101809","messageId":"alpine.DEB.1.00.0901250303150.14855@racer","threadId":"17344","inReplyTo":"200901242347.23187.trast@student.ethz.ch","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-25T02:05:38Z","receivedAt":"2009-01-25T02:05:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Jan 2009, Thomas Rast wrote:\n\n> Johannes Schindelin wrote:\n> > Worse, the whole concept of \"pick \" just does not fly well.\n> [...]\n> > - merge $sha1 [$sha1...] was $sha1 \"Merge ...\"\n> > \n> > \twill merge the given list of commits into the current HEAD, for \n> > \tthe user's reference and to keep up-to-date what was rewritten, the \n> > \toriginal merge is shown after the keyword \"was\" (which is not a valid \n> > \tSHA-1, luckily)\n> \n> I really like the underlying idea. I'm not even sure if the current \n> semantics are well-defined in all cases; an explicit merge command at \n> least makes it very clear what is going on.\n> \n> However, I think the syntax as proposed above is a bit confusing in the \n> usual two-parent merge. I couldn't tell whether\n> \n> merge A was B\n> \n> was intended to be read as \"the merge of A into the current branch\" or \n> \"the merge with sha1 A\" right away, and I doubt I'll be able to tell \n> without looking in the (rare) cases I have to invoke rebase -i -p.\n> \n> I can't really come up with a better replacement for 'was', so how about\n> \n> merge A # was B \"Merge...\"\n> \n> which would make it more clear that the \"was B...\" has no effect \n> whatsoever on the merge's semantics.\n\nHmm. You're right, that is not really intuitive. How about\n\n\tmerge (B) A # Merge...\n\ninstead?\n\n> > A - B - - - E \n> > \\ /\n> > C - D\n> > \n> > could yield this TODO script:\n> > \n> > \tpick A\n> > \tpick C\n> > \tpick D\n> > \tgoto A'\n> > \tpick B\n> > \tmerge D' was E\n> \n> I kind of wonder if it would be possible to decorate the TODO with\n> 'git log --graph' output, to make it easier to follow the history as\n> it is built.\n\nI wondered about that, too, and abandoned it as my common operation is cut \n& past lines around. The result would look _utterly_ confusing.\n\nMaybe I should have mentioned that to spare you the brain cycles thinking \nabout --graph...\n\nCiao,\nDscho\n"},{"id":"101810","messageId":"alpine.DEB.1.00.0901250305450.14855@racer","threadId":"17344","inReplyTo":"7vzlhgl35z.fsf@gitster.siamese.dyndns.org","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-25T02:23:46Z","receivedAt":"2009-01-25T02:23:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Jan 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> - What's with the apostrophe? I seem to remember that you argued it \n> >> would be enough to make \"A\" stand for the original when it is used \n> >> for the first time and the second and later use can stand for the \n> >> result of the last use (e.g. the \"goto A'\" above can be simply \n> >> spelled as \"goto A\"), when I suggested to use \"mark\" in a way \n> >> similar to how fast-import language uses it during the sequencer \n> >> discussion?\n> >> \n> >> I am not complaining; I am just being curious why the sudden change \n> >> of heart.\n> >\n> > Very easy explanation. I got convinced by your arguments. Even if I \n> > could imagine that I never use the thing without apostrophe, it is \n> > good to have an obvious indicator that this is not necessarily the \n> > original commit.\n> \n> Now that does not make much sense to me.\n> \n> The reason I suggested that 'mark' would give a cleaner semantics was \n> because in your earlier design \"A\" could either stand for the original \n> or it could stand for the result of an operation that used \"A\", and \n> there could be more than one operation that uses \"A\". Explicitly naming \n> each result with a mark would give us an unambiguous way to distinguish \n> them.\n\nBut that is not what rebase -i is about! Either you rewrite a commit, or \nyou don't. You don't rewrite it multiple times _and_ reference all of the \nintermediate steps!\n\nShould you suggest that this is a sane worflow, you would really ask for \ntrouble.\n\nAs it is, \"mark\" is useless. It would give one and the same thing two \nnames, one short SHA-1, and one numeric value, and the relationship \nbetween the two -- even if they mean the same! -- would be completely \narbitrary.\n\n> I however do not think you would ever use A twice in the context of \n> \"rebase -i/-p\".\n\nExactly!\n\n> Cherry-picking the same commit twice to create two copies of them will \n> not happen in that context.\n\nNot exactly true, as you could split a patch by\n\n\tedit abcdefg Patch to be split\n\tedit abcdefg Patch to be split\n\nAnd removing half of the patch in the first edit (e.g. by \"git reset \nHEAD^ && git add -e\" or something similar).\n\n> While trying to recreate something like this on top of a commit \"o\", you\n> would have to talk about \"A\" multiple times,...\n> \n> B---M\n> / / \\\n> ---o---A---C \\\n> \\ \\ \\\n> D---N-------O\n> \n> ... but even in such a picture, after one \"pick A\", you would always want\n> to refer to the result of the pick, and never the original A.\n> \n> pick A\n> goto A'^\n\n... or goto $ONTO...\n\n> pick D\n> merge A' was N\n> goto A'\n> pick B\n> goto A'\n> pick C\n> merge B' was M\n> merge N' was O\n> \n> So I am inclined to think that \"first use refers to the original, second\n> and thereafter will refer to the result of the first use\" would be a good\n> enough semantics for \"rebase -i/-p\", and you do not need \"A\" vs \"A'\" for\n> this.\n> \n> By the way, I think this example shows that your \"goto\" might need a way\n> to refer to the \"onto\" commit in some way (I just used \"A'^\" there).\n\nIt will use $ONTO.\n\n> On the other hand, if you are aiming to allow users to create (by editing\n> the insn file) an arbitrarily different structure like this, starting from\n> the same topology:\n> \n> ---o---B---C---A\n> \\ \\\n> A---D-------O\n> \n> that is, rebasing the upper line of development into one linear sequence\n> with different patch order, while rebasing the lower line into another\n> linear sequence by rebasing D on top of A, you would need to be able to\n> refer to the two different results of \"using A\", and your \"A'\" notation\n> would not help.\n> \n> pick B\n> pick C\n> pick A\n> goto B'^\n> pick A\n> pick D\n> merge A' was O\n> \n> The last \"merge A' was O\" is done while on the result of applying D on top\n> of the result of applying A on the lower line, and wants to call the tip\n> of the upper line by referring it as \"the result of applying A\". \n> \n> But there are two results from applying A, and I do not think you can\n> avoid 'mark', even though you for some reason seem to hate it.\n\nYou can, by doing the sane thing and first apply one strand of the two \nbranches, then going back and applying the other strand. You would not \neven once need \"goto A'\".\n\n> If this kind of transformation is outside the scope of your redesign \n> (which I think is a sensible design decision), I do not see why you \n> would need \"A vs A'\".\n> \n> You either need the full power of 'mark', or \"A is original until it is \n> used, and then the one and only one result once it is used,\"; nothing in \n> between like \"A vs A'\" would make much sense.\n\nYour example seems a little bit constructed to the purpose of showing the \nshortcomings of the A' notation.\n\nBut it has a shortcoming in and of its own: if you want to apply A for \nboth branches, it would make a metric ton more sense to apply A before \nbranching:\n\n ---o---A---B---C\n \\ \\\n D-------O\n\nBesides, if you would concoct a real obscure situation where you really \nneeded to apply one and the same patch twice, _and_ refer to both \"A'\" \n(something like\n\n ---o---B---A---C----H\n \\ \\ / /\n \\ E /\n \\ /\n D---A---F\n \\ /\n G\n\nThen you could still do the part B...C first (with the first version of \nA'), then D...F (with the second version of A') and be done with it. \nUnless you would want anything like\n\n\n C---A---B\n /\n ---A\n\nwhich is ugly beyond belief IMO, but in which case you could _still_ do it \nwith an \"edit C; merge A' was B\" where you just git cherry-pick A.\n\nSo it is possible, even if it needs trickery, which is okay IMHO as this \nis not the common case. And I want to optimize for the common case.\n\nCiao,\nDscho\n"},{"id":"101811","messageId":"alpine.DEB.1.00.0901250324320.14855@racer","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901250303150.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-25T02:25:12Z","receivedAt":"2009-01-25T02:25:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jan 2009, Johannes Schindelin wrote:\n\n> On Sat, 24 Jan 2009, Thomas Rast wrote:\n> \n> > Johannes Schindelin wrote:\n> > > Worse, the whole concept of \"pick \" just does not fly well.\n> > [...]\n> > > - merge $sha1 [$sha1...] was $sha1 \"Merge ...\"\n> > > \n> > > \twill merge the given list of commits into the current HEAD, for \n> > > \tthe user's reference and to keep up-to-date what was rewritten, the \n> > > \toriginal merge is shown after the keyword \"was\" (which is not a \n> > > \tvalid SHA-1, luckily)\n> > \n> > I really like the underlying idea. I'm not even sure if the current \n> > semantics are well-defined in all cases; an explicit merge command at \n> > least makes it very clear what is going on.\n> > \n> > However, I think the syntax as proposed above is a bit confusing in \n> > the usual two-parent merge. I couldn't tell whether\n> > \n> > merge A was B\n> > \n> > was intended to be read as \"the merge of A into the current branch\" or \n> > \"the merge with sha1 A\" right away, and I doubt I'll be able to tell \n> > without looking in the (rare) cases I have to invoke rebase -i -p.\n> > \n> > I can't really come up with a better replacement for 'was', so how \n> > about\n> > \n> > merge A # was B \"Merge...\"\n> > \n> > which would make it more clear that the \"was B...\" has no effect \n> > whatsoever on the merge's semantics.\n> \n> Hmm. You're right, that is not really intuitive. How about\n> \n> \tmerge (B) A # Merge...\n> \n> instead?\n\nOr even better:\n\n\tmerge B parent A' # Merge...\n\n?\n\nCiao,\nDscho\n"},{"id":"101832","messageId":"glhqdi$tec$1@ger.gmane.org","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901250324320.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-01-25T13:46:02Z","receivedAt":"2009-01-25T13:46:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n>> Hmm.  You're right, that is not really intuitive.  How about\n>> \n>>       merge (B) A # Merge...\n>> \n>> instead?\n> \n> Or even better:\n> \n>         merge B parent A' # Merge...\n\nmerge B with A' # Merge... \n\n;-)\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"101835","messageId":"alpine.DEB.1.00.0901251509550.14855@racer","threadId":"17344","inReplyTo":"glhqdi$tec$1@ger.gmane.org","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-25T14:17:10Z","receivedAt":"2009-01-25T14:17:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[please do not forget to Cc: me; today is a slow day, so I did not miss \n your mail, but that is definitely not true on other days.]\n\nOn Sun, 25 Jan 2009, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> >> Hmm.  You're right, that is not really intuitive.  How about\n> >> \n> >>       merge (B) A # Merge...\n> >> \n> >> instead?\n> > \n> > Or even better:\n> > \n> >         merge B parent A' # Merge...\n> \n> merge B with A' # Merge... \n\nNo, that does not catch the meaning.\n\nB is the _original_ merge commit. So it actually knows what parents it \nhas, but we want to give the user the freedom to change those parents.\n\nThe first parent is easy: this will be HEAD at that stage.\n\nThe other parents will be relatively easy: just replace A' by something \nelse.\n\n_However_ now that the merge commit B will be _redone_, we _still_ want to \nbe able to refer to it later in the rebase script. Therefore, rebase has \nto know that we _redid_ B at this stage.\n\nAnother idea:\n\n\tmerge B Merge bla/blub\n\tparent A' bla/blub\n\nHmm?\n\nCiao,\nDscho\n"},{"id":"101837","messageId":"bd6139dc0901250707m5e1898cdu530a0d7566ca2da5@mail.gmail.com","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901251509550.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-25T15:07:08Z","receivedAt":"2009-01-25T15:07:08Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Jan 25, 2009 at 15:17, Johannes Schindelin\n wrote:\n>> >> merge (B) A # Merge...\n>> > merge B parent A' # Merge...\n>> merge B with A' # Merge...\n> merge B Merge bla/blub\n> parent A' bla/blub\n\nOh goody, more painting! I was wondering when the next pick-a-word\ncontest would be!\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"101838","messageId":"alpine.DEB.1.00.0901251622310.14855@racer","threadId":"17344","inReplyTo":"bd6139dc0901250707m5e1898cdu530a0d7566ca2da5@mail.gmail.com","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-25T15:24:46Z","receivedAt":"2009-01-25T15:24:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jan 2009, Sverre Rabbelier wrote:\n\n> On Sun, Jan 25, 2009 at 15:17, Johannes Schindelin\n> wrote:\n> >> >> merge (B) A # Merge...\n> >> > merge B parent A' # Merge...\n> >> merge B with A' # Merge...\n> > merge B Merge bla/blub\n> > parent A' bla/blub\n> \n> Oh goody, more painting! I was wondering when the next pick-a-word\n> contest would be!\n\nIn this case, it is not about painting. I will gladly ignore all those \nwho think they must submit a new word for this action.\n\nThe thing is: I want the command to be intuitive, so I need a syntax where \neven the most idiotic dullard will understand what are the parents, and \nwhy we need the original merge's commit name, too.\n\nSo maybe I answered my question myself:\n\n\tmerge parents $sha1 [$sha1...] original $sha1 $msg\n\nCiao,\nDscho\n"},{"id":"101839","messageId":"200901251722.53392.jnareb@gmail.com","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901251509550.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-01-25T16:22:52Z","receivedAt":"2009-01-25T16:22:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 25 Jan 2009, Johannes Schindelin wrote:\n> Hi,\n> \n> [please do not forget to Cc: me; today is a slow day, so I did not miss \n> your mail, but that is definitely not true on other days.]\n\nThis was spur of the moment idea, one that I wouldn't mind if you\nwould miss it.\n\nBut now that you have something interesting to say, I'll re-added\nCC list for this thread.\n\n> On Sun, 25 Jan 2009, Jakub Narebski wrote:\n>> Johannes Schindelin wrote:\n>> \n>>>> Hmm.  You're right, that is not really intuitive.  How about\n>>>> \n>>>>       merge (B) A # Merge...\n>>>> \n>>>> instead?\n>>> \n>>> Or even better:\n>>> \n>>>         merge B parent A' # Merge...\n>> \n>> merge B with A' # Merge... \n> \n> No, that does not catch the meaning.\n\nErrr... I didn't mean for 'with' to mean 'into'.\n \n> B is the _original_ merge commit. So it actually knows what parents it \n> has, but we want to give the user the freedom to change those parents.\n> \n> The first parent is easy: this will be HEAD at that stage.\n> \n> The other parents will be relatively easy: just replace A' by something \n> else.\n> \n> _However_ now that the merge commit B will be _redone_, we _still_ want to \n> be able to refer to it later in the rebase script. Therefore, rebase has \n> to know that we _redid_ B at this stage.\n> \n> Another idea:\n> \n> \tmerge B Merge bla/blub\n> \tparent A' bla/blub\n\nIt would be good idea... even better if 'p' shortcut was not taken\nby 'pick'...\n\nThis is similar to your earlier idea:\n\n merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next\n # \\ 9383af1 Revert previous two commits\n\n\nOr perhaps:\n\n\tmerge A' D' into B Merge bla/blub\n\n-- \nJakub Narebski\nPoland\n"},{"id":"101841","messageId":"20090125171821.GA5881@atjola.homenet","threadId":"17344","inReplyTo":"200901251722.53392.jnareb@gmail.com","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-01-25T17:18:21Z","receivedAt":"2009-01-25T17:18:21Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.01.25 17:22:52 +0100, Jakub Narebski wrote:\n> Or perhaps:\n> \n> \tmerge A' D' into B Merge bla/blub\n\nThat would be confusing. I'd read it as:\n\ngit checkout B\ngit merge A' D'\n\nBut the point of B is just to tell rebase that the original merge commit\nB is replaced by this new merge commit, so that B' works later.\n\nBjörn\n"},{"id":"101871","messageId":"7vwscjceec.fsf@gitster.siamese.dyndns.org","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901251622310.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-25T20:35:39Z","receivedAt":"2009-01-25T20:35:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So maybe I answered my question myself:\n>\n> \tmerge parents $sha1 [$sha1...] original $sha1 $msg\n\nWhen you are reparenting, how would original commit get in the picture?\nYou wouldn't want the resulting merge to claim it merged X (which would be\nwhat's in original's commit log) when in fact it now merged Y because the\nuser reparented it, would you?\n"},{"id":"101876","messageId":"alpine.DEB.1.00.0901252157090.14855@racer","threadId":"17344","inReplyTo":"7vwscjceec.fsf@gitster.siamese.dyndns.org","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-25T20:59:17Z","receivedAt":"2009-01-25T20:59:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jan 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > So maybe I answered my question myself:\n> >\n> > \tmerge parents $sha1 [$sha1...] original $sha1 $msg\n> \n> When you are reparenting, how would original commit get in the picture?\n> You wouldn't want the resulting merge to claim it merged X (which would be\n> what's in original's commit log) when in fact it now merged Y because the\n> user reparented it, would you?\n\nOh yes, I would! Example:\n\n\n\tA - B - C\n\t /\n\tX - Y\n\nIf I merged X into B by accident, but actually meant to merge Y, then C' \nshould still come after B', no?\n\nCiao,\nDscho\n"},{"id":"101882","messageId":"200901252303.29204.jnareb@gmail.com","threadId":"17344","inReplyTo":"7vwscjceec.fsf@gitster.siamese.dyndns.org","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-01-25T22:03:28Z","receivedAt":"2009-01-25T22:03:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 25 Jan 2009, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > So maybe I answered my question myself:\n> >\n> > \tmerge parents $sha1 [$sha1...] original $sha1 $msg\n> \n> When you are reparenting, how would original commit get in the picture?\n> You wouldn't want the resulting merge to claim it merged X (which would be\n> what's in original's commit log) when in fact it now merged Y because the\n> user reparented it, would you?\n\nWell, the subject part of merge (with merged branches names) shouldn't,\nI guess, change. The summary (shortlog) part might, or perhaps even\nshould following rewrite (if it was present here).\n\nBut there is one issue I am wondering about: could we pick up _merge_\n_resolution_? So if you have evil merge, and the change is for example\nsplitting commits without visible final changes, or just changing some\ncommit message before merge, it would get recreated without problems?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"101902","messageId":"alpine.DEB.1.00.0901260026310.14855@racer","threadId":"17344","inReplyTo":"200901252303.29204.jnareb@gmail.com","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-25T23:29:43Z","receivedAt":"2009-01-25T23:29:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Jan 2009, Jakub Narebski wrote:\n\n> On Sun, 25 Jan 2009, Junio C Hamano wrote:\n> > Johannes Schindelin writes:\n> > \n> > > So maybe I answered my question myself:\n> > >\n> > > \tmerge parents $sha1 [$sha1...] original $sha1 $msg\n> > \n> > When you are reparenting, how would original commit get in the \n> > picture? You wouldn't want the resulting merge to claim it merged X \n> > (which would be what's in original's commit log) when in fact it now \n> > merged Y because the user reparented it, would you?\n> \n> Well, the subject part of merge (with merged branches names) shouldn't, \n> I guess, change. The summary (shortlog) part might, or perhaps even \n> should following rewrite (if it was present here).\n> \n> But there is one issue I am wondering about: could we pick up _merge_ \n> _resolution_? So if you have evil merge, and the change is for example \n> splitting commits without visible final changes, or just changing some \n> commit message before merge, it would get recreated without problems?\n\nNanako had a script at some stage; I would prefer an subcommand to \"git \nrerere\" which reconstructs the whole merge in-memory, and then records the \nconflict's resolution.\n\nHowever, I really think you are getting ahead of yourself. That is by no \nmeans something we want to have in rebase -p. And even then, it would \nhave to be non-automatic, i.e the user has to check the resolution.\n\nWe _know_ that git rerere does a fine job most of the time, almost all of \nthe exceptions to be found when working with rebase -i extensively, as you \nare prone to take different decisions during development.\n\nCiao,\nDscho\n"},{"id":"102006","messageId":"497DE08D.2030306@xiplink.com","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901242056070.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2009-01-26T16:10:53Z","receivedAt":"2009-01-26T16:10:53Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Johannes Schindelin wrote:\n> \n> - $sha1'\n> \n> \tfor merge and goto, if a $sha1 ends in a single quote, the \n> \trewritten commit is substituted (if there is one)\n\nI find this notation fairly unintuitive. I'm more inclined to let users \nspecify their own names for important parts of the rebase.\n\nI guess that's what Junio's 'mark' command is for, but not having seen a \nproper explanation of 'mark', I suggest instead a more inline method: an \n'as' keyword. Any command in a todo script can be followed (on the same \nline, before the SHA1 value) with 'as ' allowing to appear \nlater in the script to refer to the result of the earlier command.\n\nSo the script in the example becomes\n\n\tpick as start A\n\tpick C\n\tpick as bottom D\n\tgoto start\n\tpick B\n\tmerge bottom was E\n\nI find that much easier to understand. Especially when real SHA1 values \nare floating around everywhere, I think this notation will help users \nget things right.\n\nThis approach also allows a commit name \"A\" to consistently refer to the \noriginal commit, which I think also makes things easier for users.\n\n\t\tM.\n"},{"id":"101996","messageId":"497DE318.2070603@xiplink.com","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901242156320.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2009-01-26T16:21:44Z","receivedAt":"2009-01-26T16:21:44Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"I'm sorry, but I just don't understand the purpose of 'was E' (or \nwhatever syntax) in the merge command. Why is there a need to refer to \nE at all? The only reason I can think of is to replicate E's commit \nmessage. Am I missing something?\n\nCome to think of it, what if the user wants to edit a merge commit's \nmessage? Should there be an 'editmerge' command?\n\n\t\tM.\n\n\nJohannes Schindelin wrote:\n>\n>> - Why do you need \"merge D' was E\"? Shouldn't \"pick E\" be able to \n>> notice that E is a merge and decompose it into \"merge D' was E\" \n>> internally?\n>>\n>> This one I am somewhat complaining, unless your answer is \"because \n>> this way the user could drop some parents from the merge in the \n>> editor\".\n> \n> Not only that; the user could use this to fix mismerges, i.e. by replacing \n> a SHA-1 with the SHA-1 (or indeed, a short name, unless it is \"was\") of \n> the branch that she _actually_ wanted to merge with.\n> \n>> And if your answer is that, then my next question will be \"if that is \n>> the case, can the user be expected to easily find out which commit \n>> each parent SHA-1 refers to, without having more hint on the 'merge' \n>> insn line?\"\n> \n> Nope.\n> \n> In most cases, however, that should be plenty enough:\n> \n> \tmerge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next\n> \n> The user does not have to guess much what 9383af1 might refer to.\n"},{"id":"102124","messageId":"20090127092117.d13f24e7.stephen@exigencecorp.com","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901242056070.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2009-01-27T15:21:17Z","receivedAt":"2009-01-27T15:21:17Z","isPatch":false,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> I am very sorry if somebody actually scripted rebase -i -p (by setting\n> GIT_EDITOR with a script), but I am very certain that this cleanup is\n> absolutely necessary to make rebase -i -p useful.\n\nI have scripted rebase-i-p, but with GIT_EDITOR=: [1]. I assume this\nwill still work and just accept the default script?\n\n(Er, maybe I can just use rebase-p...I forget why [1] is using the\nGIT_EDITOR=: with -i.)\n\nMy primary pain point with rebase-i-p has been rebasing a branch that\nhas merged in another branch that has a lot of commits on it. E.g.:\n\n a -- b -- c origin/feature\n \\\n d -- e feature\n /\n ... g origin/master\n\nWhere e is merging in, say, a latest release that had a few hundred\ncommits in the master branch. After resolving conflicts/etc. in e, I\nwant to rebase d..e from a to be on c.\n\nThe two problems have been:\n\n1) `git pull` with rebase set uses rebase-i, with no -p, so all of the\n commits from the latest release branch that got merged in with e are\n flattened/duplicated. This is what [1] tries to fix. I've made\n noises about hacking the branch rebase flag but haven't followed\n through.\n\n I know this is a git pull issue, but I bring it up because, IIRC, the\n t3410 test case came from a scenario where I was rebasing a merge\n like e above and due to --cherry-pick dropping a commit (probably e\n itself, I'm not sure), rebase-i-p as it existed then broke and\n produced a noop. So I set off to get it to do \"something\" and ended\n up introducing the \"DROPPED\" directory.\n\n2) With manual invocation of `rebase-i-p`, previously you'd get a\n laundry list of commits from the e merge that are new to the feature\n branch, but since g and its ancestors aren't changing, you don't need\n to consider them in the script and so its (potentially a lot of)\n noise. This is what the parent probing back port from git sequencer\n addressed.\n\nSo, I don't mean to rehash old complaints, as I'd love to see the\nrebase-i-p code cleaned up by someone who can really refactor it vs. my\nhack patches. But I wanted to emphasize the motivation for my hacks over\ntheir implementation so that hopefully you can still address these use\ncases in the new version.\n\nThanks,\nStephen\n\n[1]: http://github.com/stephenh/git-central/blob/master/scripts/pull\n"},{"id":"102148","messageId":"alpine.DEB.1.00.0901271903210.3586@pacific.mpi-cbg.de","threadId":"17344","inReplyTo":"20090127092117.d13f24e7.stephen@exigencecorp.com","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-27T18:08:04Z","receivedAt":"2009-01-27T18:08:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Jan 2009, Stephen Haberman wrote:\n\n> > I am very sorry if somebody actually scripted rebase -i -p (by setting \n> > GIT_EDITOR with a script), but I am very certain that this cleanup is \n> > absolutely necessary to make rebase -i -p useful.\n> \n> I have scripted rebase-i-p, but with GIT_EDITOR=: [1]. I assume this\n> will still work and just accept the default script?\n\nYes, this will still work. AFAICT this is actually how git \n--no-interactive -p is implemented...\n\n> (Er, maybe I can just use rebase-p...I forget why [1] is using the\n> GIT_EDITOR=: with -i.)\n\nSee above... :-)\n\n> My primary pain point with rebase-i-p has been rebasing a branch that\n> has merged in another branch that has a lot of commits on it. E.g.:\n> \n> a -- b -- c origin/feature\n> \\\n> d -- e feature\n> /\n> ... g origin/master\n> \n> Where e is merging in, say, a latest release that had a few hundred\n> commits in the master branch. After resolving conflicts/etc. in e, I\n> want to rebase d..e from a to be on c.\n> \n> The two problems have been:\n> \n> 1) `git pull` with rebase set uses rebase-i, with no -p, so all of the\n> commits from the latest release branch that got merged in with e are\n> flattened/duplicated.\n\nMaybe teach git pull about --rebase=preserve[-merges] and \nbranch..rebase=preserve[-merges]?\n\n> 2) With manual invocation of `rebase-i-p`, previously you'd get a\n> laundry list of commits from the e merge that are new to the feature\n> branch, but since g and its ancestors aren't changing, you don't need\n> to consider them in the script and so its (potentially a lot of)\n> noise. This is what the parent probing back port from git sequencer\n> addressed.\n\nI always meant to handle that in the fast-forward handling of pick_one().\n\n> So, I don't mean to rehash old complaints, as I'd love to see the \n> rebase-i-p code cleaned up by someone who can really refactor it vs. my \n> hack patches. But I wanted to emphasize the motivation for my hacks over \n> their implementation so that hopefully you can still address these use \n> cases in the new version.\n\nWell, let's see how things turn out once I use the patches for my own \nwork...\n\nThanks,\nDscho\n"},{"id":"102169","messageId":"20090128071054.6117@nanako3.lavabit.com","threadId":"17344","inReplyTo":"20090127092117.d13f24e7.stephen@exigencecorp.com","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-01-27T22:10:54Z","receivedAt":"2009-01-27T22:10:54Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Stephen Haberman :\n\n> My primary pain point with rebase-i-p has been rebasing a branch that\n> has merged in another branch that has a lot of commits on it. E.g.:\n>\n> a -- b -- c origin/feature\n> \\\n> d -- e feature\n> /\n> ... g origin/master\n>\n> Where e is merging in, say, a latest release that had a few hundred\n> commits in the master branch. After resolving conflicts/etc. in e, I\n> want to rebase d..e from a to be on c.\n\nSorry for asking a basic question, but if \"feature\" is a topic branch for advance the feature, why are you merging origin/master into it? Doesn't it blur the theme of the branch by including \"development of the feature and all the random things that happened while it was being developed in other places\"?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"102179","messageId":"20090127163650.34581368.stephen@exigencecorp.com","threadId":"17344","inReplyTo":"20090128071054.6117@nanako3.lavabit.com","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Stephen Haberman","fromEmail":"stephen@exigencecorp.com","sentAt":"2009-01-27T22:36:50Z","receivedAt":"2009-01-27T22:36:50Z","isPatch":false,"sender":{"key":"stephen@exigencecorp.com","avatar":"https://gravatar.com/avatar/23b93ad70a06ce53505f17ddba65176edbcfb6588e7a4c1a2dca04aaf0a6aff1?d=mp&s=160"},"body":"\n> > a -- b -- c origin/feature\n> > \\\n> > d -- e feature\n> > /\n> > ... g origin/master\n\n> Sorry for asking a basic question, but if \"feature\" is a topic branch\n> for advance the feature, why are you merging origin/master into it?\n> Doesn't it blur the theme of the branch by including \"development of\n> the feature and all the random things that happened while it was being\n> developed in other places\"?\n\nWe merged origin/master because a release had just happened (e.g. master\nmoved from 1.0 -> 1.1), and when QA looks at origin/feature, they wanted\nto see it integrated with the latest release (e.g. 1.1).\n\nNow, granted, if feature was a private/unpublished branch, we would\nrebase the entire thing (a/b/c) on top of master (g), but a/b/c has\nalready been published to our bug tracker, email lists, and other\ndevelopers who are collaborating on origin/feature, so between polluting\nfeature with a merge from master and changing the published hashes, we\nchose the merge.\n\n- Stephen\n"},{"id":"102946","messageId":"20090203190517.6117@nanako3.lavabit.com","threadId":"17344","inReplyTo":"alpine.DEB.1.00.0901260026310.14855@racer","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-02-03T10:05:17Z","receivedAt":"2009-02-03T10:05:17Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Johannes Schindelin :\n\n> Nanako had a script at some stage; I would prefer an subcommand to \"git \n> rerere\" which reconstructs the whole merge in-memory, and then records the \n> conflict's resolution.\n\nI'm sorry but I'm not sure what script of mine you are referring to.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"102952","messageId":"alpine.DEB.1.00.0902031247070.6573@intel-tinevez-2-302","threadId":"17344","inReplyTo":"20090203190517.6117@nanako3.lavabit.com","subject":"Re: Heads up: major rebase -i -p rework coming up","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-03T11:47:17Z","receivedAt":"2009-02-03T11:47:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 3 Feb 2009, Nanako Shiraishi wrote:\n\n> Quoting Johannes Schindelin :\n> \n> > Nanako had a script at some stage; I would prefer an subcommand to \n> > \"git rerere\" which reconstructs the whole merge in-memory, and then \n> > records the conflict's resolution.\n> \n> I'm sorry but I'm not sure what script of mine you are referring to.\n\nhttp://article.gmane.org/gmane.comp.version-control.git/96911\n\nCiao,\nDscho\n"}]}