Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 31, 2007, 10:50 UTC
Message-ID: <B3C76DB8-076D-4C43-AC28-99119A05325C@zib.de>
In-Reply-To: <7v8x5jiseh.fsf@gitster.siamese.dyndns.org>

On Oct 31, 2007, at 9:45 AM, Junio C Hamano wrote:

Show 8 quoted lines

>> - git push can be configuration to push only the current
>>   branch, as outlined below. This would certainly work. What
>>   I do not like is that you first need to do some configuration
>>   before you get a safe working environment.
>
> I would not doubt it would be safer for _your_ workflow, but you
> should consider the risk of making things more cumbersome for
> workflows of others by enforcing that policy.

Together with the '--create' flag it would be safer in all cases, because it would always do _less_ than what git push currently does. The safest choice would be if "git push" refused to do anything until configured appropriately.

"safer" is independent of the workflow.

But I see that it may be more cumbersome depending on the workflow.

I'm mainly interested in using git against a shared repo, and make it as simple and as safe as possible to use in such a setup. I suspect that git is more optimized for the workflow used for the Linux kernel and for developing git, which heavily rely on sending patches to mailing lists and pulling fro read-only repos.

> In other words, don't change anything unless you have a very
> good reason to convince everybody else that it is universally
> a good change to the default.

What I can imagine would not be universally better, but it would be universally safer. You'd need to either explicitly tell git push how to act (e.g. '--current' or '--matching' flags), or you could explicitly configure git to always act in a specific way. But it would only start to act this way _after_ being configured appropriately.

	Steffen