Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.

> I however think what Pierre wanted to do is different, and you do not have
> to solve "force this strict rewind" problem to solve it.
> 
> What we need is (with a configuration option) to change the meaning of
> "matching refs" from the current definition "branches with the same name
> between here and there" to "branches with the same name between here and
> there, but excluding the ones that do not fast forward (or strictly
> behind)".  So if you have tons of stale branches you checked out but
> haven't touched most of them, your "matching push" won't even try to push
> what you haven't touched.
> 
> I do not think we would ever want to allow a configuration that disables
> the exit status from push upon a push failure when somebody explicitly
> says "git push $there $this" and $this is not non-fast-forward.  If you
> asked $this to be pushed, and if $this cannot be pushed, we _should_ error
> out.
>
> So...
> 
>  (1) when you say "git push" to trigger the "matching refs" push, with the
>      new configuration, you do not error out nor even try to push out
>      things that do not fast forward.  Pretend that you did not even
>      attempt to push them, and do not error out.  This may result in not
>      pushing anything out, but that is what the people who have such a
>      configuration is asking for.
> 
>      If you have configured which branches are pushed when you are on your
>      current branch, and that branch --- most likely it is that current
>      branch --- does not fast forward, it is your problem.
> 
>  (2) even with such a configuration, you can "git push $there $this" and
>      "git push $there +$this" to explicitly ask refs to be pushed.  Such a
>      push won't be interfered by the new configuration and correctly fail
>      (or force).