On Wednesday 14 January 2009, Miles Bader <miles@xxxxxxx> wrote about 'Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state': >"Boyd Stephen Smith Jr." <bss@xxxxxxxxxxxxxxxxx> writes: >>>We may need a version bump to 1.7.0 to update the UI for this command, >>> but please do test rigorously to build a stronger case for a saner UI. >> >> Instead of changing the meaning of edit, how about introducing a >> "replace" command? > >That seems like at best an awkward workaround, not a real solution to >the problem, Actually, I think it's a better solution (or rather a solution to the real problem) because others have already said they like and expect the current edit behavior. The "real problem" is you need different behavior for your interactive rebasing. >which is that the term "edit XXXX" suggests you're starting >with XXXX and modifying it. Exactly. "edit" is: While interactively rebuilding history (rebase -i), you get to the first place that commit existed and then modify it (commit --amend or other tools). >The term "replace" by contrast, seems more >to connote entirely removing XXXX and substituting something else. Exactly. "replace" is: While rebasing you stop just before the commit existed (changes are even staged) and decide to do something else (like using add -i and a few commit commands to split the thing up or whatever). >[I do wonder how on earth the current awkward behavior was accepted in >the first place...] (Actually, I do too, but it's accepted and expected behavior now--good reason not to change it.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@xxxxxxxxxxxxxxxxx ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.
