Tzu-Jung Lee [off-list ref] writes:
Is this an intended behavior?
Yes, I think you are talking about the case where "the current index does
not match the current HEAD, but it does match the tree we are switching
to" case. In that case we take the contents of switched-to branch.
It is the last case in the table in this old design document:
http://thread.gmane.org/gmane.comp.version-control.git/4641
bug ignore the terminology (stage#). Read only the body of the table, with
the understanding that the three entries in each row talk about the state
for the same path in the index entry, the tree entry in the current HEAD,
and the tree entry in the switched-to branch. Also the table does not talk
about the checking performed on the working tree file, but assume that we
do not overwrite it when the resulting entry in the index does not match
what you have there.
The reason we allow branch switching in this case, instead of failing, is
so that you can be in a state where you applied the same change (relative
to the current branch to the branch you are switching to) lying around
already in your workspace and safely switch to the new branch without
losing any work (after all, the content matches).
By the way, the first six lines of your original message that describes
"saving and applying" is not correct.
On Fri, Sep 2, 2011 at 1:11 AM, Junio C Hamano [off-list ref] wrote:
Tzu-Jung Lee [off-list ref] writes:
quoted
Is this an intended behavior?
Yes, I think you are talking about the case where "the current index does
not match the current HEAD, but it does match the tree we are switching
to" case. In that case we take the contents of switched-to branch.
It is the last case in the table in this old design document:
http://thread.gmane.org/gmane.comp.version-control.git/4641
Cool! It's really valuable resource about the internals. Do all the
entries of the matrix still hold true today?
Maybe we can have an updated version put in the manual or other
official documentation.
bug ignore the terminology (stage#). Read only the body of the table, with
the understanding that the three entries in each row talk about the state
for the same path in the index entry, the tree entry in the current HEAD,
and the tree entry in the switched-to branch. Also the table does not talk
about the checking performed on the working tree file, but assume that we
do not overwrite it when the resulting entry in the index does not match
what you have there.
The reason we allow branch switching in this case, instead of failing, is
so that you can be in a state where you applied the same change (relative
to the current branch to the branch you are switching to) lying around
already in your workspace and safely switch to the new branch without
losing any work (after all, the content matches).
I understand it's a safe behavior in the sense that all the 'content'
are preserved. But the 'work' may still lost in another sense.
Consider the extended scenario. I was in the middle of doing... kind
of 'in-commit-bisection' (btw, how would you call this?).
Finding out which are the guilty changes in a giant patch that has
large number of changes including binary updates.
(good) (good) (bad)
index HEAD switchd-to
A1 A1 A2
B2 B1 B2
C2 C1 C2
D2 D1 D2
E1 E1 E2
...
I accidentally switch to the switched-to branch without committing the
intermediate status.
The 'work' was gone, and I had no idea how to bring it back.
By the way, the first six lines of your original message that describes
"saving and applying" is not correct.
I accidentally switch to the switched-to branch without committing the
intermediate status.
The 'work' was gone, and I had no idea how to bring it back.
Forgive me if I am missing something here, but can't you use reflog to
go back to the point just before you checked the switched-to branch
out?
I guess the question is in general, how do you revert to a previous
instance of the working index AND previous checked out branch? I don't
know the 'switch branch with modified working index' mapping well
enough to be able to determine if there is a bijection possible, a
concise description of it would probably show us. If not, the only way
to achieve this is to keep the history available.
Regards,
Andrew Ardill