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

quoted text
>> - 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.


quoted text
> 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


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html