From: "Antoine Beaupré" <anarcat@debian.org>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH] hooks--pre-push.sample: identify branch point
Date: Sun, 12 Mar 2023 14:14:04 -0400 [thread overview]
Message-ID: <87lek1suqb.fsf@angela.anarc.at> (raw)
In-Reply-To: <CAMP44s30GBC7PFovzgaORMLLGYW=1mFVG4WH-dUfUW5-1sMd1Q@mail.gmail.com>
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.
[...]
>> 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".
a.
--
Science knows still practically nothing about the real nature of
matter, energy, dimension, or time; and even less about those
remarkable things called life and thought. But whatever the meaning
and purpose of this universe, you are a legitimate part of it.
- Gene Roddenberry
next prev parent reply other threads:[~2023-03-12 18:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 22:04 [RFC PATCH] hooks--pre-push.sample: identify branch point Antoine Beaupré
2023-03-09 23:22 ` Felipe Contreras
2023-03-10 16:28 ` Antoine Beaupré
2023-03-10 22:09 ` Felipe Contreras
2023-03-12 18:14 ` Antoine Beaupré [this message]
2023-03-16 17:32 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lek1suqb.fsf@angela.anarc.at \
--to=anarcat@debian.org \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox