Junio C Hamano schrieb: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> "git archive" is used to create archives from a tree (or commit), so >> it should not consult any .gitattributes files on working directory. >> >> It currently does,... > > ...which _might_ be actively used as a _feature_ by people; I do not think > it is a bad idea to have a mode of operation where it solely works with > in-tree attributes ignoring the work tree ones, and I suspect we probably > would want to make that the default, but "so it should not" is probably a > bit too strong. > > For example, an older version may record $Id$ with keyword expansion set > in its in-tree .gitattributes, and you later found it to be a mistake and > have removed it in the current version. Re-exporting an older version > with the current code wouldn't have $Id$ expanded, but with your patch it > will. > > A stronger example would be crlf conversion, I suppose, but the same "with > the current code we can fix it up but after this patch we can't" worry > applies. > > So perhaps you may want to resurrect the current behaviour with a new > option --fix-attributes, whose description would be "normally the command > takes attributes settings from the tree being exported, but .gitattributes > files in it may record wrong attributes you may want to fix while > exporting. With this option, corresponding .gitattributes files in the > work tree will override the in-tree .gitattributes" or something like > that. Hmm, "fix" implies that something is broken without this option, which is not necessarily the case. A purely descriptive name like --worktree-attributes fits better IMHO. Also, the last sentence of the description may be taken to imply a mixing of attributes from work tree and exported tree is done, which is not the case with the patch from series 2 (and shouldn't be). Perhaps: "With this option, .gitattributes files are read from the work tree instead of from the exported tree." René -- 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