On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote: > On Wed, Feb 26, 2014 at 5:52 AM, Jeff King <peff@xxxxxxxx> wrote: > > This seems like a reasonable feature to me. All of your examples are > > possible with an "e"dit and another git command, but the convenience may > > be worth it (though personally, most of the examples you gave are > > particularly interesting to me[1]). > > This strikes me as over-complicating the rebase --interactive > interface. Sorry, I missed an important word in my final sentence. It should have been "the examples you gave are NOT particularly interesting to me". > Particularly all of the ideas expressed later on about > merge commits and resetting authors, etc. It seems like you're trying > to define a whole new command set (i.e., API) for Git, but within the > context of rebase --interactive. I think it would be hard to document > this, and hard to learn it, and harder still to remember it (even > though it would obviously try to mirror the existing Git command API). I agree some of the examples are getting esoteric. Things like --signoff and --reset-author are a fairly straightforward convenience feature: they save you from writing "exec git commit --amend --signoff". For others that cannot currently be done with a simple option to "git commit", I think a reasonable first step would be to implement them there. For example, you cannot currently "git commit --tree". Maybe that is too insane and low-level an option for "git commit". But if it is, then it is almost certainly too insane and low-level for a rebase instruction. For others from Michael's list, I expect they may not make _sense_ outside of a rebase. That is, they are operations whose input is not a single commit, but a sequence of commits (e.g., if you had some high-level command that allowed swapping two commits without having to redo the conflicts from the second commit). Those ones might make sense to exist as part of rebase and nowhere else (but then they are not necessarily just options, but rather new instructions). > That said, I do think that this is probably a bad direction and > shouldn't be rushed into too fast. I'm not sure whether it is a good idea or not. But I think it is looking decreasingly like a good GSoC project. -Peff -- 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