On Sun, Mar 2, 2014 at 4:04 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote: >> "git rebase -e XYZ" is basically the same as >> >> EDITOR="sed -i '1s/pick XYZ/edit XYZ/' $@" \ >> git rebase -i XYZ^ >> >> In English, it prepares the todo list for you to edit only commit XYZ >> to save your time. The time saving is only significant when you edit a >> lot of commits separately. > > Should this accept multiple -e arguments? Based upon the above > justification, it sounds like it should, and I think that would be the > intuitive expectation (at least for me). > > The current implementation, however, is broken with multiple -e arguments. With: > > git rebase -i -e older -e newer > > 'newer' is ignored entirely. However, with: > > git rebase -i -e newer -e older > > it errors out when rewriting the todo list: > > "expected to find 'edit older' line but did not" > > An implementation supporting multiple -e arguments would need to > ensure that the todo list extends to the "oldest" rev specified by any > -e argument. Of course, I'm misreading and abusing the intention of -e as if it is "-e <arg>". -- 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