Thank you for all the effort to fix this issue. Unfortunately, we are still suffering from this and our workaround just stopped being sufficient.
We were wondering if there is any way to tell when this fix will be released? BR Jakob -----Original Message----- From: Junio C Hamano *EXTERN* [mailto:gits...@pobox.com] Sent: Dienstag, 3. Oktober 2017 08:06 To: Michael J Gruber <g...@grubix.eu> Cc: git@vger.kernel.org; Ekelhart Jakob <jakob.ekelh...@fsw.at>; Jeff King <p...@peff.net>; Johannes Schindelin <johannes.schinde...@gmx.de> Subject: Re: [PATCH 2/3] merge-base: return fork-point outside reflog Junio C Hamano <gits...@pobox.com> writes: > Michael J Gruber <g...@grubix.eu> writes: > >> I'm still trying to understand what the original intent was: If we >> abstract from the implementation (as we should, as you rightly >> emphasize) and talk about historical tips then we have to ask ourselves: >> - What is "historical"? >> - What is tip? >> - Tip of what, i.e. what is a "branch"? > > The feature was meant to be a solution for "upstream rebased the > branch I based my work on." > ... So, what is the status of this thing? While I think 1/3 and 3/3 of these three definitely make sense, I do not think "fork-point outside reflog" does as-is If it is not even part of the commits that were known to be at the tip some time in the past (including "right now"---which is the fix you made with 3/3 is about), then the patch may make the command return something in more situations, and these extra things that it returns might even be improvements, but they are definitely not "fork-points". To be quite honest, I am not convinced that the extra output you would get out of the command by removing the latter half of "which are the ancestors that were known to be at the tip?" would always give better commit to use as the beginning of the topic to be rebased, as I do not see any reasoning behind why, unlike the filtered case where there _is_ a strong reasoning (with explained limitation) behind it. As long as the code misidentifies and picks a commits deeper than necessary, which will force the user to say "rebase --skip", I think we are OK. What we want to absolutely avoid is the opposite; somehow the code misidentifies a commit that is part of the work you want to rebase as a recommended fork-point, which would cause the rebase to silently lose changes. I do not think I saw why it won't happen explained in the log message of 2/3 at all.
