On Aug 28, 2008, at 3:42 AM, David Woodhouse wrote:
On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote:
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
--
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