> I agree with Avi on what the rebase -i -p behavior should be for his > scenario. This patch makes it so. However, the bane of my existence, > t3404 is failing ~12 tests in, which is a real PITA to debug, so > please let me know if this is a worthwhile tangent to continue on. Ah, good old t3404--it caught me on an aspect I had considered but wanted to avoid--Avi's (and my) preferred "--first-parent" way of listing merges works great if the right hand side of the merge commits are outside of the branch getting rebased. E.g. my use case is when I merge in a stable release with ~100 commits or so and could potentially want to move it around, perhaps squash around it as Avi pointed it, I don't want all 100 commits that are in the stable branch to be listed in my todo file. However, t3404 makes a good point that if the right hand of the merge has parents that are going to get rebased, the right hand side does need to be included/shown/rewritten. I also went and looked at the git-sequencer rewrite of rebase-i and it looks slick. I don't fully understand it yet, but I'm much more inclined now to just let Stephan (& sponors/list) ably handle the problem. Especially since its moving to builtin, it moves the required technical ability to contribute above my current skillset--perhaps that is the intent. :-) So, unless I think of something else, I'm done hacking on this and am withdrawing the patch. Though I am curious--with the sequencer, is the Avi/my request of not listing out-of-band commits in the todo file going to be handled? Some sort of "--first-parent-unless-included-in-rebase" flag. Thanks, Stephen -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
