git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Scott Johnson" <jaywir3@gmail.com>,
	git@vger.kernel.org, "Constantin Weißer" <i7c@posteo.de>
Subject: Re: Would a config var for --force-with-lease be useful?
Date: Mon, 27 Aug 2018 15:29:33 -0700	[thread overview]
Message-ID: <xmqqd0u3igtu.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <87k1obee0f.fsf@evledraar.gmail.com> (=?utf-8?B?IsOGdmFyIEFy?= =?utf-8?B?bmZqw7Zyw7A=?= Bjarmason"'s message of "Mon, 27 Aug 2018 22:44:00 +0200")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I.e. making plain --force-with-lease harder to use by hiding it behind a
> config option gives the user fewer options than with --force to recover.

I agree with that.  But I would consider it a good thing, if done
properly (i.e. suggest --force-with-lease that is not a lzzy form).

> So I think we should still recommend the longer and even safer variants
> of --force-with-lease, but being guaranteed to have the SHA-1 you just
> clobbered locally is *better*, and allows us to e.g. do this:
>
>     $ git push --force-with-lease
>     hint: You just clobbered <X> on <remote with <Y>. If you regret
>     hint: this you can (until the object gets pruned) do:
>     hint:     git push <remote> --force-with-lease=<refname>:<Y>

Until the object gets pruned, and until somebody else pushes there
to make the damage bigger, you can recover from a mistake with that
information.  It probably is a bug that the lazy force-with-lease
does not report what the remote tip you just overwrote was, and this
would help great deal.  It would be a good place to start.

One thing that I am still not clear how this line of thought truly
would help users is how to help them decide their answer to "If you
regret this".  An unthinking naïve user would say "of course I meant
it when I gave the option---why do you think I regret it?" without a
bit more hint, namely, "<Y> was taken from the remote tracking
branch, are you sure that is still what the newly prepared contents
you built to replace?  Did somebody clobber it while you are not
watching?"

These three lines however will be felt too loud by those who would
most benefit from them (i.e. those who do not know why they need
protection); I do not think advise.* to allow them to be squelched
would be appropriate.

      reply	other threads:[~2018-08-27 22:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-24 16:39 Would a config var for --force-with-lease be useful? Scott Johnson
2018-08-25 13:34 ` Constantin Weißer
2018-08-27 21:21   ` Johannes Schindelin
2018-08-28  9:59     ` Phillip Wood
2018-08-27 19:24 ` Junio C Hamano
2018-08-27 19:40   ` Ævar Arnfjörð Bjarmason
2018-08-27 20:09     ` Junio C Hamano
2018-08-27 20:44       ` Ævar Arnfjörð Bjarmason
2018-08-27 22:29         ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqd0u3igtu.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=i7c@posteo.de \
    --cc=jaywir3@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).