{"thread":{"id":"35955","subject":"GSoC idea: allow \"git rebase --interactive\" todo lines to take options","startedAt":"2014-02-26T08:04:30Z","lastAt":"2014-03-11T19:31:00Z","messageCount":12,"participants":["Michael Haggerty","Jeff King","Tay Ray Chuan","Junio C Hamano","Brandon McCaig"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"235353","messageId":"530DA00E.4090402@alum.mit.edu","threadId":"35955","inReplyTo":null,"subject":"GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-26T08:04:30Z","receivedAt":"2014-02-26T08:04:30Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"I just submitted the idea below as a pull request [1] to the GSoC ideas\npage, but I'd like to get some mailing list feedback first that the idea\nis sensible...\n\nAnd, is there anybody else willing to volunteer as a mentor for this\nproject? (There should be at least two.)\n\nMichael\n\n[1] https://github.com/git/git.github.io/pull/5\n\n\n## Line options for `git rebase --interactive`\n\nOne of the more powerful features in Git is the command `git rebase\n--interactive`, which allows recent commits to be reordered, squashed\ntogether, or even revised completely. The command creates a todo list\nand opens it in an editor. The original todo list might look like:\n\n pick deadbee Implement feature XXX\n pick c0ffeee The oneline of the next commit\n pick 01a01a0 This change is questionable\n pick f1a5c00 Fix to feature XXX\n pick deadbab The oneline of the commit after\n\nThe user can edit the list to make changes to the history, for example\nto\n\n pick deadbee Implement feature XXX\n squash f1a5c00 Fix to feature XXX\n exec make\n edit c0ffeee The oneline of the next commit\n pick deadbab The oneline of the commit after\n\nThis would cause commits `deadbee` and `f1a5c00` to be squashed\ntogether into one commit followed by running `make` to test-compile\nthe results, delete commit `01a01a0` altogether, and stop after\ncommitting commit `c0ffeee` to allow the user to make changes.\n\nIt would be nice to support more flexibility in the todo-list commands\nby allowing the commands to take options. Maybe\n\n* Convert a commit into a merge commit:\n\n pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after\n\n* After squashing two commits, add a \"Signed-off-by\" line to the\n commit log message:\n\n pick deadbee Implement feature XXX\n squash --signoff f1a5c00 Fix to feature XXX\n\n or GPG-sign a commit:\n\n pick --gpg-sign= deadbee Implement feature XXX\n\n* Reset the author of the commit to the current user or a specified\n user:\n\n pick --reset-author deadbee Implement feature XXX\n pick --author=\"A U Thor \" deadbab The oneline of\nthe commit after\n\nThe goal of this project would be (1) to add the infrastructure for\nhandling options on todo-list lines, and (2) implement some concrete\noptions. A big part of the difficulty of this project is that `git\nrebase --interactive` is implemented via a sparsely-commented shell\nscript. Adding comments and cleaning up the script as you go would be\nvery welcome.\n\n - Language: sh\n - Difficulty: medium\n - Possible mentors: Michael Haggerty\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235365","messageId":"20140226105249.GE25711@sigill.intra.peff.net","threadId":"35955","inReplyTo":"530DA00E.4090402@alum.mit.edu","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-26T10:52:49Z","receivedAt":"2014-02-26T10:52:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote:\n\n> It would be nice to support more flexibility in the todo-list commands\n> by allowing the commands to take options. Maybe\n> \n> * Convert a commit into a merge commit:\n> \n> pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after\n\nThis seems like a reasonable feature to me. All of your examples are\npossible with an \"e\"dit and another git command, but the convenience may\nbe worth it (though personally, most of the examples you gave are\nparticularly interesting to me[1]).\n\nI'd worry a little that it is not a summer's worth of work, but I\nsuspect there are other parts of rebase--interactive that could use\nattention once the student is familiar with the code.\n\n> * After squashing two commits, add a \"Signed-off-by\" line to the\n> commit log message:\n> \n> pick deadbee Implement feature XXX\n> squash --signoff f1a5c00 Fix to feature XXX\n> \n> or GPG-sign a commit:\n> \n> pick --gpg-sign= deadbee Implement feature XXX\n> \n> * Reset the author of the commit to the current user or a specified\n> user:\n> \n> pick --reset-author deadbee Implement feature XXX\n> pick --author=\"A U Thor \" deadbab The oneline of\n> the commit after\n\nYour first example would need some commit-tree magic, I think. But could\nyou implement these two with:\n\n pick deadbee Implement feature XXX\n exec git commit --amend --signoff --reset-author\n\n? You could even alias the \"amend\" command to \"exec git commit --amend\",\nlike:\n\n amend --signoff --reset-author\n\nMaybe that is unnecessarily unfriendly to the user, though.\n\n-Peff\n\n[1] The one feature I would like in this vein is that editing the title\n in the instruction-sheet would modify the commit message of the\n relevant commit. For some reason I try to do this every few weeks,\n but of course the changes are just thrown away.\n"},{"id":"235372","messageId":"530DCC83.1060805@alum.mit.edu","threadId":"35955","inReplyTo":"20140226105249.GE25711@sigill.intra.peff.net","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-26T11:14:11Z","receivedAt":"2014-02-26T11:14:11Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/26/2014 11:52 AM, Jeff King wrote:\n> On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote:\n> \n>> It would be nice to support more flexibility in the todo-list commands\n>> by allowing the commands to take options. Maybe\n>>\n>> * Convert a commit into a merge commit:\n>>\n>> pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after\n> \n> This seems like a reasonable feature to me. All of your examples are\n> possible with an \"e\"dit and another git command, but the convenience may\n> be worth it (though personally, most of the examples you gave are\n> particularly interesting to me[1]).\n> \n> I'd worry a little that it is not a summer's worth of work, but I\n> suspect there are other parts of rebase--interactive that could use\n> attention once the student is familiar with the code.\n> \n>> * After squashing two commits, add a \"Signed-off-by\" line to the\n>> commit log message:\n>>\n>> pick deadbee Implement feature XXX\n>> squash --signoff f1a5c00 Fix to feature XXX\n>>\n>> or GPG-sign a commit:\n>>\n>> pick --gpg-sign= deadbee Implement feature XXX\n>>\n>> * Reset the author of the commit to the current user or a specified\n>> user:\n>>\n>> pick --reset-author deadbee Implement feature XXX\n>> pick --author=\"A U Thor \" deadbab The oneline of\n>> the commit after\n> \n> Your first example would need some commit-tree magic, I think. But could\n> you implement these two with:\n> \n> pick deadbee Implement feature XXX\n> exec git commit --amend --signoff --reset-author\n> \n> ? You could even alias the \"amend\" command to \"exec git commit --amend\",\n> like:\n> \n> amend --signoff --reset-author\n> \n> Maybe that is unnecessarily unfriendly to the user, though.\n\nThe whole point is to make these things easy. But I have to admit that\n\"amend\" would be another nice todo-list command. Once the\ninfrastructure is there to handle options, it would be no big deal to\nadd an \"amend\" command with a \"--signoff\" option and offer the same\n\"--signoff\" option on other, existing commands.\n\n> [1] The one feature I would like in this vein is that editing the title\n> in the instruction-sheet would modify the commit message of the\n> relevant commit. For some reason I try to do this every few weeks,\n> but of course the changes are just thrown away.\n\nGiven that commit messages can be more than one line long, a feature\nlike this would be confusing, I think, and perhaps subtly encourage\npeople to limit their commit messages to a single line, which would be a\nbad thing. Plus, until now such edits were thrown away, so there are\nbackwards compatibility problems if we suddenly start preserving such edits.\n\nBut using the other ideas discussed here one could do\n\n pick -m \"New log message\" \n\nor\n\n amend -m \"Revised log message\"\n\nIt also might be reasonable, if the user edits the title in a way that\ndoes not simply delete characters at the end, to do an implicit \"reword\"\nwith the edited title stuck in at the first line (and maybe the original\ntitle following it, commented out with \"#\").\n\nAnother, more wonkish idea I though of would be\n\n pick --tree= \n\nto force the tree of the commit to be set to that of the specified\n while keeping the commit metadata from . What would\nthis be useful for? When swapping two commits, it is often the case\nthat conflicts have to be resolved twice. But the tree should be the\nsame after both commits are applied, regardless of the order in which\nthey are applied. So one could change\n\n pick aaaaaaa\n pick bbbbbbb\n\nto\n\n pick bbbbbbb\n pick --tree=bbbbbbb aaaaaaa\n\nOn the other hand, maybe \"git rebase --interactive\" should have the\nintelligence to do this automatically whenever the set of commits\npre/post rewriting is identical, possibly if a \"--reorder-only\" option\nis used.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235380","messageId":"20140226114200.GA3779@sigill.intra.peff.net","threadId":"35955","inReplyTo":"530DCC83.1060805@alum.mit.edu","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-26T11:42:01Z","receivedAt":"2014-02-26T11:42:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 26, 2014 at 12:14:11PM +0100, Michael Haggerty wrote:\n\n> > [1] The one feature I would like in this vein is that editing the title\n> > in the instruction-sheet would modify the commit message of the\n> > relevant commit. For some reason I try to do this every few weeks,\n> > but of course the changes are just thrown away.\n> \n> Given that commit messages can be more than one line long, a feature\n> like this would be confusing, I think, and perhaps subtly encourage\n> people to limit their commit messages to a single line, which would be a\n> bad thing.\n\nRight, I was assuming it would just modify the subject-line, and leave\nthe rest intact (I often want to use it to just replace one word or fix\na typo, since I am starting right at it in the insn sheet).\n\n> Plus, until now such edits were thrown away, so there are\n> backwards compatibility problems if we suddenly start preserving such edits.\n\nGood point. For true interactive use it probably wouldn't be that big a\ndeal, but people do weird things with GIT_EDITOR and auto-munging the\nlist of commits. A heuristic like \"is there any message there at all\"\nmight work, as you mentioned, but heuristics make me nervous.\n\n> But using the other ideas discussed here one could do\n> \n> pick -m \"New log message\" \n\nYeah, that would work, though you have to retype the whole thing, which\nis potentially annoying (clever use of your editor can pull it over from\nthe other side, but it's not super-friendly).\n\nSomething like:\n\n pick --subject \n\nwould be simpler.\n\n> amend -m \"Revised log message\"\n\nThat would replace the whole message, which I definitely don't want (and\nwould encourage bad habits).\n\n> Another, more wonkish idea I though of would be\n> \n> pick --tree= \n> \n> to force the tree of the commit to be set to that of the specified\n> while keeping the commit metadata from .\n\nI think there's a large foot-shooting capacity there. Any commit you've\nreordered from after the \"--tree\" to before it will mysteriously get\nundone in the \"--tree\" commit. E.g.:\n\n pick aaaaaaa\n pick bbbbbbb\n pick ccccccc\n\nbeing done as:\n\n pick ccccccc\n pick bbbbbbb\n pick --tree=bbbbbbb aaaaaaa\n\n-Peff\n"},{"id":"235382","messageId":"CALUzUxqr5ycLRshn9=w_RR3umUd27gCg67qunXC1d9djqKdm2w@mail.gmail.com","threadId":"35955","inReplyTo":"20140226105249.GE25711@sigill.intra.peff.net","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2014-02-26T14:55:14Z","receivedAt":"2014-02-26T14:55:14Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"On Wed, Feb 26, 2014 at 6:52 PM, Jeff King wrote:\n> I'd worry a little that it is not a summer's worth of work, but I\n> suspect there are other parts of rebase--interactive that could use\n> attention once the student is familiar with the code.\n\nIt might be worthwhile to check for prior projects that were a \"bag\"\nof small projects that were accepted into GSoC. I don't have the time\nto do this right now, I'll get to it at a later time.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"235404","messageId":"xmqq4n3l4pjr.fsf@gitster.dls.corp.google.com","threadId":"35955","inReplyTo":"20140226105249.GE25711@sigill.intra.peff.net","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-26T19:55:20Z","receivedAt":"2014-02-26T19:55:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote:\n>\n>> It would be nice to support more flexibility in the todo-list commands\n>> by allowing the commands to take options. Maybe\n>> \n>> * Convert a commit into a merge commit:\n>> \n>> pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after\n>\n> This seems like a reasonable feature to me. All of your examples are\n> possible with an \"e\"dit and another git command, but the convenience may\n> be worth it (though personally, most of the examples you gave are\n> particularly interesting to me[1]).\n\nI actually had a completely opposite reaction to the above one. It\ntook considerable mental effort to decipher what that \"pick -p ...\"\nline was trying to do, and I am not absolutely sure if I understand\nwhat it is trying to do enough to rewrite it to an equivalent\n\"inconvenient\" sequence of \"edit and another git command\".\n\n> [1] The one feature I would like in this vein is that editing the title\n> in the instruction-sheet would modify the commit message of the\n> relevant commit. For some reason I try to do this every few weeks,\n> but of course the changes are just thrown away.\n\nEvery time I thought about this one, I get stopped after realizing\nthat the title line is only a small part of the log message.\n"},{"id":"235442","messageId":"530EEDBA.6090804@alum.mit.edu","threadId":"35955","inReplyTo":"20140226105249.GE25711@sigill.intra.peff.net","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-27T07:48:10Z","receivedAt":"2014-02-27T07:48:10Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/26/2014 11:52 AM, Jeff King wrote:\n> On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote:\n> \n>> It would be nice to support more flexibility in the todo-list commands\n>> by allowing the commands to take options. Maybe\n>>\n>> * Convert a commit into a merge commit:\n>>\n>> pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after\n> \n> This seems like a reasonable feature to me. All of your examples are\n> possible with an \"e\"dit and another git command, but the convenience may\n> be worth it (though personally, most of the examples you gave are\n> particularly interesting to me[1]).\n\nDon't forget that any of the parent commits might have been rewritten\ndue to the earlier lines of the rebase script. Rebase has to map the\nspecified SHA-1s to their new versions. So I don't think that this one\nwould be very practical to implement by hand.\n\nActually I think it is awkward to have to specify all of the parent\ncommits. I did it this way to make it look like commit-tree's -p\noption. But any usage of this feature that *doesn't* include the\nimmediately preceding commit as a parent would probably be broken anyway\n(for example, the preceding commit would become unreachable).\n\nSo maybe a better UI would be\n\n pick --merge=e1ee712 deadbab The oneline of the commit after\n\n(even though this precludes the short form \"-m\" because it is already\ntaken by --message).\n\nOn the other hand, allowing arbitrary parents with \"-p\" might be a way\nto make \"rebase --interactive\" work half-sanely with parts of history\nthat *already* include merge commits. The todo list that rebase\nprepares for the user would already include these \"-p\" lines.\n\nWhat I like about allowing options in todo lists is that is that it\nopens up a lot of possibilities for \"git rebase --interactive\" that, I\nthink, have previously been hampered by the restriction that commands\nhave to consist of a single word, and (until now) have to be abbreviable\nto a single distinct letter.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235487","messageId":"CANUGeEY2qE2LPq=-bhaKrKrv+uJUaPRqAeW_X1sFyZH-_PRVeA@mail.gmail.com","threadId":"35955","inReplyTo":"20140226105249.GE25711@sigill.intra.peff.net","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Brandon McCaig","fromEmail":"bamccaig@gmail.com","sentAt":"2014-02-27T18:10:30Z","receivedAt":"2014-02-27T18:10:30Z","isPatch":false,"sender":{"key":"bamccaig@gmail.com","avatar":"https://gravatar.com/avatar/05b01f2b62a5ddbaa1946579266a8d9e970fed0c0b3c20e8d42aca973c31531c?d=mp&s=160"},"body":"On Wed, Feb 26, 2014 at 5:52 AM, Jeff King wrote:\n> This seems like a reasonable feature to me. All of your examples are\n> possible with an \"e\"dit and another git command, but the convenience may\n> be worth it (though personally, most of the examples you gave are\n> particularly interesting to me[1]).\n\nThis strikes me as over-complicating the rebase --interactive\ninterface. Particularly all of the ideas expressed later on about\nmerge commits and resetting authors, etc. It seems like you're trying\nto define a whole new command set (i.e., API) for Git, but within the\ncontext of rebase --interactive. I think it would be hard to document\nthis, and hard to learn it, and harder still to remember it (even\nthough it would obviously try to mirror the existing Git command API).\nI honestly didn't know (or forgot) about the e\"x\"ec command, but that\nto me says that I can automate whatever I want without needing to make\nany changes to the rebase --interactive interface. The advantage to\nthis is that we don't need to reinvent the square wheel that is the\nGit command API. We can just exec git ... with the exact same command\nset and options that we're already familiar with. No doubts about\nsyntax or disparities, etc.\n\nI don't think it's my place to resist these changes; particularly\nbecause I don't think they'd necessarily affect me, except for maybe\nthe proposed automatic merge support, but if that SOMEHOW actually\nworks reliably and sensibly (i.e., to allow you to rebase over merges\nwithout losing the merges) I'm not sure I'd complain. That said, I do\nthink that this is probably a bad direction and shouldn't be rushed\ninto too fast. It seems like it would be a complicated thing to do,\nmore complicated to do well, and I'm not sure that it would really\nimprove things any. I'm not sure that users would prefer to use this\nover \"e\"diting and/or e\"x\"ecing instead. Plus where do you draw the\nline as far as which features to reproduce? How do you prevent scope\ncreep?\n\n> [1] The one feature I would like in this vein is that editing the title\n> in the instruction-sheet would modify the commit message of the\n> relevant commit. For some reason I try to do this every few weeks,\n> but of course the changes are just thrown away.\n\nWhen I do this I am usually half asleep and it's a good reminder to\npay attention to what I'm doing. I'd probably rather Git *error* when\nI change the subject line and tell me why it doesn't make sense and\nrecommend \"r\"eword instead.\n\nRegards,\n\n\n-- \nBrandon McCaig \nCastopulence Software \nBlog \nperl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.\nq{Vg qbrfa'\\''g nyjnlf fbhaq gung jnl.};\ntr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'\n"},{"id":"235604","messageId":"20140228125241.GA23448@sigill.intra.peff.net","threadId":"35955","inReplyTo":"CANUGeEY2qE2LPq=-bhaKrKrv+uJUaPRqAeW_X1sFyZH-_PRVeA@mail.gmail.com","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-28T12:52:41Z","receivedAt":"2014-02-28T12:52:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:\n\n> On Wed, Feb 26, 2014 at 5:52 AM, Jeff King wrote:\n> > This seems like a reasonable feature to me. All of your examples are\n> > possible with an \"e\"dit and another git command, but the convenience may\n> > be worth it (though personally, most of the examples you gave are\n> > particularly interesting to me[1]).\n> \n> This strikes me as over-complicating the rebase --interactive\n> interface.\n\nSorry, I missed an important word in my final sentence. It should have\nbeen \"the examples you gave are NOT particularly interesting to me\".\n\n> Particularly all of the ideas expressed later on about\n> merge commits and resetting authors, etc. It seems like you're trying\n> to define a whole new command set (i.e., API) for Git, but within the\n> context of rebase --interactive. I think it would be hard to document\n> this, and hard to learn it, and harder still to remember it (even\n> though it would obviously try to mirror the existing Git command API).\n\nI agree some of the examples are getting esoteric. Things like --signoff\nand --reset-author are a fairly straightforward convenience feature:\nthey save you from writing \"exec git commit --amend --signoff\".\n\nFor others that cannot currently be done with a simple option to \"git\ncommit\", I think a reasonable first step would be to implement them\nthere. For example, you cannot currently \"git commit --tree\". Maybe that\nis too insane and low-level an option for \"git commit\". But if it is,\nthen it is almost certainly too insane and low-level for a rebase\ninstruction.\n\nFor others from Michael's list, I expect they may not make _sense_\noutside of a rebase. That is, they are operations whose input is not a\nsingle commit, but a sequence of commits (e.g., if you had some\nhigh-level command that allowed swapping two commits without having to\nredo the conflicts from the second commit). Those ones might make sense\nto exist as part of rebase and nowhere else (but then they are not\nnecessarily just options, but rather new instructions).\n\n> That said, I do think that this is probably a bad direction and\n> shouldn't be rushed into too fast.\n\nI'm not sure whether it is a good idea or not. But I think it is looking\ndecreasingly like a good GSoC project.\n\n-Peff\n"},{"id":"235610","messageId":"53109748.3090507@alum.mit.edu","threadId":"35955","inReplyTo":"20140228125241.GA23448@sigill.intra.peff.net","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-28T14:03:52Z","receivedAt":"2014-02-28T14:03:52Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/28/2014 01:52 PM, Jeff King wrote:\n> [...]\n> Sorry, I missed an important word in my final sentence. It should have\n> been \"the examples you gave are NOT particularly interesting to me\".\n> \n> On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:\n>> Particularly all of the ideas expressed later on about\n>> merge commits and resetting authors, etc. It seems like you're trying\n>> to define a whole new command set (i.e., API) for Git, but within the\n>> context of rebase --interactive. I think it would be hard to document\n>> this, and hard to learn it, and harder still to remember it (even\n>> though it would obviously try to mirror the existing Git command API).\n> \n> I agree some of the examples are getting esoteric. Things like --signoff\n> and --reset-author are a fairly straightforward convenience feature:\n> they save you from writing \"exec git commit --amend --signoff\".\n> \n> For others that cannot currently be done with a simple option to \"git\n> commit\", I think a reasonable first step would be to implement them\n> there. For example, you cannot currently \"git commit --tree\". Maybe that\n> is too insane and low-level an option for \"git commit\". But if it is,\n> then it is almost certainly too insane and low-level for a rebase\n> instruction.\n> \n> For others from Michael's list, I expect they may not make _sense_\n> outside of a rebase. That is, they are operations whose input is not a\n> single commit, but a sequence of commits (e.g., if you had some\n> high-level command that allowed swapping two commits without having to\n> redo the conflicts from the second commit). Those ones might make sense\n> to exist as part of rebase and nowhere else (but then they are not\n> necessarily just options, but rather new instructions).\n> \n>> That said, I do think that this is probably a bad direction and\n>> shouldn't be rushed into too fast.\n> \n> I'm not sure whether it is a good idea or not. But I think it is looking\n> decreasingly like a good GSoC project.\n\nI guess I misread the sentiment of the mailing list, because I merged\nthis idea into the list about two hours ago.\n\nI'm not claiming that all of the sub-ideas are good, but I do think that\nsome of them are, and that the general idea of allowing options on\ntodo-list commands would make it possible for them to be more expressive\nwhile *avoiding* making them a lot harder to learn. I would rather give\nthe user a few options that can be used consistently on multiple\ncommands than have to invent a new command for each new feature. And I\nthink that the line-oriented nature of the todo list makes\n\n pick --signoff 1234abc Blah blah\n\neasier to understand (and easier to type) than\n\n pick 1234abc Blah blah\n amend --signoff\n\nlet alone\n\n pick 1234abc Blah blah\n exec git commit --amend --signoff\n\nI also like the idea of a non-broken \"git rebase --interactive\n--preserve-merges\" via a todo option \"-p\" or something similar.\n\nBut if you think that even the proposal's simpler sub-ideas are\ncontroversial, then let me know and I will delete the idea from the list\nagain. I don't want a GSoC student to have to fight battles of my own\ncreation :-)\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"236475","messageId":"20140311013749.GA12033@sigill.intra.peff.net","threadId":"35955","inReplyTo":"53109748.3090507@alum.mit.edu","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-11T01:37:49Z","receivedAt":"2014-03-11T01:37:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 28, 2014 at 03:03:52PM +0100, Michael Haggerty wrote:\n\n> > I'm not sure whether it is a good idea or not. But I think it is looking\n> > decreasingly like a good GSoC project.\n> \n> I guess I misread the sentiment of the mailing list, because I merged\n> this idea into the list about two hours ago.\n\nYeesh, sorry to be so slow on the reply to this. It floated to the\nbottom of my \"to respond\" list.\n\n> But if you think that even the proposal's simpler sub-ideas are\n> controversial, then let me know and I will delete the idea from the list\n> again. I don't want a GSoC student to have to fight battles of my own\n> creation :-)\n\nI'd say keep it at this point. I think there _are_ some good ideas here,\nand part of a project is figuring out what is good. And part of the role\nof the mentor is applying some taste. There are probably students who\nwould be a good fit, and students who would not. That is true for just\nabout every project, of course, but I think this one is just a little\ntrickier than some.\n\n-Peff\n"},{"id":"236521","messageId":"xmqqy50gpm6j.fsf@gitster.dls.corp.google.com","threadId":"35955","inReplyTo":"20140311013749.GA12033@sigill.intra.peff.net","subject":"Re: GSoC idea: allow \"git rebase --interactive\" todo lines to take options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-11T19:31:00Z","receivedAt":"2014-03-11T19:31:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I'd say keep it at this point. I think there _are_ some good ideas here,\n> and part of a project is figuring out what is good. And part of the role\n> of the mentor is applying some taste.\n\nAmen to that. I hope we have enough mentor-candidates with good\ntaste, though ;-)\n\n> There are probably students who would be a good fit, and students\n> who would not. That is true for just about every project, of\n> course, but I think this one is just a little trickier than some.\n\nPerhaps.\n"}]}