On 07/03/2013 12:11 PM, Johan Herland wrote:
> On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother
> <maill...@steelskies.com> wrote:
>> I'm struggling to think of instances where I wouldn't want this
>> CAS-like behaviour.  Wouldn't it be better to make it the default when
>> pushing, and allowing the current behaviour with "git push
>> --blind-force" or something?
> I believe I agree with you. I guess the reason this hasn't come up
> before is that by far most of the pushes we do are either
> fast-forwarding, or pushing into a non-shared repo (e.g. my own public
> repo),  and this safety only really applies when we're forcing a
> non-fast-forward push into a shared repo...

I didn't see Jonathan's original email but I was having exactly the same
though as him (and was even going to propose the same option name).

Non-ff pushing without knowing what you are going to overwrite is
irresponsible in most scenarios, and (if backwards-compatibility
concerns can be overcome) I think it would be quite prudent to forbid a
non-ff push if there is no local remote-tracking branch that is
up-to-date at the time of the push.  Circumventing that check should
require some extra-super-force option.

So yes, I very much like the general idea of the RFD and personally
would lean towards making it stronger and default, at the 2.0 transition
if necessary.


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

Reply via email to