On Sun, Mar 12, 2023 at 12:14 PM Antoine Beaupré <anarcat@xxxxxxxxxx> wrote:
>
> On 2023-03-10 16:09:43, Felipe Contreras wrote:
> > On Fri, Mar 10, 2023 at 10:28 AM Antoine Beaupré <anarcat@xxxxxxxxxx> 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@xxxxxxxxxx> 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.
> >> 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
