Re: [RFD] Making "git push [--force/--delete]" safer?
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Jul 3, 2013, 12:06 UTC
- Message-ID
- <51D413BA.6080709@viscovery.net>
- In-Reply-To
- <51D40203.1010100@alum.mit.edu>
Am 7/3/2013 12:50, schrieb Michael Haggerty:
Show 23 quoted lines
> On 07/03/2013 12:11 PM, Johan Herland wrote: >> On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother >> <maillist@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.
I don't think that is necessary. We already have *two* options to force-push a ref: the + in front of refspec, and --force.
IMO, the meaning of + should be changed to "force-push with safety", and --force can then be used to override if the safety triggers (i.e., --force is your extra-super-force option).
-- Hannes