Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

On Aug 28, 2008, at 3:42 AM, David Woodhouse wrote:

On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote:

quoted

Are you suggesting that I break into machines that I don't have  
access
to add a export PATH= line to copies of scripts that were written 6
months ago, and worked just fine until someone decided that "upward
compatibility" wasn't an important concept?

Not at all. But as long as you also refrain from breaking into those
same machines and upgrading them to git 1.6.0, you should be fine.

I was being over-dramatic in an attempt to get people to at least try  
to think it out.  You did, thanks!

But the actual problem is that I provide a central repository with  
"the current version of git" for us.  I'm not sure who all pulls from  
that repository, but a number of them have finally learned git well  
enough to clamor for 1.6.0.

So it's them upgrading from my repository, not me upgrading for them.

Or if you _do_ upgrade them to git 1.6.0, you should make sure you  
build
with gitexecdir=/usr/bin to prevent the breakage.

That's a hack, which will burn me in less than a year.

What distribution are you running on those machines? If they upgrade
their version of git from an earlier version to 1.6.0 in a stable
release without setting gitexecdir=/usr/bin to preserve compatibility,
then the packager needs to be taken out back and shot.

I'm the packager.  I didn't upgrade our customized version of git  
because I'm still trying to think it out.

I don't get to break things.  If I break them, I gotta fix them.  I  
haven't been paid to do git stuff for months, and I have a deadline  
tomorrow.  But I gotta act now if I want a chance to live a life  
without the git community breaking upward compatibility on minor  
version releases for completely frivolous reasons.  It wasn't broke,  
but you "fixed" it anyway.  What's next?

I'm more worried about what's next and what's already slipped through  
than this one particular thing.

-- Perry