Re: [RFD] Making "git push [--force/--delete]" safer?

Junio C Hamano [off-list ref] writes:

Jonathan del Strother [off-list ref] writes:

quoted

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?

Not until we run this in the wild for a while and the mechanism
proves to be useful without being too cumbersome to some population.

Then at a major version bump, we can start talking about enabling it
by default, allowing people to selectively disable it.

If we enable this by default, we would need to be a lot more careful
designing what should happen when there is no remote-tracking branch
the corresponds to what we are updating/deleting.

The proposed behaviour so far is to fail, and that is justifiable
because "the user asked us to check, but did not say what to check
against, and we tried to check with a remote-tracking branch and
found none.  We cannot satisfy the user's request to check, hence we
fail".

Enabling the check by default will change the picture somewhat; that
justification no longer holds.

If you are pushing to more than one publishing branches of your own,
there is no reason to have remote-tracking branches for the
secondary locations, because you always push to all your publishing
repositories at the same time, and you only need to keep remote
tracking for one of them to remember what you pushed out.  Making a
push to secondaries fail in such a case is bad, and forcing the user
to disable the feature for each secondary remotes is unnice, too.