Sam Vilain <sam@xxxxxxxxxx> writes: >>> cd .. >>> success= >>> if git-diff-files >>> then >>> >> ... >> >>> git-reset --hard HEAD && success=1 >>> fi >>> >> >> Wouldn't "reset --hard HEAD" pretty much unconditionally nuke >> your local changes, including added files to the index? For >> example, if I do this: >> >> $ >foo && git add foo && git reset --hard HEAD >> >> it would remove the newly added 'foo' from both the index and >> the working tree. So I am not quite sure what you are trying to >> achieve with "diff-index | perl" magic. > > Right, but we've already checked using diff-files that there weren't any > local changes. So all we're saying is "remove all files which won't be > written by git reset --hard, then checkout new versions of files". I am afraid I am not following your logic. I missed that "if git-diff-files"; it is not checking (you would have to ask for --exit-code or something --- traditionally we never used git-diff-xxxx exit code to indicate if there is any changes). Suppose we update that "if" to see if diff-files says "no change in the working tree wrt the index". But then, I think what you have at the end, "git reset --hard HEAD", where the HEAD is an arbitrary commit that does not necessarily have to do anything with what the index is based on, would remove what is known to the index but not in HEAD. Which was my point about the "diff-index piped to perl". I do not think that one is necessary. Actually, more importantly, why is it justified to remove a file that is unchanged since the index, if the updated HEAD does not have it? That is losing information, isn't it? Or are you assuming that this is used only for a worktree where there is NO actual development happens, but just kept up to date to whatever commit comes at HEAD? - 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
