Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > This is one of the concerns I had while creating this iteration. What > do you suggest? Should we limit the number of paths listed like this? Personally, I do not think you should list any paths. If the program states clearly that it does not like to see a dirty working tree (or a dirty working tree is likely to be a mistake by a forgetful user), the user already has enough tools such as "git status" and "git diff" to figure out which ones are dirty. > - If it's an "edit", "squash" or "fixup" interactive rebase step, the > staged changes are automatically committed to the current commit: > you don't have to explicity commit --amend. It might be somewhat irritating to see "you haven't committed the amend" against "rebase --continue" after running "git add" or "git add -p" to shape what should be the final commit, and that is why the codepath runs "commit --amend" for the user, but I personally think this is an attempt to help users that is ill-thought-out. The codepath stops when there are changes to the working tree files that are not added, to avoid mistakes by a forgetful user, but what if the change the user forgot to add was an addition of a new file? Also, this is one special case that the user has to remember. It is too late to change this now, but it would have been a lot nicer if we insisted that the "commit --amend" is always done by the user, and never automatically by "rebase-i --continue" codepath. > - If it's a "reword" step, staged changes/ dirty working tree don't > mean anything. The use should simply stash everything and continue > in this case. Why would "reword" involve _any_ local changes? > I suppose I can come up with a way to check which path was taken and > print more targeted advice. Will do in the next iteration. In general, I am mildly against giving advices like "commit or stash", especially when the program does not know the workflow the end user in each situation is using better than the end user. -- 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