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

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Apr 17, 2007, 21:18 UTC
Message-ID: <46a038f90704171418p354cde19h8ab3c47eed36f04e@mail.gmail.com>
In-Reply-To: <200704172012.31280.andyparkins@gmail.com>

On 4/18/07, Andy Parkins <andyparkins@gmail.com> wrote:

Show 5 quoted lines

> On Tuesday 2007, April 17, Linus Torvalds wrote:
> > So you will never work with anybody outside of git?
> For my projects - correct; I don't care about the rest of the world.
> For projects that do - don't enable keywords, it's an option, all I
> want is to have that option.

GIT's fundamental respect for the contents its tracking (in not munging them with keyword expansion) means that it works great in contexts where other SCMs tools are used. And being content-centric at the SCM layer means that it is possible to track a git project with - say - Mercurial (and vice-versa) with nothing more than a bit of perl glue and no guessing at all. The content is the content is the content.

When the SCM has "munge-the-content" options, your "upstream" can make things completely un-trackable. Tracking CVS with git is a breeze but there is breakage related to keyword expansion. I should write some better heuristics for it, but it's impossible to know with 100% certainty that you are doing the right thing, and getting the correct content from CVS.

All this talk of breaking non-git-patch goes back to the same. With the current design, projects that use git are easily trackable if you just look at the content, and ignore the SCM. That's an outstanding property and quite central to the design, and I wouldn't include an option to "turn it off" even if the patch to implement it turns out to be trivial.

Probably using make will help - you might be able to wire it to work off a post-update-hook so it's completely transparent.

cheers,

martin