Christian Couder [off-list ref] writes:
and give an example to show how it can be used.
Signed-off-by: Christian Couder <redacted>
Signed-off-by: Junio C Hamano <redacted>
---
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.
On Sunday 07 March 2010 06:52:46 Junio C Hamano wrote:
Christian Couder [off-list ref] writes:
quoted
and give an example to show how it can be used.
Signed-off-by: Christian Couder <redacted>
Signed-off-by: Junio C Hamano <redacted>
---
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,
but changed files in the working tree are kept untouched. Aborts if the
reset would touch any of them.
?
Thanks,
Christian.
On Sun, Mar 07, 2010 at 09:38:18PM +0100, Christian Couder wrote:
On Sunday 07 March 2010 06:52:46 Junio C Hamano wrote:
quoted
Christian Couder [off-list ref] writes:
quoted
and give an example to show how it can be used.
Signed-off-by: Christian Couder <redacted>
Signed-off-by: Junio C Hamano <redacted>
---
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:
quoted
+--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