Re: [RFD] Making "git push [--force/--delete]" safer?
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Jul 3, 2013, 10:50 UTC
- Message-ID
- <51D40203.1010100@alum.mit.edu>
- In-Reply-To
- <CALKQrgfQhVVC1NxizjCQdDmNfihfyEgypYddWB0CMTPqW9Mxtg@mail.gmail.com>
On 07/03/2013 12:11 PM, Johan Herland wrote:
Show 12 quoted lines
> 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.
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
-- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/