Re: [PATCH 2/2] Add keyword unexpansion support to convert.c

"Robin H. Johnson" [off-list ref] 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 ;-)

On Tue, Apr 17, 2007 at 05:02:43PM -0700, Junio C Hamano wrote:

"Robin H. Johnson" [off-list ref] writes:

quoted

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.

On Tue, Apr 17, 2007 at 05:02:43PM -0700, Junio C Hamano wrote:

quoted

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 ;-)

I certainly wasn't stating blindly commit the file. Any Gentoo developer
doing that should not have made it through the recruitment process.

Do the diff, separate the wheat from the chaff, and then put the useful
(and reviewed) changes back into the tree.

Glancing at the Gentoo bugs I've dealt with over the last 2 months as a
quick survey, there are a few levels: 
A - Able to submit a good diff
B - Able to do a good implementation
C - Able to come up with a good idea for improvement

B are in short supply, and even of those, the number that can do A are
smaller :-(. Category C is vastly bigger than B, and those that don't
make B throw up a lot of chaff of bad implementations.

Being able to extract the good ideas is what's important.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

On Tue, 17 Apr 2007, J. Bruce Fields wrote:

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.

It's actually fairly easy to do.

Get the git hash of the blob: use "git hash-object" to do so (although 
you can do it without git too, see later), then just do

	git whatchanged v0.5..v0.7 -- src/widget/widget.c

and just look for the hash. If it's an exact match, you'd find it there, 
and it will tell you when it changed.

If it's *not* an exact match, you have to come up with some "measure of 
minimality" for the thing (the size of the diff might be a good one), and 
you can do

	git rev-list --no-merges --full-history v0.5..v0.7 -- src/widget/widget.c > rev-list

which will get you a full set of commits that changed that file. Then you 
can just do something like

	best_commit=none
	best=1000000
	while read commit
	do 
		git cat-file blob "$commit:src/widget/widget.c" > tmpfile
		lines=$(diff reference-file tmpfile | wc -l)
		if [ "$lines" -lt "$best" ]
		then
			echo Best so far: $commit $lines
			best=$lines
		fi
	done < rev-list

and you're done!

(Yeah, I'm sure that script could be improved, but it's probably really 
not that bad even as-is! The initial "git rev-list" will have done all 
the heavy lifting, and picked out the commits that matter)

I haven't wondered that often enough that I'd consider it worth
embedding the blob SHA1 in every checked-out file, though!

It really doesn't pay.

Besides, if you actually have the file, you can trivially get the SHA1 
_without_ embedding it into the file. Just do

	(echo -e -n "blob <size>\0" ; cat file) | sha1sum

where "size" is just the size in bytes of the file.

So embedding the SHA1 doesn't actually buy you anything: every blob BY 
DEFINITION has their SHA1 embedded into them.

In fact, embedding the SHA1 (or doing any other modifications) just makes 
it harder to do this, since then you have to filter it out again.

		Linus

On Tue, 17 Apr 2007, Junio C Hamano wrote:

"Robin H. Johnson" [off-list ref] writes:

quoted

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 ;-)

As a concrete example, say I'm not a Gentoo developer at all, but I'm 
trying to get some package to install in a slightly odd situation. (E.g., 
I want to build a version of gcc for ARM microcontrollers, which requires 
flags to be set that aren't normally available for the ARM architecture.) 
In order to do this, I need to make some changes to the gcc ebuild to pass 
those USE flags through to configure. Since I'm not a Gentoo developer, I 
don't have the version-controlled tree, just: (1) the tree that gets 
reverted to the official state every time I sync and (2) my tree of local 
overlays. (2) also contains other packages I've made modifications to 
(adding patches to packages where those patches are only in unreleased 
version, but solve my problems, e.g.), so it's clearly the place to put 
the gcc change.

Now, if I figure out how to get the ebuild working, I'll be happy just to 
have a working compiler for this weird target, and I don't care too much 
further. But then if word gets out that I managed this, or if I notice a 
bug report that other people are failing to get it to build, I may want to 
post my working ebuild. And maybe the maintainer decides that my method 
was good, and wants to use it. But then it could be a lot of work to 
figure out what differences are from me beating on this ebuild, what are 
important, and what are reverts of changes make upstream after I made my 
copy (particularly because the same ebuild for gcc also gets a lot more 
development making it better as the system native compiler).

If the ebuild has the blob ID that the file had when it left Gentoo 
version control and went out into local hack land, it would be relatively 
easy to figure out what patch should be applies to get the useful changes.

(In case you're wondering, I actually eventually gave up and installed a 
gnu-arm binary distribution, because I was in a hurry to get the project 
going, and building from source kept failing to get configured properly; 
but if my first line of attack had worked, I would have ended up with the 
described hacked ebuild.)

	-Daniel
*This .sig left intentionally blank*

Hi,

On Tue, 17 Apr 2007, Junio C Hamano wrote:

"Robin H. Johnson" [off-list ref] writes:

quoted

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.

Me, too. Although people really believe strange things. When I asked such 
a guy on another list, if he could send me a patch instead of a complete 
file, he shouted loudly at me that patches were obsolete. Yes. Really. I 
begged to differ, but I guess he still believes that.

Ciao,
Dscho