Re: [RFC PATCH] hooks--pre-push.sample: identify branch point

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Mar 16, 2023, 17:32 UTC
Message-ID: <CAMP44s12i0nzSKd4reJf_51=BgrGVD3xpsDzYHGJOO11FcvjCA@mail.gmail.com>
In-Reply-To: <87lek1suqb.fsf@angela.anarc.at>

On Sun, Mar 12, 2023 at 12:14 PM Antoine Beaupré <anarcat@debian.org> wrote:

Show 41 quoted lines

>
> On 2023-03-10 16:09:43, Felipe Contreras wrote:
> > On Fri, Mar 10, 2023 at 10:28 AM Antoine Beaupré <anarcat@debian.org> wrote:
> >>
> >> On 2023-03-09 17:22:55, Felipe Contreras wrote:
> >> > Hi Antoine,
> >> >
> >> > On Thu, Mar 9, 2023 at 4:34 PM Antoine Beaupré <anarcat@debian.org> wrote:
> >> >
>
> [...]
>
> >> > It's interesting how we keep coming back to the same problems; right
> >> > now there's a discussion in the git-users mailing list precisely about
> >> > the same topic: how to find the branch point, in particular so `git
> >> > name-rev` shows the correct branch a commit belongs to (which is
> >> > otherwise just a bad guess).
> >>
> >> Well, it's a need people certainly seem to have. :)
> >>
> >> I feel we are letting perfection be the enemy of good here. No, there
> >> are no solutions that work for the general case, you always find a
> >> corner case that breaks it. But what if we could have a simple solution
> >> that works for *most* cases and then *fails* gracefully for the corner
> >> cases?
> >
> > I did propose such a solution, I wrote extensive tests to make sure it
> > worked properly, but it was largely ignored [2].
> >
> > The solution with --exclude-first-parent-only fails my tests in a very
> > complex case:
> >
> >    X (master)
> >     \
> >      A (topic)
> >
> > Sure, it's probably easy to fix, but the point is that a reliable and
> > robust solution everyone agrees with doesn't exist.
>
> Hm... that's odd, I'm surprised that doesn't work. But that's certainly
> a "special" (!) case that should be handled properly.

That's because the command wasn't meant to be called from a script, but by a human who knows what he is doing.

To make it into a command that "just works" regardless of the situation some work would be needed to make sure it works in all the cases people have already debated.

My command just works, I would be willing to do the work of investigating if --exclude-first-parent-only could be used instead, but it's not very tempting to do that work again if it's going to be ignored again.

Show 10 quoted lines

> >> Or they could even have a per-branch .git/config entry to map the branch
> >> to an upstream branch, and *that* could even "default" to "main" or
> >> whatever that setting is called now. :)
> >
> > Sounds like you are talking about the upstream tracking branch [3].
> > Are you familiar with that?
>
> No, I'm not refering to branch.NAME.upstream here, sorry if my use of
> "upstream" here was confusing. I mean "the branch this branch has been
> forked from" not "the upstream equivalent to this local branch".

Unfortunately Git conflates two different concepts into @{upstream}: the branch we want to rebase to, and the branch we want to be merged to. By "upstream" I meant the upstream tracking branch when it's configured to the branch we want to rebase to. For example:

  git switch --create topic --track master

In this case topic@{u} is the branch that we forked from.

In my fork of git I de-conflate these two concepts, which are clearly different: @{upstream} versus @{publish}.

In my personal workflow @{upstream} is *always* the branch I forked from, and I want to rebase to, and when it's not configured "master" is a safe default.

Because it's tedious to do this check every time, I have a script to basically do:

  local u="${branch}@{u}"
  git rev-parse --verify --quiet "$u" || u=master
  echo "${u}..$branch"

It would be nice if git supported @{upstream|default} or even better: @{base}.

Cheers.

-- 
Felipe Contreras