Johannes Schindelin [off-list ref] writes:
I am not quite sure if this should not be the default, with
--skip-index to turn it off if the trivial index merge fails,
and the user might be interested only in the working directory
changes anyway.
Comments?
There is a bit of impedance mismatch between a rename-aware
three-way merge (aka merge-recursive) used to update the working
tree and a patch that updates the index. The "rename-aware"
thing can be fixed by doing the diff with -M, though.
It might be easier to explain (1) not have --index option, but
attempt to do this always, and (2) even if the index cannot be
updated, keep going, without worrying about losing the
difference between I and W, probably with a message to the end
user.
Suppose you are the user who gets "perhaps you would want to run
without --index?" hint. What can you do? Run without --index,
or forget about unstashing. But the latter does not sound like
an option. So it feels to me that --index is an unnecessary
option.
The potential confusion problem I mentioned in two of my earlier
messages due to the program doing one thing sometimes and
another thing some other times still applies, though.
Hi,
On Mon, 2 Jul 2007, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
I am not quite sure if this should not be the default, with
--skip-index to turn it off if the trivial index merge fails,
and the user might be interested only in the working directory
changes anyway.
Comments?
There is a bit of impedance mismatch between a rename-aware
three-way merge (aka merge-recursive) used to update the working
tree and a patch that updates the index. The "rename-aware"
thing can be fixed by doing the diff with -M, though.
Ah yes, I did not think about renames. But like you said, adding -M to the
diff should help that.
It might be easier to explain (1) not have --index option, but attempt
to do this always, and (2) even if the index cannot be updated, keep
going, without worrying about losing the difference between I and W,
probably with a message to the end user.
Okay, in this case I propose to make this the default, with an option
"--skip-index" to only try re-apply the changes to the working directory.
Suppose you are the user who gets "perhaps you would want to run without
--index?" hint. What can you do? Run without --index, or forget about
unstashing. But the latter does not sound like an option. So it feels
to me that --index is an unnecessary option.
It is very much like the choice you have with "git checkout" vs "git
checkout -f". Either you change your index accordingly, or you say "I
don't care about the index. What changes I had there, I will reconstruct
myself."
The potential confusion problem I mentioned in two of my earlier
messages due to the program doing one thing sometimes and another thing
some other times still applies, though.
Yes, that's why I would suggest not going ahead when the index could not
be easily merged. Rather give the user enough information to decide.
Of course, this means that in complicated cases, the user mustn't run and
hide when she hears "index!", but I guess that complicated cases always
need you to know your tools better than easy problems.
Ciao,
Dscho