Re: disallowing push to currently checked-out branch

From: david@lang.hm <david@lang.hm>
Date: Feb 16, 2009, 05:55 UTC
Message-ID: <alpine.DEB.1.10.0902152143430.14911@asgard.lang.hm>
In-Reply-To: <20090216043708.GB12986@coredump.intra.peff.net>

On Sun, 15 Feb 2009, Jeff King wrote:

Show 20 quoted lines

> On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:
>
>>> So people doing major version upgrades of their OS don't need to read
>>> release notes or re-test behavior?
>>
>> when was the last time you read the release notes for an entire distro?
>
> Since you ask, I track Debian unstable and I read the release notes
> (NEWS.Debian) for every package that I upgrade, and skim the changelogs
> for perhaps half.
>
> But yes, I realize that is not common; I don't expect that every user
> reads every release note.
>
> My point is that things _are_ going to change in a major version OS
> upgrade. It is up to the user to make the tradeoff of how much time they
> want to spend researching those changes versus the likelihood and
> severity of breakage. If I have a mission critical system running git,
> I'm going to read git's release notes. If I don't, then I will probably
> accept that something could break, and fix it if it does.

in that case there's no reason for any warning time. just change the default and put a comment about it in the changelog.

that worked well for the dashed names didn't it.

Show 31 quoted lines

>> and it's not a matter of reading the release notes. it's a matter of them
>> running a version that gives them a warning before you feed them a version
>> that will cause their existing stuff to fail.
>
> The warning is not a panacea:
>
>  1. It might actually cause breakage. Less likely than a straight
>     change in behavior, but still possible.
>
>  2. Users don't necessarily see the warning. By definition, it is not
>     changing the behavior. So unless they are examining the output
>     (which might not be the case for an unattended system), it can go
>     unnoticed.
>
> So all of the problems you are talking about are still possible even
> with an extremely long change cycle.
>
>> I recognise that not all software is concerned about backwards
>> compatibility, but if git wasn't concerned with backwards compatibility
>> and a graceful upgrade process, this thread wouldn't exist.
>
> I think git is much better about backwards compatibility than most
> packages I have seen. But there is a cost to maintaining it completely
> and forever, in that you are either hampered in what you can do (i.e.,
> there are enhancements you would like to make but can't) or you pay an
> awful burden in development cost maintaining two diverging codebases.
>
> Based on the numbers in your last email, you seem to be advocating a
> 9-15 year lag on making any behavior changes in git. I'm sorry, but I
> have no interest in waiting that long to see enhancements I work on in
> git make it into a released version.

two cycles of changes, not three, so 6-10 years for changes that break existing bahavior without a _really_ pressing reason. so new functions, new commands, new flags don't have to wait at all. it's only if you want to change something that will cause grief for users if they get a new version and run their existing tools against it.

Show 5 quoted lines

> I think Junio is doing a fine job at dealing with backwards
> compatibility and keeping things moving at a reasonable pace. If you
> think it should go slower, you are certainly welcome to fork and release
> an "ultra-stable" version of git that reverts any backwards incompatible
> changes while keeping up with other new features.

I am not interested in forking git. but I am saying that a backwards incompatible change had better _really_ be worth it, and not just be worth it for the people who live an breath git, but for the users as well (this is a test that the dashed name elimination failed. in spite of a volcal few saying that all the commands in the path were causing problems, most people couldn't understand why the git people wanted to remove them)

for anything less than a fairly critical bug, if it's in a public interface you really don't want to change it (in part becouse the timeframe to properly depriciate it, with warnings, needs to happen on timescales measured in years)

and I agree that Junio is doing a good job with this. he's the one who started this thread to discuss the possible changes after all.

David Lang

> -Peff
>