Junio C Hamano <junkio@xxxxxxx> writes: > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > >> Given the ugliness in -mm making it an error to have an >> non-attributed patch would result in people specifying --author >> when they really don't know who the author is, giving us much >> less reliable information. >> >> Possibly what we need is an option to not make it an error so that >> people doing this kind of thing in their own trees have useful >> information. > > I agree it is probably a good way to error by default, optinally > allowing to say "don't care". I do not think Linus would pull > from such a tree or trees branched from it into his official > tree, so I do not think we would need to worry about commits > with incomplete information propagating for this particular > "gitified mm" usage. But as a general purpose tool to produce > "gitified quilt series" tree, we would. > > It depends on the expected use of the resulting gitified mm > tree. > > If it is for an individual developer to futz with and tweak > upon, and the end result from the work leaves such a "gitified > quilt series" repository only as a patch form, then not having > to figure out and specify authorship information to many patches > is probably a plus; the information will not be part of the > official history recorded elsewhere anyway. So what we need for this case really is a way to mark the commit objects in such a way that git-fetch or git-merge would choke on the commit objects and refuse to merge. That way the changes could not easily propagate in the wild. Every user would at least have to specify a non-default option, that Linus at least would never specify. This scenario is how I have been primarily using such a tree. > However, if it is to produce a reference git tree to point > people at, (i.e. the quiltimport script is run once per a series > by somebody and the result is published for public use), I would > imagine we would want to have the attribution straight, so if > the tool has to "guess", it should either error out or go > interactive and ask. Reasonable. Going interactive is probably the best way since it appears that the patches do have sufficient information to derive the user information from. I know people have at various times in the past made the Andrews tree available in git form so you could do things like git-bisect, etc. So I think we need to address this issue. Probably by at least asking Andrew about it. I will take a look at the policy and see what I can do. At the very least the default we be to error on such a tree. .. A infrastructure question came to me when looking at this: several of the patches are from a branch with several authors. How do we specify a commit in git with several authors? There are cases when you have enough collaboration that even a single patch could have multiple authors, contributing equally. Eric - : 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