On Mon, Dec 15, 2008 at 02:13:13PM -0800, Junio C Hamano wrote: > You can do a merge inside a dirty work tree, and the merge will fail > without clobbering your work tree files that are dirty when it needs to be > able to overwrite to do its job. The set of "dirty files" in this > sentence of course includes paths that are modified since HEAD, but it > also includes also paths that do not exist in HEAD (i.e. "new files"). > > But we already caution users that you need to know what you are doing when > working in such a dirty work tree. Namely, after a failed merge, your > next "git reset --hard" will blow away your local modifications. And > local modifications in this context includes the files you could have > added to the index but you haven't. I strongly disagree. With the suggested behavior I would have to double-check every single untracked file in my tree for conflicts before trying a throw-away merge followed by git reset --hard, for example. The file could even be ignored! Whatever happened to git reset doesn't touch untracked files? I would even prefer breaking t6023 (until we can properly implement this feature) in order to avoid that. -- 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
