Re: [PATCH v3 6/7] doc: add reference for "--[no-]force-if-includes"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio,

On 09/14/2020 14:01, Junio C Hamano wrote:
> Srinidhi Kaushik <shrinidhi.kaushik@xxxxxxxxx> writes:
> 
> > diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> > index 3b8053447e..b40fe7e7cf 100644
> > --- a/Documentation/git-push.txt
> > +++ b/Documentation/git-push.txt
> > @@ -320,6 +320,12 @@ seen and are willing to overwrite, then rewrite history, and finally
> >  force push changes to `master` if the remote version is still at
> >  `base`, regardless of what your local `remotes/origin/master` has been
> >  updated to in the background.
> > ++
> > +Alternatively, specifying `--force-if-includes` an an ancillary option along
> > +with `--force-with-lease[=<refname>[:expect]]` (when "<refname>" or "<expect>"
> > +values are unspecified) at the time of `push` will verify if updates from the
> > +remote-tracking refs that may have been implicitly updated in the background
> > +are integrated locally before allowing a forced update.
> 
> You cannot omit <refname> without omitting <expect>, so
> 
> 	... with "--force-with-lease[=<refname>]" (i.e. without
> 	saying what exact commit the ref on the remote side must be
> 	pointing at, or which refs on the remote side are being
> 	protected) at the time of ...
> 
> would be more appropriate.

OK, that makes sense, will update.
 
> > +--[no-]force-if-includes::
> > +	Force an update only if the tip of the remote-tracking ref
> > +	has been integrated locally.
> > ++
> > +This option verifies if the tip of the remote-tracking ref on which
> > +a local branch has based on (for a rewrite), is reachable from at
> > +least one of the `reflog` entries of the local branch about to be
> 
> If we take the "we don't have to look at a local branch's reflog;
> just check HEAD's and rebase will automatically be handled without
> expensive merge-base" approach, then
> 
>     ... if the tip of the remote-tracking ref was once checked out
>     to the working tree (for a rewrite) by seeing if it appears in
>     the reflog of "HEAD" ...
> 

Right, as mentioned in the other thread, we can go with this route,
will change in the next series.

Thanks.
-- 
Srinidhi Kaushik



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux