Hi, On Mon, 2 Jul 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
