On Tue, Apr 17, 2007 at 05:02:43PM -0700, Junio C Hamano wrote: > "Robin H. Johnson" <robbat2@xxxxxxxxxx> writes: > > > As for a usage case: > > - J.PEBKAC.User gets a a tree (from a tarball or GIT, we should gain the > > same output) > > - Copies some file outside of the tree (the user is NOT smart enough, > > and resists all reasonable attempts at edumacation) > > - Modifies said file outside of tree. > > - Contacts maintainer with entire changed file. > > - User vanishes off the internet. > > > > The entire file he sent if it's CVS, contains a $Header$ that uniquely > > identifies the file (path and revision), and the maintainer can simply > > drop the file in, and 'cvs diff -r$OLDREV $FILE'. > > If it's git, the maintainer drops the file in, and does 'git diff > > $OLDSHA1 $FILE'. > > I personally hope that the maintainer drops such a non-patch > that originates from a PEBKAC. At least I hope the tools that I > personally use are not maintained by such a maintainer ;-) That may not be quite fair--note the 'git diff $OLDSHA1 $FILE'. So the $Header$ here is a hint telling the maintainer how to produce a (hopefully) reviewable patch, not an invitation to blindly drop random files into the tree. (Other objections to accepting code from random non-reachable people aside....) I've occasionally wondered before whether git could offer any help in the case where, say, somebody hands me a file, I know it's based on src/widget/widget.c from somewhere in v0.5..v0.7, and I'd like a guess at the most likely candidates. I haven't wondered that often enough that I'd consider it worth embedding the blob SHA1 in every checked-out file, though! --b. - 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