Re: unmerging feature branches
- From
Alejandro Martinez Ruiz <alex@flawedcode.org>
- Date
- Oct 31, 2007, 21:16 UTC
- Message-ID
- <20071031211658.GA5430@inspiron>
- In-Reply-To
- <alpine.LFD.0.999.0710231026011.30120@woody.linux-foundation.org>
On Tue 23 Oct 2007, 10:40, Linus Torvalds wrote:
Show 21 quoted lines
>
> So a "revert" is fundamentally different from a "undo". Most of the time
>
> [cut]
>
> So sometimes the behaviour of "git revert" will be exactly what people
> expected and wanted ("good, I'll never get that commit again when I pull,
> because I told git that I don't want that commit"), and sometimes it will
> _not_ be what people expected and wanted ("oh, I didn't get that commit,
> even though I was now ready for it - because I had reverted it back when I
> was *not* ready for it").
>
> See? The logic is exactly the same in both cases, but one was good, the
> other bad, and the only difference was really the mindset of the user.
>
> A tool can't ever get "mindset of the user" differences right. At least
> not until we add the "esp option" ;)
>
> So I really don't want to push this as a problem or deficiency, I think
> it's a good thing. But it's a good thing only when people are *aware* of
> what "revert" really means.So how about an "undo" command or a switch for revert with a special meaning like "hey, this one is a nice commit, but it ain't ready yet, I'd like you to ignore I ever committed the thing when merging or rebasing again, thanks"?
Alex