{"thread":{"id":"28315","subject":"git-rebase skips automatically no more needed commits","startedAt":"2011-09-06T16:08:48Z","lastAt":"2011-09-28T14:49:05Z","messageCount":19,"participants":["Francis Moreau","Junio C Hamano","Michael J Gruber","Martin von Zweigbergk","Ramkumar Ramachandra","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174935","messageId":"CAC9WiBg9+30NjO+NKXVdBiWjR-HU2689JQqVY7Rk5+DM7MiNBg@mail.gmail.com","threadId":"28315","inReplyTo":null,"subject":"git-rebase skips automatically no more needed commits","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-09-06T16:08:48Z","receivedAt":"2011-09-06T16:08:48Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hello,\n\nWhen rebasing my current branch onto the last master one, there're\nsometimes some commits which doesn't add anything anymore.\n\nCurrently git-rebase produces the following message:\n\n nothing added to commit but untracked files present (use \"git add\" to track)\n\nWould it be possible to add a new option to this command so it simply\nskip the unneeded commit ?\n\nThanks\n-- \nFrancis\n"},{"id":"174942","messageId":"7v1uvta97o.fsf@alter.siamese.dyndns.org","threadId":"28315","inReplyTo":"CAC9WiBg9+30NjO+NKXVdBiWjR-HU2689JQqVY7Rk5+DM7MiNBg@mail.gmail.com","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-06T17:09:47Z","receivedAt":"2011-09-06T17:09:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Francis Moreau writes:\n\n> When rebasing my current branch onto the last master one, there're\n> sometimes some commits which doesn't add anything anymore.\n>\n> Currently git-rebase produces the following message:\n>\n> nothing added to commit but untracked files present (use \"git add\" to track)\n>\n> Would it be possible to add a new option to this command so it simply\n> skip the unneeded commit ?\n\nOur assumption has always been that it is a notable event that a patch\nthat does not get filtered with internal \"git cherry\" (which culls patches\nthat are textually identical to those that are already merged to the\nhistory you are rebasing onto) becomes totally unneeded and is safe to ask\nfor human confirmation in the form of \"rebase --skip\" than to ignore it\nand give potentially incorrect result silently.\n\nObviously you do not find it a notable event for some reason. We would\nneed to understand why, and if the reason is sensible, it _might_ make\nsense to allow a user to say \"git rebase --ignore-merged\" or something\nwhen starting the rebase.\n"},{"id":"174948","messageId":"CAC9WiBjrfJeJ854dkJMPwRSwuujRsYLnAd7QX7C_oU8_FdOvQA@mail.gmail.com","threadId":"28315","inReplyTo":"7v1uvta97o.fsf@alter.siamese.dyndns.org","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-09-06T19:28:41Z","receivedAt":"2011-09-06T19:28:41Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hello Junio,\n\nOn Tue, Sep 6, 2011 at 7:09 PM, Junio C Hamano wrote:\n>\n> Our assumption has always been that it is a notable event that a patch\n> that does not get filtered with internal \"git cherry\" (which culls patches\n> that are textually identical to those that are already merged to the\n> history you are rebasing onto) becomes totally unneeded and is safe to ask\n> for human confirmation in the form of \"rebase --skip\" than to ignore it\n> and give potentially incorrect result silently.\n\nOk then I think this \"git cherry\" filtering is not working in my case\nsince it seems to me that commit that I cherry-picked are not\nfiltered, please see below.\n\n>\n> Obviously you do not find it a notable event for some reason. We would\n> need to understand why, and if the reason is sensible, it _might_ make\n> sense to allow a user to say \"git rebase --ignore-merged\" or something\n> when starting the rebase.\n\nMy use case is the following: I'm maintaining a branch from an\nupstream project (the kernel one). While the upstream project follows\nits development cycle (including some fixes), my branch is stuck. I\nsometime want to includes (or rather backport) some commits that\nhappened later in the development cycle. To do that I use \"git\ncherry-pick\".\n\nAfter some period, I'm allowed to rebase to a more recent commit from\nthe upstream project and this rebase 'cancel' the previous 'git\ncherry-pick' I did. But for some reasons, git telling me \"nothing\nadded to commit ...\", which is expected in my case, well I think,\nhence my question.\n\nThanks.\n-- \nFrancis\n"},{"id":"174995","messageId":"4E676F6A.3060906@drmicha.warpmail.net","threadId":"28315","inReplyTo":"CAC9WiBjrfJeJ854dkJMPwRSwuujRsYLnAd7QX7C_oU8_FdOvQA@mail.gmail.com","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-09-07T13:19:38Z","receivedAt":"2011-09-07T13:19:38Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Francis Moreau venit, vidit, dixit 06.09.2011 21:28:\n> Hello Junio,\n> \n> On Tue, Sep 6, 2011 at 7:09 PM, Junio C Hamano wrote:\n>>\n>> Our assumption has always been that it is a notable event that a patch\n>> that does not get filtered with internal \"git cherry\" (which culls patches\n>> that are textually identical to those that are already merged to the\n>> history you are rebasing onto) becomes totally unneeded and is safe to ask\n>> for human confirmation in the form of \"rebase --skip\" than to ignore it\n>> and give potentially incorrect result silently.\n> \n> Ok then I think this \"git cherry\" filtering is not working in my case\n> since it seems to me that commit that I cherry-picked are not\n> filtered, please see below.\n> \n>>\n>> Obviously you do not find it a notable event for some reason. We would\n>> need to understand why, and if the reason is sensible, it _might_ make\n>> sense to allow a user to say \"git rebase --ignore-merged\" or something\n>> when starting the rebase.\n> \n> My use case is the following: I'm maintaining a branch from an\n> upstream project (the kernel one). While the upstream project follows\n> its development cycle (including some fixes), my branch is stuck. I\n> sometime want to includes (or rather backport) some commits that\n> happened later in the development cycle. To do that I use \"git\n> cherry-pick\".\n> \n> After some period, I'm allowed to rebase to a more recent commit from\n> the upstream project and this rebase 'cancel' the previous 'git\n> cherry-pick' I did. But for some reasons, git telling me \"nothing\n> added to commit ...\", which is expected in my case, well I think,\n> hence my question.\n> \n> Thanks.\n\nUnless you had to resolve a conflict when cherry-picking, the picked\ncommit should be patch-equivalent to the original one, and thus dropped\nby rebase automatically.\n\nHow do the two patches compare:\n\ngit show $picked >a\ngit show $original >b\ngit patch-id writes:\n\n> If I start the rebase process with : \"git rebase -i -p master foo\"\n> then the filtering is happening. Here 'foo' has been created with\n> v2.6.39 tag as start point and contains some patches cherry-picked\n> from the upstream.\n>\n> However if I call git-rebase this way: \"git rebase -i -p --onto master\n> v2.6.39 foo\", then it seems that no filtering is done.\n>\n> Is that expected ?\n\nBecause \"rebase --onto A B C\" has to be usable when commit A does not have\nany ancestry relationship with the history between B and C, I wouldn't be\nsurprised if the command does not look at commits on the history that lead\nto A that _might_ be related to the ones between B and C. It does not know\nhow far to dig from A and stop, and obviously you do not want to dig down\nto the beginning of the history. \"rebase A B\" on the other hand can safely\nstop digging the history back from A down to where the history leading to\nB forked (i.e. merge base between A and B).\n\nI do not know if \"expected\" is the right adjective; understandable---yes,\nunsurprised---yes, justifiable--- I dunno.\n"},{"id":"175070","messageId":"CAC9WiBjMUg3SUOP9AJw6qCKrGVLs6Qy_O2fQa_SHX30NkjAEdw@mail.gmail.com","threadId":"28315","inReplyTo":"7vk49k48q4.fsf@alter.siamese.dyndns.org","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-09-08T07:10:08Z","receivedAt":"2011-09-08T07:10:08Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano wrote:\n> Francis Moreau writes:\n>\n>> If I start the rebase process with : \"git rebase -i -p master foo\"\n>> then the filtering is happening. Here 'foo' has been created with\n>> v2.6.39 tag as start point and contains some patches cherry-picked\n>> from the upstream.\n>>\n>> However if I call git-rebase this way: \"git rebase -i -p --onto master\n>> v2.6.39 foo\", then it seems that no filtering is done.\n>>\n>> Is that expected ?\n>\n> Because \"rebase --onto A B C\" has to be usable when commit A does not have\n> any ancestry relationship with the history between B and C,\n\nBut is it the common case ? That would mean that A and B are part of\ntotaly independant branches which is not that common I think.\n\nI'm using \"git rebase --onto A B C\" because I want to simplify git's\nwork. I know that any commits between A..B are already in A history\nand I'm not interested in rebasing them anyways.\n\n> I wouldn't be\n> surprised if the command does not look at commits on the history that lead\n> to A that _might_ be related to the ones between B and C. It does not know\n> how far to dig from A and stop, and obviously you do not want to dig down\n> to the beginning of the history. \"rebase A B\" on the other hand can safely\n> stop digging the history back from A down to where the history leading to\n> B forked (i.e. merge base between A and B).\n\nHmm I dont understand why \"rebase --onto A B C\" wouldn't try to find\nthe merge base between A and B. If it doesn't (which is quite uncommon\nI guess) then don't do the filtering as we're currently doing but if\nthere's a merge base (common case) then do the filtering.\n\nNo ?\n-- \nFrancis\n"},{"id":"175091","messageId":"alpine.DEB.2.00.1109080753460.12564@debian","threadId":"28315","inReplyTo":"CAC9WiBjMUg3SUOP9AJw6qCKrGVLs6Qy_O2fQa_SHX30NkjAEdw@mail.gmail.com","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-08T13:14:20Z","receivedAt":"2011-09-08T13:14:20Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, 8 Sep 2011, Francis Moreau wrote:\n\n> On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano wrote:\n> > Francis Moreau writes:\n> >\n> >> If I start the rebase process with : \"git rebase -i -p master foo\"\n> >> then the filtering is happening. Here 'foo' has been created with\n> >> v2.6.39 tag as start point and contains some patches cherry-picked\n> >> from the upstream.\n> >>\n> >> However if I call git-rebase this way: \"git rebase -i -p --onto master\n> >> v2.6.39 foo\", then it seems that no filtering is done.\n\nPatches that are in both sides of v2.6.39...foo will be filtered, but\nas Junio said, what is in master is not considered. In your case,\nsince foo was created from the tag, there should of course be no\ncommits in foo..v2.6.39.\n\n> I'm using \"git rebase --onto A B C\" because I want to simplify git's\n> work.\n\nWhat work? Calculating mege-base and patch-ids? But that's exactly\nwhat you said you don't want to avoid, no?\n\n> I know that any commits between A..B are already in A history\n\nDid you mean \"B..A\" here?\n\n> and I'm not interested in rebasing them anyways.\n\nThey wouldn't be rebased by running \"git rebase A C\" either... Maybe\nI'm misunderstanding something.\n\n> Hmm I dont understand why \"rebase --onto A B C\" wouldn't try to find\n> the merge base between A and B. If it doesn't (which is quite uncommon\n> I guess) then don't do the filtering as we're currently doing but if\n> there's a merge base (common case) then do the filtering.\n\nIt could do that. I think that's what Junio meant by \"justifiable--- I\ndunno\". In your case, though, it seems like \"git rebase master foo\"\nwould do exactly what you want.\n\nSomewhat related, I think \"git rebase --onto A B C\" should NOT filter\nout patches that also appear both sides of \"B...C\", because when\n\"--onto\" is used, \"B\" is only used as a way to calculate the\nmerge-base. I think it would make more sense to filter out from\nappears in both \"B..C\" what also appears in \"C..A\". This has been on\nmy todo list for way too long. Some day I'll send out a patch for it\nand we'll see what others think.\n\n\nMartin\n"},{"id":"175146","messageId":"alpine.DEB.2.00.1109082123300.12564@debian","threadId":"28315","inReplyTo":"CAC9WiBiMYUfaPtrXyW=W7qaZnJqLeFO-B3od7X4u8wUrb8hfUA@mail.gmail.com","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-09T02:23:29Z","receivedAt":"2011-09-09T02:23:29Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, 8 Sep 2011, Francis Moreau wrote:\n\n> On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk\n> wrote:\n> >\n> > Patches that are in both sides of v2.6.39...foo will be filtered, but\n> \n> what do you mean by \"both sides\" ?\n\nSee the section called \"SPECIFYING RANGES\" in \"git --help\nrev-parse\". It doesn't define \"both sides\", but what I mean by that is\n\"both in v2.6.39..foo and in foo..v2.6.39\". I believe that section\nwill answer most of the other questions too.\n\n> Yes my use of \"git rebase --onto master foo~10 foo\" is equivalent to\n> \"git rebase master foo, the only difference is that the --onto variant\n> allow me to limit the range of commits that I want to rebase. So I\n> still want git rebase to do its the filtering process.\n\nOk, that is different. I think you used v2.6.39 instead of foo~10\npreviously. Assuming that v2.6.39 is the merge base of foo and master\nand that foo~10 is a later commit than v2.6.39, you are right that\n\"git rebase --onto master foo~10 foo\" could potentially filter out\npatches already in foo..master, without calculating patch-ids for all\ncommits in master..foo for that matter. I think that would make sense\nand as I said, it has been on my todo list for a long time. If\nnecessary, we could have a flag to disable the filtering e.g. when the\nuser knows that master is part of a completely separate history from\nfoo.\n\n\nMartin\n"},{"id":"175150","messageId":"CAC9WiBhApjEr-NYm9NkyXaZPNCivoJ65c=xx2bg5Li60kfZMTQ@mail.gmail.com","threadId":"28315","inReplyTo":"alpine.DEB.2.00.1109082123300.12564@debian","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-09-09T06:43:17Z","receivedAt":"2011-09-09T06:43:17Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk\n wrote:\n> On Thu, 8 Sep 2011, Francis Moreau wrote:\n>\n>> On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk\n>> wrote:\n>> >\n>> > Patches that are in both sides of v2.6.39...foo will be filtered, but\n>>\n>> what do you mean by \"both sides\" ?\n>\n> See the section called \"SPECIFYING RANGES\" in \"git --help\n> rev-parse\". It doesn't define \"both sides\", but what I mean by that is\n> \"both in v2.6.39..foo and in foo..v2.6.39\". I believe that section\n> will answer most of the other questions too.\n>\n>> Yes my use of \"git rebase --onto master foo~10 foo\"  is equivalent to\n>> \"git rebase master foo, the only difference is that the --onto variant\n>> allow me to limit the range of commits that I want to rebase. So I\n>> still want git rebase to do its the filtering process.\n>\n> Ok, that is different. I think you used v2.6.39 instead of foo~10\n> previously. Assuming that v2.6.39 is the merge base of foo and master\n> and that foo~10 is a later commit than v2.6.39,\n\nThat's what I meant.\n\n> you are right that\n> \"git rebase --onto master foo~10 foo\" could potentially filter out\n> patches already in foo..master, without calculating patch-ids for all\n> commits in master..foo for that matter. I think that would make sense\n\nyou meant master..foo~10, didn't you ?\n\n> and as I said, it has been on my todo list for a long time. If\n\nplease let me know when you submitting your work, I'm interested to see it.\n\n> necessary, we could have a flag to disable the filtering e.g. when the\n> user knows that master is part of a completely separate history from\n> foo.\n\nCan't git figure this out itself ? (I'm not saying the switch is useless)\n\nThanks\n-- \nFrancis\n"},{"id":"175181","messageId":"alpine.DEB.2.00.1109090900301.12564@debian","threadId":"28315","inReplyTo":"CAC9WiBhApjEr-NYm9NkyXaZPNCivoJ65c=xx2bg5Li60kfZMTQ@mail.gmail.com","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-09T13:06:36Z","receivedAt":"2011-09-09T13:06:36Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Fri, 9 Sep 2011, Francis Moreau wrote:\n\n> On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk\n> wrote:\n> \n> > you are right that\n> > \"git rebase --onto master foo~10 foo\" could potentially filter out\n> > patches already in foo..master, without calculating patch-ids for all\n> > commits in master..foo for that matter. I think that would make sense\n> \n> you meant master..foo~10, didn't you ?\n\nYes. (I actually did mean \"all commits in master..foo\", but \"_any_\ncommits in master..foo~10\" is more clear and exact.)\n\n> please let me know when you submitting your work, I'm interested to see it.\n\nWill do. It's not really that much work, but I'm not sure when I will\nhave time for it. If you or anyone else is interested in doing it, you\nare of course welcome.\n\n> > necessary, we could have a flag to disable the filtering e.g. when the\n> > user knows that master is part of a completely separate history from\n> > foo.\n> \n> Can't git figure this out itself ? (I'm not saying the switch is useless)\n\nYes, but this hypothetical flag would only be to speed things up by\navoid going to the roots to find out that the histories are disjoint.\n\nMartin\n"},{"id":"175182","messageId":"CAC9WiBj0TJa44Ay4e8=VyMzfUGxWd1NW8rjrxxkCSx5K6BthRw@mail.gmail.com","threadId":"28315","inReplyTo":"alpine.DEB.2.00.1109090900301.12564@debian","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-09-09T13:25:24Z","receivedAt":"2011-09-09T13:25:24Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"On Fri, Sep 9, 2011 at 3:06 PM, Martin von Zweigbergk\n wrote:\n> On Fri, 9 Sep 2011, Francis Moreau wrote:\n>\n>> On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk\n>> wrote:\n>>\n>> > you are right that\n>> > \"git rebase --onto master foo~10 foo\" could potentially filter out\n>> > patches already in foo..master, without calculating patch-ids for all\n>> > commits in master..foo for that matter. I think that would make sense\n>>\n>> you meant master..foo~10, didn't you ?\n>\n> Yes. (I actually did mean \"all commits in master..foo\", but \"_any_\n> commits in master..foo~10\" is more clear and exact.)\n>\n>> please let me know when you submitting your work, I'm interested to see it.\n>\n> Will do. It's not really that much work, but I'm not sure when I will\n> have time for it. If you or anyone else is interested in doing it, you\n> are of course welcome.\n\nI'm a simple mortal user ;)\n\n>\n>> > necessary, we could have a flag to disable the filtering e.g. when the\n>> > user knows that master is part of a completely separate history from\n>> > foo.\n>>\n>> Can't git figure this out itself ? (I'm not saying the switch is useless)\n>\n> Yes, but this hypothetical flag would only be to speed things up by\n> avoid going to the roots to find out that the histories are disjoint.\n\nYou're right but in my (mortal) experience, I'm always rebasing\nbranches onto another one which is not disjoint, so I'm assuming it's\nthe (very) common case, but I may be wrong. And what I'm assuming is\ncorrect, I think it's make more sense to do the filtering by default\nunless the flag tells to do otherwise.\n\nThanks\n-- \nFrancis\n"},{"id":"175539","messageId":"alpine.DEB.2.00.1109122139110.12564@debian","threadId":"28315","inReplyTo":"alpine.DEB.2.00.1109090900301.12564@debian","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-15T02:19:39Z","receivedAt":"2011-09-15T02:19:39Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Fri, 9 Sep 2011, Martin von Zweigbergk wrote:\n\n> On Fri, 9 Sep 2011, Francis Moreau wrote:\n> \n> > please let me know when you submitting your work, I'm interested to see it.\n> \n> Will do. It's not really that much work [...]\n\nIt seems to be a little less straight-forward than I had first\nexpected.\n\nWe want to get all commits in $oldbase..$branch that do not share\npatch-id with commits in $oldbase..$newbase. These are the commits\nprefixed by '+' in 'git cherry $newbase $branch $oldbase'. However,\njust getting the list of commits is not enough, because we currently\ndon't explicitly provide a list of commits to create patches from, but\ninstead run something like 'git format-patch --ignore-if-in-upstream\n--stdout | git am --rebasing'.\n\nI can see a few different solutions.\n\n 1. Teach git-format-patch a --stdin option that makes it read the\n list of commits from the command line. git-format-patch currently\n itself walks the history, so I'm not sure how such an option\n should interact with current option. The options should probably\n be mutually exclusive.\n\n 2. Somehow modify git-rebase--am.sh not to depend on format-patch. In\n [1], Junio mentions rewriting git-rebase--am.sh \"to have\n format-patch avoid the cost of actually generating the patch text\"\n and \"when using \"am\" for rebasing we do not really care anything\n but the commit object names\". If all we need is the commit name,\n why would we not use cherry-pick/sequencer instead of git-am?\n Sorry if this makes no sense; I'm not familiar with the git-am\n code.\n\n 3. If I'm reading the code correctly, 'git cherry $upstream $branch\n $limit' does one walk to find patch-ids for \"$upstream\n ^$branch\". It then walks \"$branch ^$upstream ^$limit\" and removes\n the commits that have the same patch-id as a commit found in the\n first walk. Since format-patch uses the revision walking\n machinery, we could make it possible to ask git-rev-list directly\n what git-cherry does, i.e. to ask for \"commits in a..b that don't\n share patch-id with commits in c..d\". We could even make it more\n generic by allowing queries like \"commits in\n $rev_list_expression_1 that don't share patch-id with commits in\n $rev_list_expression_2\".\n\nI'm not sure which option is better. Option 1 seems easiest to\nimplement. Option 3 seems a bit harder, but may bring more value. I'm\njust not sure if teaching rev-list about patch-ids is generally useful\nor if it would feel more like a hack for this specific case. Option 2\nis less clear to me and I would probably need more input before\nimplementing, but I trust Junio that it would be a good long-term\nsolution.\n\nI will be moving soon and I don't know how much time I will have to\nimplement any of this. Still, I would be happy to hear your\nopinions. Maybe I'm just missing something and there is even a simple\nsolution to my problem.\n\n\nMartin\n\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/180976/focus=181085\n"},{"id":"175543","messageId":"7vwrdaqxpk.fsf@alter.siamese.dyndns.org","threadId":"28315","inReplyTo":"alpine.DEB.2.00.1109122139110.12564@debian","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-15T03:41:11Z","receivedAt":"2011-09-15T03:41:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin von Zweigbergk writes:\n\n> 2. Somehow modify git-rebase--am.sh not to depend on format-patch. In\n> [1], Junio mentions rewriting git-rebase--am.sh \"to have\n> format-patch avoid the cost of actually generating the patch text\"\n> and \"when using \"am\" for rebasing we do not really care anything\n> but the commit object names\". If all we need is the commit name,\n> why would we not use cherry-pick/sequencer instead of git-am?\n\nWhat I said is \"all 'am' need to use from its input while rebasing is the\ncommit object name\"; that is very different from \"we have only commit\nobject name so we must use cherry-pick\" or \"because we have commit object\nname, we can afford to use cherry-pick\".\n\nLook for $rebasing in git-am.sh and notice that:\n\n - We run get-author-ident-from-commit on $commit to keep the authorship\n information in $dotest/author-script for later use, instead of letting\n them read from $dotest/info prepared by \"mailinfo\".\n\n - My \"fixing it would be just the matter of doing this\" patch in a\n separate thread we had recently (\"mailinfo\" would obviously have\n trouble telling where the message ends whilerebasing a change with\n patch text in the commit log message) adds a similar logic to extract\n the patch text out of $commit in the same place as above, to override\n what \"mailinfo\" prepares in $dotest/patch.\n\n - Even with the above two differences from the normal \"separate the\n metainfo and patch from the mailbox, and use them\" codepath, $rebasing\n codepath uses the same \"git apply && git write-tree && git commit-tree\"\n flow.\n\nUse of \"apply && write-tree && commit-tree\" is to avoid the merge overhead\nof using cherry-pick, and historically, it used to matter a lot, because\nstarting merge-recursive was very slow (it was a Python script). Even\nthough we have merge-recursive rewritten in C these days, it probably\nstill matters, especially for large-ish projects, because merge will trash\nthe cached-tree information in the index, making write-tree inefficient.\n"},{"id":"175635","messageId":"alpine.DEB.2.00.1109151956040.12564@debian","threadId":"28315","inReplyTo":"7vwrdaqxpk.fsf@alter.siamese.dyndns.org","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-16T01:27:08Z","receivedAt":"2011-09-16T01:27:08Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"Hi,\n\nOn Wed, 14 Sep 2011, Junio C Hamano wrote:\n\n> What I said is \"all 'am' need to use from its input while rebasing is the\n> commit object name\"; that is very different from \"we have only commit\n> object name so we must use cherry-pick\" or \"because we have commit object\n> name, we can afford to use cherry-pick\".\n\nRight. I didn't mean to suggest that we should use cherry-pick.\n\n> Look for $rebasing in git-am.sh and notice that:\n\nThanks! I had no idea about these \"tricks\" in git-am.sh. Now I\nunderstand much better what you meant. So we are currently getting the\nmetainfo from the commit rather than from the mailbox. With your\npatch, we would also get the patch body from the commit. The only\nthing remaining after that is the commit log message, correct?\n\nOnce all that git-am reads from the mailbox while in $rebasing mode is\nthe commit name, it would be as small change to teach it to read a\nlist of commit names instead. Is this what you meant or did you really\nmean for format-patch to generate output without patch body? At this\npoint the name 'am' becomes quite misleading, but maybe that's not\nworth worrying about.\n\n\nThanks,\nMartin\n"},{"id":"175896","messageId":"alpine.DEB.2.00.1109201254020.12564@debian","threadId":"28315","inReplyTo":"alpine.DEB.2.00.1109151956040.12564@debian","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-20T20:45:40Z","receivedAt":"2011-09-20T20:45:40Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, 15 Sep 2011, Martin von Zweigbergk wrote:\n\n[CC'ing Ramkunar regarding the footnote]\n\n> [...] With your\n> patch, we would also get the patch body from the commit. The only\n> thing remaining after that is the commit log message, correct?\n\nIt turns out the commit log message have been taken from the commit\nfor ages. Sorry about not checking the code first.\n\nI have started implementing the changes to git-am.sh now. I have made\nit not use mailinfo when in $rebasing mode, as you suggested. So now\ngit-am works even if only a list of\n\n From $sha1 Mon Sep 17 00:00:00 2001\n\nlines are fed to it. Since only the $sha1 is needed, we should\nprobably make --rebasing imply a patch-format is just a simple list of\nrevisions. Since the --rebasing flag is only for internal use, this\nshould be safe when it comes to backwards compatibility. [1]\n\nNow the question is how to generate such lines, without the overhead\nof a full format-patch call. We still want the --ignore-if-in-upstream\nfunctionality, so we can not use plain rev-list. We also want it to\nwork with --root, so we can not use git-cherry. Finally, we can not\nuse 'git rev-list --cherry-pick --right-only' since it seems to be\ninherently for symmetric ranges and therefore does not support\ngit-cherry's parameter.\n\nIf I'm not mistaken, we would have to teach some new option to some\ncommand, but which one?\n\nIt doesn't feel right to teach format-patch a --commit-name-only,\nsimply because it would then no longer be a patch.\n\nIt's probably easiest to teach git-cherry a --root flag. Does that\nsound like the right solution to people? I think it makes sense for\nsuch an option to exist.\n\nMore involved would be to teach rev-list --cherry-pick also for\nasymmetric ranges. I would imagine that \"--cherry-pick $branch --not\n$newbase $oldbase\" could be defined as \"all commits in $branch that\nare not patch-equivalent to any commits in $newbase or $oldbase\". Just\ns/patch-equivalent/identical/ and you have the regular definition of\nthe rev-list, right? There is of course no need to actually calculate\nthe patch-id for any commits are not in \"$branch --not $newbase\n$oldbase\" (identical => patch-equivalent).\n\nI would go for teaching git-cherry --root, unless the \"rev-list\n--cherry-pick for asymmetric ranges\" option would be useful\nelsewhere. Either way, teaching git-cherry --root would not be a bad\nthing, I think.\n\n\nMartin\n\n\n [1] Long term, would it make sense to teach 'git cherry-pick' a '-2'\n option instead of using the '-3' option to 'git am'? (Where 'git\n cherry-pick -2' would try \"apply && write-tree && commit-tree\"\n before falling back to merging.)\n"},{"id":"176121","messageId":"CALkWK0mggSNoxxqzUaGp1-AxGWSpCb0HnRmBxSkcVrHnhwMr1Q@mail.gmail.com","threadId":"28315","inReplyTo":"alpine.DEB.2.00.1109201254020.12564@debian","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-09-24T09:12:15Z","receivedAt":"2011-09-24T09:12:15Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Martin,\n\nMartin von Zweigbergk writes:\n> I have started implementing the changes to git-am.sh now. I have made\n> it not use mailinfo when in $rebasing mode, as you suggested. So now\n> git-am works even if only a list of\n>\n>  From $sha1 Mon Sep 17 00:00:00 2001\n\nAh, nice :)\n\n> Now the question is how to generate such lines, without the overhead\n> of a full format-patch call. We still want the --ignore-if-in-upstream\n> functionality, so we can not use plain rev-list. We also want it to\n> work with --root, so we can not use git-cherry. Finally, we can not\n> use 'git rev-list --cherry-pick --right-only' since it seems to be\n> inherently for symmetric ranges and therefore does not support\n> git-cherry's parameter.\n\nUsing git-format-patch for anything except emailing patches to the\nmaintainer/ list is a mistake imo.\n\n> I would go for teaching git-cherry --root, unless the \"rev-list\n> --cherry-pick for asymmetric ranges\" option would be useful\n> elsewhere. Either way, teaching git-cherry --root would not be a bad\n> thing, I think.\n\nEither this, or we have to write another wrapper around git-patch-id.\n\n>  [1] Long term, would it make sense to teach 'git cherry-pick' a '-2'\n>     option instead of using the '-3' option to 'git am'? (Where 'git\n>     cherry-pick -2' would try \"apply && write-tree && commit-tree\"\n>     before falling back to merging.)\n\nYeah, in the wake of scripts already doing \"apply && write-tree &&\ncommit-tree\" by hand, I think this proposal for git-cherry-pick makes\na lot of sense. I'm not sure if the option should be called '-2'\nthough.\n\nThanks.\n\n-- Ram\n"},{"id":"176151","messageId":"alpine.DEB.2.00.1109242148570.24369@debian","threadId":"28315","inReplyTo":"CALkWK0mggSNoxxqzUaGp1-AxGWSpCb0HnRmBxSkcVrHnhwMr1Q@mail.gmail.com","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-25T03:25:58Z","receivedAt":"2011-09-25T03:25:58Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"Hi Ram and Thomas,\n\nOn Sat, 24 Sep 2011, Ramkumar Ramachandra wrote:\n\n> Martin von Zweigbergk writes:\n> > [...] We also want it to\n> > work with --root, so we can not use git-cherry.\n\nI think I was confused here; git-cherry should work just fine. Simply\nleaving out the limit, or setting it to $onto, makes the walk go all\nthe way to the roots. After thinking a bit more about this, I'm\ninstead wondering what the purpose of the --root flag to git-rebase\nis. Thomas introduced it in 190f532 (rebase: learn to rebase root\ncommit, 2009-01-05).\n\nIf I understand correctly, it was introduced to solve exactly the same\nreason problem that made Francis start this thread -- to avoid\nre-applying patches that are already in $onto. In Thomas's patch,\ngit-rebase started passing $onto..$orig_head instead of\n$upstream..$orig_head to git-format-patch. It also started passing\n--root to git-format-patch, but that was made unneccessary a few days\nlater in 68c2ec7 (format-patch: show patch text for the root commit,\n2009-01-10).\n\nAfter my patches (that are not yet ready) that calculate revisions as\n\"git cherry $onto $orig_head $upstream\", I don't think there should be\nany need for the --root flag. The only place the flag is checked now\n(in my current work tree, that is) is when deciding how to interpret\nthe remaining arguments. Although I have not tried (temporarily)\nrewriting all the test cases from\n\n git rebase --root --onto upstream branch\n\nto\n\n git rebase upstream branch\n\n, I think it should work. What do you think, Thomas? I saw that\n\"--root\" is also passed to the hook. Should that value be passed to\nthe hook also when the old base is not explicitly a root (by \"rebase\n--root\"), but only implicitly so (by an $onto that is disjoint from\n$branch)?\n\nMartin\n"},{"id":"176192","messageId":"201109261110.59940.trast@student.ethz.ch","threadId":"28315","inReplyTo":"alpine.DEB.2.00.1109242148570.24369@debian","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-09-26T09:10:59Z","receivedAt":"2011-09-26T09:10:59Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Martin von Zweigbergk wrote:\n> \n> If I understand correctly, [rebase --root] was introduced to solve\n> exactly the same reason problem that made Francis start this thread\n> -- to avoid re-applying patches that are already in $onto.\n\nNot quite; I wrote it because at the time, there was no way to\ntransplant git history onto a git-svn \"make empty subdir\" commit for\nlater dcommitting. So the main point was really\n\n> After my patches (that are not yet ready) that calculate revisions as\n> \"git cherry $onto $orig_head $upstream\", I don't think there should be\n> any need for the --root flag. The only place the flag is checked now\n> (in my current work tree, that is) is when deciding how to interpret\n> the remaining arguments. Although I have not tried (temporarily)\n> rewriting all the test cases from\n> \n> git rebase --root --onto upstream branch\n> \n> to\n> \n> git rebase upstream branch\n> \n> , I think it should work. What do you think, Thomas?\n\nI still think it would be natural for a user to want a way to say \"all\nthe way back to the root commit\". At least for me the \"full\" rebase\ninvocation is\n\n git rebase --onto onto base branch\n\nIn that mindset it comes natural to replace 'base' with --root if you\nwant to go all the way.\n\nMaybe I don't trust rebase enough to do what I want ;-)\n\n> I saw that\n> \"--root\" is also passed to the hook. Should that value be passed to\n> the hook also when the old base is not explicitly a root (by \"rebase\n> --root\"), but only implicitly so (by an $onto that is disjoint from\n> $branch)?\n\nI think I did it that way because if you use --root, the base/upstream\nargument is missing, and the hook needs to know that.\n\nIf the user specifies an upstream that is disjoint from the branch\nitself, the hook gets the upstream argument and can presumably work it\nout from there. So you could perhaps save the hook some trouble if\nyou *know* that it's a disjoint rebase, but I wouldn't spend too much\ntime on that.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"176420","messageId":"CAOeW2eFyTewS2+QK7UW_yOWpVKtCkwSBH0PjPutn0BYYqgV1HQ@mail.gmail.com","threadId":"28315","inReplyTo":"201109261110.59940.trast@student.ethz.ch","subject":"Re: git-rebase skips automatically no more needed commits","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-09-28T14:49:05Z","receivedAt":"2011-09-28T14:49:05Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Mon, Sep 26, 2011 at 5:10 AM, Thomas Rast wrote:\n> Martin von Zweigbergk wrote:\n>>\n>> If I understand correctly, [rebase --root] was introduced to solve\n>> exactly the same reason problem that made Francis start this thread\n>> -- to avoid re-applying patches that are already in $onto.\n>\n> Not quite; I wrote it because at the time, there was no way to\n> transplant git history onto a git-svn \"make empty subdir\" commit for\n> later dcommitting.  So the main point was really\n\nBut that was only due to the bug/limitation in format-patch that you\n(?) fixed a few days later, no?\n\n> I still think it would be natural for a user to want a way to say \"all\n> the way back to the root commit\".  At least for me the \"full\" rebase\n> invocation is\n>\n>  git rebase --onto onto base branch\n\nSure, I can understand that. Still, it would just be an alternative\nsyntax and nothing else. So I think I should also update the\ndocumentation after my other patches to make it clear that that is the\ncase. We also have to think about backwards compatibility, so I'm\nobviously not suggesting that we should stop supporting the flag; I\njust wanted to make sure that it is not technically needed.\n\n>> I saw that\n>> \"--root\" is also passed to the hook. Should that value be passed to\n>> the hook also when the old base is not explicitly a root (by \"rebase\n>> --root\"), but only implicitly so (by an $onto that is disjoint from\n>> $branch)?\n>\n> I think I did it that way because if you use --root, the base/upstream\n> argument is missing, and the hook needs to know that.\n>\n> If the user specifies an upstream that is disjoint from the branch\n> itself, the hook gets the upstream argument and can presumably work it\n> out from there.  So you could perhaps save the hook some trouble if\n> you *know* that it's a disjoint rebase, but I wouldn't spend too much\n> time on that.\n\nThe hook would still have to be able to handle both cases (i.e.\ngetting the upstream argument as \"--root\" or simply a commit that\nhappens to be disjoint from the the branch-to-be-rebased). I believe\nthat has been the case since that bug in format-patch was fixed. So if\nwe were to change git-rebase so it no longer passes the --root flag to\nthe hook, I think any (correctly written) hooks should still work. I\ndon't see much reason to change it, though; if the user uses the\n--root syntax, we can pass the flag, otherwise we don't.\n\nMartin\n"}]}