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: > > > >> 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. :) OK, I've rebased my patches on top of the current master (which wasn't easy) and sent them to the mailing list [1]. They are pretty hacky, but they show what an actual solution could look like. > > 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? There's no change in the workflow, the user keeps typing the same commands, there's just extra information. But yeah, every branch now has two refs. > > 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. > 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. But I bet you want the simple case of a sequence of commits with no merges to properly detect something. > > 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. :) Sounds like you are talking about the upstream tracking branch [3]. Are you familiar with that? Cheers. [1] https://lore.kernel.org/git/20230310214515.39154-1-felipe.contreras@xxxxxxxxx/ [2] https://stackoverflow.com/a/10821591/10474 [3] https://felipec.wordpress.com/2013/09/01/advanced-git-concepts-the-upstream-tracking-branch/ -- Felipe Contreras
