Michael J Gruber writes:
> It seems the consensus was that current functionality is as designed but
> not necessarily as expected, and another mode "--fork-base" (that does
> what I suggested as "fix") would meet these expectations. I would reuse
> the documentation of the current mode as a descr
Ekelhart Jakob venit, vidit, dixit 08.11.2017 09:52:
> 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 Jako
* [mailto:gits...@pobox.com]
Sent: Dienstag, 3. Oktober 2017 08:06
To: Michael J Gruber
Cc: git@vger.kernel.org; Ekelhart Jakob ; Jeff King
; Johannes Schindelin
Subject: Re: [PATCH 2/3] merge-base: return fork-point outside reflog
Junio C Hamano writes:
> Michael J Gruber writes:
>
>&g
Junio C Hamano writes:
> Michael J Gruber 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"?
>> -
Michael J Gruber 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
Junio C Hamano venit, vidit, dixit 22.09.2017 03:49:
> Michael J Gruber writes:
>
>> Also, I'm undecided about about your reflog argument above - if we leave
>> "--fork-point" to be the current behaviour including Jeff's fix then the
>> documentation would need an even bigger overhaul, because it
Michael J Gruber writes:
> Also, I'm undecided about about your reflog argument above - if we leave
> "--fork-point" to be the current behaviour including Jeff's fix then the
> documentation would need an even bigger overhaul, because it's neither
> "reflog also" (as claimed in the doc) nor "refl
Junio C Hamano venit, vidit, dixit 21.09.2017 08:27:
> Junio C Hamano writes:
>
>> ... I agree that there is a value in what your patch 2/3
>> wants to do when the current one that is more strict would say
>> "there is no known fork-point"---we would gain a way to say "... but
>> this is the bes
Junio C Hamano writes:
> ... I agree that there is a value in what your patch 2/3
> wants to do when the current one that is more strict would say
> "there is no known fork-point"---we would gain a way to say "... but
> this is the best guess based on available data that may be better
> than get
Michael J Gruber writes:
> I did not look up the discussion preceeding 4f21454b55 ("merge-base:
> handle --fork-point without reflog", 2016-10-12), but if "merge-base
> --fork-point" were about a "strict reflog" notion then there was nothing
> to fix back then - no reflog, no merge-base candidate
Junio C Hamano venit, vidit, dixit 15.09.2017 04:48:
> Michael J Gruber writes:
>
>> In fact, per documentation "--fork-point" looks at the reflog in
>> addition to doing the usual walk from the tip. The original design
>> description in d96855ff51 ("merge-base: teach "--fork-point" mode",
>> 201
On 15/09/17 03:48, Junio C Hamano wrote:
>
> Michael J Gruber writes:
>
>> In fact, per documentation "--fork-point" looks at the reflog in
>> addition to doing the usual walk from the tip. The original design
>> description in d96855ff51 ("merge-base: teach "--fork-point" mode",
>> 2013-10-23)
Michael J Gruber writes:
> In fact, per documentation "--fork-point" looks at the reflog in
> addition to doing the usual walk from the tip. The original design
> description in d96855ff51 ("merge-base: teach "--fork-point" mode",
> 2013-10-23) describes this as computing from a virtual merge-bas
13 matches
Mail list logo
