On 02/28/2014 01:52 PM, Jeff King wrote: > [...] > Sorry, I missed an important word in my final sentence. It should have > been "the examples you gave are NOT particularly interesting to me". > > On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote: >> 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.
I guess I misread the sentiment of the mailing list, because I merged this idea into the list about two hours ago. I'm not claiming that all of the sub-ideas are good, but I do think that some of them are, and that the general idea of allowing options on todo-list commands would make it possible for them to be more expressive while *avoiding* making them a lot harder to learn. I would rather give the user a few options that can be used consistently on multiple commands than have to invent a new command for each new feature. And I think that the line-oriented nature of the todo list makes pick --signoff 1234abc Blah blah easier to understand (and easier to type) than pick 1234abc Blah blah amend --signoff let alone pick 1234abc Blah blah exec git commit --amend --signoff I also like the idea of a non-broken "git rebase --interactive --preserve-merges" via a todo option "-p" or something similar. But if you think that even the proposal's simpler sub-ideas are controversial, then let me know and I will delete the idea from the list again. I don't want a GSoC student to have to fight battles of my own creation :-) Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html