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
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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