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

From: Antoine Beaupré <anarcat@debian.org>
Date: Mar 10, 2023, 16:28 UTC
Message-ID: <87356ctvta.fsf@angela.anarc.at>
In-Reply-To: <CAMP44s2=qzmF1Odc_auCaKQmTBYD53YYtaJv_LGwvoFDmTxPSA@mail.gmail.com>

On 2023-03-09 17:22:55, Felipe Contreras wrote:

Show 20 quoted lines

> Hi Antoine,
>
> On Thu, Mar 9, 2023 at 4:34 PM Antoine Beaupré <anarcat@debian.org> wrote:
>
>> https://stackoverflow.com/a/71193866/1174784
>>
>> There are currently a whopping twenty-five answers to that question in
>> that thread, and I'm hoping the community here will have a more
>> definitive answer to this question. I have picked the answer that uses
>> the least possible external commands, but it still uses a `tail -1`
>> which I'm somewhat unhappy about. I have thought of using
>> `--max-count` for this instead, but I understand that probably does
>> the equivalent of a `head -n` *and* it's applied before `--reverse`,
>> so there's not other way to do this.
>
> I spent an inordinate amount of time trying to answer that question a
> decade ago, and my conclusion after trying every possible combination
> is that it's simply not possible. Every solution at the end of the day
> will be a hack that can be broken with a corner case. It has already
> been discussed in this mailing list [1], and nobody found a solution.

That's what I have gathered from reading through that Stack Overflow thread as well.

> That's why I wrote a patch to implement a branch@{tail} helper to show
> an auxiliary ref to the beginning of the branch. I don't think I ever
> sent it to the mailing list, as my patches are rarely merged, but I'm
> sure I have it somewhere.

That would be interesting for the world to see, I bet, if only as a future reference to avoid other people trying to bang their head on the problem the same way. :)

> The other solution I thought of was adding an update-branch hook that
> could be run every time a branch is updated, and then the hook would
> update the branch tail reference [2]. As expected, that patch wasn't
> merged either.

That seems like a major change in workflow though, adding basically a new ref for each branch, right?

Show 5 quoted lines

> 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?

In the case of the pre-push hook, specifically, we don't absolutely need something completely rock solid; if your branches are a mess of merges and cherry-picks and cross merges, yes, it might get confused but it's not like it's going to lose a commit or something. The worse case is that it's going to miss *checking* a commit and for this case it's not satisfying, but it's also not data loss.

Show 6 quoted lines

> FWIW my motivation at the time was to prove Mercurial users wrong
> regarding features that they have and Git doesn't, I contended that
> Mercurial named branches (aka commit labels) were not necessary, and
> everything they achieved could be achieved in Git through different
> means. That turned out to be untrue, as there is one thing Mercurial
> can do that Git can't: show the precise point a branch started from.

I have given up on Mercurial a long, long time ago. It's extremely rare that I find myself in such a situation and typically, there various hacks that answer the need without going into too much complexity.

The only reason I raise the issue here is because I wasn't satisfied hardcoding "master" (or main, for that matter) in the hook because I wanted a more generic answer. I suspect many people could be perfectly fine with hardcoding that in their hook or, failing that, with the incomplete heuristic I am proposing.

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. :)

A.