On 27.01.16 12:59, Junio C Hamano wrote: > Clemens Buchacher <drizzd@xxxxxx> writes: > >> If committed files are not normalized, adding gitattributes has the >> side effect that such files are shown as modified, even though they >> were not actually modified by the user, and the work tree matches >> the committed file. This is because with gitattributes, the file is >> modified on the fly when git reads it from disk, before it compares >> with the index contents. >> >> This is desirable in most situations, because it makes the user >> aware that files should be normalized. However, it can become an >> issue for automation. Since Git considers the work tree to be >> dirty, some operations such as git rebase or git cherry-pick refuse >> to operate. Those commands offer no flag to force overwrite work >> tree changes. The only options are to commit the changes, or to >> remove gitattributes, but that changes the repository state, which >> may be undesirable in a scripted context. It feels like a workaround for something that could be fixable, or is already ongoing. Before going into more details, could you tell us which attributes you are typically using (when having this problems) ? Is it * text=auto or *.sh text or something else? >> >> Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if >> set makes Git ignore any gitattributes. >> >> Signed-off-by: Clemens Buchacher <drizzd@xxxxxx> >> --- > > Is the problem you are trying to solve related to the issue we > discussed recently in a nearby thread? It seems that I missed the thread ? > > That is, even after "reset --hard", if the result of converting the > contents in the index to the working tree representation and then > converting that result back to the normalized representation does > not match what is in the index, Git would sometimes say that the > working tree contents differ from the index? > > I think the change in this patch has some uses, and I think the > issue we discussed recently in a nearby thread indeed is a problem, > but I do not think there is an impedance mismatch beween the two, so > I'd like to first make sure you are trying to solve the problem I > think you are trying to solve. -- 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