Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> at the cost of annoying
>
> - a few oldtimers
> - now, instead of later

Nobody seems to have realized this, but suddenly changing the default to
refuse without giving people enough advance warning to adjust will hurt
not just the old-timers (a rough definition is people who are from the
kernel circle and have been using git since summer of 2005), but people
who picked up a recipe from various how-to web pages to push to a live
repository and updating the checkout that is otherwise never touched by
the humans with its post-update hook running "reset --hard".  Old timers
may be savvy enough to know what has changed and may be able to grudgingly
react, but what is your plans for these recipe following kids?

How many times do I have to repeat that it is much worse to break a
working setup of people without advance warning and sound transition
guidance than having a known breakage that users can be trained to avoid?

And realize that I am not saying we need to keep the known breakage
forever.

The only thing I am saying is that you need to have a smooth transition
plan for changing the default, and a mechanism to guide people in place.

I'll ignore you if you keep repeating "all it takes is for old timers to
flip a switch".  Such an argument shows that you didn't learn a thing
after the 1.6.0 fallout.
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux