Question: is there a possibility of getting a warning before a git push -f

> One thing I sometimes encounter is that I sometimes git push -f and
> moments later I realise I did it at the wrong time, result being a
> disaster. I was wondering if a little [y/N] warning could be possible
> before the risky command gets executed. I saw the code for push
> superficially and I don't think it's implemented. I think it would be
> a nice feature though.

> On 10 Jun 2025, at 12:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Aditya Garg <gargaditya08@live.com> writes:
> 
>> One thing I sometimes encounter is that I sometimes git push -f and
>> moments later I realise I did it at the wrong time, result being a
>> disaster. I was wondering if a little [y/N] warning could be possible
>> before the risky command gets executed. I saw the code for push
>> superficially and I don't think it's implemented. I think it would be
>> a nice feature though.
> 
> I suspect that an even nicer feature that is more generally
> applicable is a patch to your shell to make any command you give it
> is not run for a few seconds to give you a chance to kill it with
> ^C.  You do not want to run around castrating a bunch of commands
> and features like "git push", "rm", ">overwrite-with-redirect", and
> all the other "destructive" things you may regret doing.  There are
> literally too many.
> 
> Quite honestly, "-f" or "--force" should be a hint enough that the
> user wants the command to do what the command usually does not allow
> them to do to avoid potentially dangerous operations.
> 
> I would expect that many people will truly get annoyed when "git
> anycommand --force" starts asking "That's very dangerous---are you
> sure?" for confirmations, and would complain "Yes, otherwise I
> wouldn't be giving you '--force'---just do it as I told you".

>> Le 9 juin 2025 à 12:47, Aditya Garg <gargaditya08@live.com> a écrit :
>>
>> One thing I sometimes encounter is that I sometimes git push -f and moments later I realise I did it at the wrong time, result being a disaster.
> 
> 2 effective habits I like:
> - Check what I’m pushing first.
> - Only force when absolutely needed, and even then default to a
> “strict” version (force-with-lease *and* force-if-includes; I use an
> alias “pf” and some config to make it easy, since I do force-push
> regularly in a rebase-heavy workflow).
> 
> Expanding a bit:
> 
> I have a “git-div” script that will show me the graph in the way I
> like between HEAD and @{push}, or @{upstream} if those are the same
> revision [it accepts arbitrary revisions though]. It was mostly
> inspired by mjd’s git-vee, and uses lots of annotations (cherry-mark,
> left-right, boundary) to give a quick HUD.
> 
> https://github.com/benknoble/Dotfiles/blob/master/links/bin/git-div

> 
> (“graph” is an alias for git-log with the graph and oneline options)
> 
> I also use(d to) use show-branch a lot, and I have aliases sbu =
> show-branch HEAD @{upstream} and sbup = sbu @{push} that I still use
> sometimes.
> 
> As I recently told some colleagues, I consider regularly reviewing
> where in the commit graph I am equally as important as checking
> git-status.
> 
> The second bullet is probably self-explanatory, but the basic idea is
> to give myself the most protection I can, and only weaken it as
> necessary. In fact, I almost never need to remove any of those
> “strict” flags to force-push except when I’m intentionally
> force-pushing from a detached HEAD
> (https://lore.kernel.org/git/CALnO6CCk0SgwObQRnpd5Pt_DvCKF8dBmyVHivU6Nr_O-GusGLA@mail.gmail.com/).
> 
> 
>> I was wondering if a little [y/N] warning could be possible before the risky command gets executed. I saw the code for push superficially and I don't think it's implemented. I think it would be a nice feature though.