Hello!
I used to see messages like this:
$ stg pull
Checking for changes in the working directory ... done
stg pull: local changes in the tree. Use "refresh" or "status --reset"
This time I decided to see what "stg reset --status" actually does,
and I was unpleasantly surprised that it would do much more that its
name implies.
It doesn't just reset the status (no idea what it would be, but it
doesn't sound scary). It removes all local changes. It's essentially
"git reset --hard". I can easily imagine that some beginner would
lose valuable changes by following that advice while trying to update
from the upstream repository.
I would hate to suggest another stg command, as there are too many of
them already. On the other hand, if "applied" and "unapplied" are
downgraded to switches for "stg series", we probably could justify
adding one more command, "stg reset". By the way, the default could
be to save the changes to a hidden "stash" patch, and the "--hard"
switch would do a real reset.
Another (not alternative) approach would be to have an option to "stg
pull" to save the changes as a temporary patch that would be applied
and deleted if it applied cleanly. That shouldn't be a default for
"stg pull", as it's likely that the user just forgot "stg refresh".
--
Regards,
Pavel Roskin
On 2008-04-01 22:21:24 -0400, Pavel Roskin wrote:
This time I decided to see what "stg reset --status" actually does,
and I was unpleasantly surprised that it would do much more that its
name implies.
It doesn't just reset the status (no idea what it would be, but it
doesn't sound scary). It removes all local changes. It's essentially
"git reset --hard". I can easily imagine that some beginner would
lose valuable changes by following that advice while trying to
update from the upstream repository.
I would hate to suggest another stg command, as there are too many
of them already. On the other hand, if "applied" and "unapplied" are
downgraded to switches for "stg series", we probably could justify
adding one more command, "stg reset". By the way, the default could
be to save the changes to a hidden "stash" patch, and the "--hard"
switch would do a real reset.
(I assume "stg reset --status" is just a typo for "stg status
--reset"?)
I'd be fine with removing status --reset, but since there is currently
no other way to do this in StGit, I expect Catalin would object. (As I
recall, that's precisely what happened when I did try to remove it
some time ago.)
I'm currently (slowly) working on an "stg reset" command that'll be
able to reset the stack to any prior state. It could be made to reset
to the most recent recorded state if no extra argument is given, which
I think would make it do what you want.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
On Wed, 2008-04-02 at 14:00 +0200, Karl Hasselström wrote:
(I assume "stg reset --status" is just a typo for "stg status
--reset"?)
Exactly. "stg status --reset" is so against the logic that I could not
even write it properly :)
I'd be fine with removing status --reset, but since there is currently
no other way to do this in StGit, I expect Catalin would object. (As I
recall, that's precisely what happened when I did try to remove it
some time ago.)
1) stg diff | patch -Rp1
2) stg new -m "trash" trash; stg refresh; stg delete trash
Besides, I don't think everything should be easily doable from stgit.
I'm currently (slowly) working on an "stg reset" command that'll be
able to reset the stack to any prior state. It could be made to reset
to the most recent recorded state if no extra argument is given, which
I think would make it do what you want.
Sounds good. Thank you!
--
Regards,
Pavel Roskin