Re: [PATCH] Documentation: reset: describe new "--keep" option
- From
- Peter Baumann <waste.manager@gmx.de>
- Date
- Mar 8, 2010, 08:47 UTC
- Message-ID
- <20100308084745.GB4827@m62s10.vlinux.de>
- In-Reply-To
- <201003072138.18583.chriscool@tuxfamily.org>
On Sun, Mar 07, 2010 at 09:38:18PM +0100, Christian Couder wrote:
Show 27 quoted lines
> On Sunday 07 March 2010 06:52:46 Junio C Hamano wrote: > > Christian Couder <chriscool@tuxfamily.org> writes: > > > and give an example to show how it can be used. > > > > > > Signed-off-by: Christian Couder <chriscool@tuxfamily.org> > > > Signed-off-by: Junio C Hamano <gitster@pobox.com> > > > --- > > > > Thanks. With the example I think I can tell others that this at least has > > one known use case that is not totally whacky. > > > > I haven't re-read Peter Baumann's comments that you dismissed as a > > mis-reading of your added documentation, but if somebody _can_ misread > > what you wrote, that is a sign that it has a room to be improved for > > clarity. > > Ok, so instead of: > > > +--keep:: > > + Resets the index to match the tree recorded by the named commit, > > + but keep changes in the working tree. Aborts if the reset would > > + change files that are already modified in the working tree. > > what about: > > --keep:: > Resets the index to match the tree recorded by the named commit,
My reading of this (non native english speaker): Given the --keep flag, *only* the index is updated.
> but changed files in the working tree are kept untouched. > Aborts if the reset would touch any of them.
Huh? Does it touch the work tree, too? You propably know by now where this leads :-)
I have to admit I like Junio's version better, because at least it is clear that the worktree is also touched.
-- Peter