Re: Does GIT has vc keywords like CVS/Subversion?

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Oct 9, 2006, 21:08 UTC
Message-ID: <46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0610090904360.3952@g5.osdl.org>

On 10/10/06, Linus Torvalds <torvalds@osdl.org> wrote:

Show 6 quoted lines

> So:
>  - inside of the SCM, keyword substitution is pointless, since you have
>    much better tools available (like "git log filename")
>  - outside of the SCM, keyword substitution can make sense, but doing it
>    should be in helper scripts or something that can easily tailor it for
>    the actual need of that particular project.

For the outside of the SCM case, keyword subst is useful indeed if someone has a $version_unknown tarball, unpacks it and hacks away. It is a pretty broken scenario, and less likely to happen nowadays with easy access to SCM tools.

However, I don't think that scenario is hard to support and Git can have a much better story to tell than keyword substituting SCMs.

If we have a tool that I can pass a file or a directory tree and will find the (perfectly|closely) matching trees and related commits.

For the single file case, searching for an exact SHA1 match is easy, as is by path. If we get a file without a path it gets a bit harder -- is there a way to scan the object store for blobs of around a given size (as the packing code does) from Perl? Actually, if we find a relatively close match, it'd be useful to ask git if it's deltified and ask for other members of the delta chain.

For the directory tree case, the ideal thing would be to build a temporary index without getting the blobs in the object store, and then do a first pass trying to match tree SHA1s. If the user has modified a few files in a large project, it'll be trivial to find a good candidate commit for delta. OTOH, if the user has indulged in wide ranging search and replace... it will be well deserved pain ;-)

cheers,

martin