Re: EasyGit Integration
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Jun 10, 2009, 12:13 UTC
- Message-ID
- <20090610121349.GA27679@atjola.homenet>
- In-Reply-To
- <32541b130906091342s7dd6064fud2205bee8af95aab@mail.gmail.com>
On 2009.06.09 16:42:33 -0400, Avery Pennarun wrote:
Show 25 quoted lines
> 2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>: > > On 2009.06.09 15:52:46 -0400, Avery Pennarun wrote: > >> To be honest, I'm not convinced svn's use of the word "revert" is > >> really right, though. Git's isn't *really* right either, since it > >> actually makes a new commit, it doesn't remove the old one like it > >> sounds like it does. Maybe 'reverse' would be a better name for what > >> git does, and we should just introduce another word for what svn does. > >> (With CVS, you just deleted the file and then did a checkout/update > >> on it again, which made sense to me. That works in git too.) > >> > >> Crazy idea: we could actually make 'git revert' do both: given a > >> commit, it applies the reverse as it does now. Given filenames, it > >> simply brings them back to HEAD. But maybe that's too crazy. > > > > Doesn't seem that crazy to me. But maybe a bit problematic if you want > > to support both, "git checkout -- ." and "git checkout HEAD -- .". And > > adding DWIMmery there seems dangerous, as in: > > > > git revert == git checkout -- . > > > > git revert HEAD == > > no uncommitted changes = revert commit HEAD > > uncommitted changes = revert to HEAD > > Well, that's what I meant by "crazy" :)
OK, thinking about it, I really dislike the idea of "revert --since", as that is IMHO better thought of as "get the old version back", and for "get something out of the repo" we have checkout. That would leave us with "revert changes from a commit" and "revert uncommitted/unstaged changes". For that "limited" thing, I could live with:
git revert <commit> # As is git revert --unstaged # git checkout -- git revert --uncommitted # git checkout HEAD -- / git rm --cached
IOW: Mode of operation is chosen by a flag, which has a meaning that is somewhat similar to --cached for diff/rm, it chooses what to use as the source for the operation. And as at least "revert --uncommitted" isn't 100% the same as "checkout HEAD --", I think the overlap that we'd have with a small subset of the checkout functionality might be ok.
Björn