"Gerald Gutierrez" <ggmlfs@xxxxxxxxx> writes: > if (user_redefined_changed) > if (user_defn_of_changed(work, head)) commit(work); > else > if (builtin_changed(work, head)) commit(work); That would lead to even less intuitive semantics. Suppose your working tree has two changes, like --- a/file +++ b/file @@ ... @@ -old ignored line +new ignored line @@ ... @@ -this is relevant +change What would git be supposed to do if you ignore anything containing "ignored"? If git commits, it will commit both changes. People checking-out the new revision will get "new ignored line" in the file. So, a portion of the diff that you wanted to ignore has actually gone into the repository. IOW, whether "new ignored line" would go into the repository depends on the presence of another unrelated change. Perhaps you would have expected this, but I wouldn't, and I bet many other users wouldn't either. And usually, when you can't have people agree on a common reasonable semantics, the answer is "don't put it in git, let people script the semantics they want". Take another example : I use an external diff tool to work with OpenDocument files. It converts them into text, and calls "git diff" on them. My diff driver therefore ignores formatting changes. If I made only content changes, I get no change with this diff driver. Still, if I commit, I expect git to record my new formatting. -- Matthieu - 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
