Hi Junio,
On 2015-10-12 22:28, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>>> I think the most sensible regression fix as the first step at this
>>> point is to call it as a separate process, just like the code calls
>>> "apply" as a separate process for each patch. Optimization can
Johannes Schindelin writes:
>> I think the most sensible regression fix as the first step at this
>> point is to call it as a separate process, just like the code calls
>> "apply" as a separate process for each patch. Optimization can come
>> later when it is shown that it matters---we need to r
Hi Torsten,
On 2015-10-10 18:05, Torsten Bögershausen wrote:
> On 09.10.15 12:11, Johannes Schindelin wrote:
>> Me again,
>>
>> On 2015-10-09 11:50, Johannes Schindelin wrote:
>>>
>>> On 2015-10-09 03:40, Paul Tan wrote:
On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
> Johannes Sc
Hi Junio,
On 2015-10-09 20:55, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> I would prefer the endgame to be an efficient implementation of
> merge_recursive_generic(), a function that you can call without you
> having to worry about it dying.
>
> But the patch in this thread is not that,
Hi Junio,
On 2015-10-09 20:40, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> Instead, stepping back a bit, I wonder if we can extend coverage of
>>> the helpful message to all die() calls when running git-am. We could
>>> just install a die routine with set_die_routine() in builtin/am.c.
On 09.10.15 12:11, Johannes Schindelin wrote:
> Me again,
>
> On 2015-10-09 11:50, Johannes Schindelin wrote:
>>
>> On 2015-10-09 03:40, Paul Tan wrote:
>>> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
Johannes Schindelin writes:
> Brendan Forster noticed that we no longer
On 2015-10-09 12.11, Johannes Schindelin wrote:
> Me again,
>
> On 2015-10-09 11:50, Johannes Schindelin wrote:
>>
>> On 2015-10-09 03:40, Paul Tan wrote:
>>> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
Johannes Schindelin writes:
> Brendan Forster noticed that we no long
Johannes Schindelin writes:
> I finally have that test case working, took way longer than I wanted to:
This certainly fails without any fix and passes either with your
two-patch or a more conservative run_command() fix that I sent
separately.
However, this new test (becomes 5520.20) seems to br
Junio C Hamano writes:
> I think the most sensible regression fix as the first step at this
> point is to call it as a separate process, just like the code calls
> "apply" as a separate process for each patch. Optimization can come
> later when it is shown that it matters---we need to regain
> c
Junio C Hamano writes:
> I looked at the codepath involved, and I do not think that is a
> feasible way forward in this case. It is not about a "helpful
> message" at all. You would have to do everything that is done in
> the error codepath in your custom die routine, which does not make
> much
Junio C Hamano writes:
>> Instead, stepping back a bit, I wonder if we can extend coverage of
>> the helpful message to all die() calls when running git-am. We could
>> just install a die routine with set_die_routine() in builtin/am.c.
>> Then, should die() be called anywhere, the helpful error m
Paul Tan writes:
> That said, I do agree that even if we die(), we could try to be more
> helpful by printing additional helpful instructions.
>
>> If that is the case, I'd thinkg that we'd prefer, as a regression
>> fix to correct "that", i.e., let recursive-merge die and let the
>> caller catch
Me again,
On 2015-10-09 11:50, Johannes Schindelin wrote:
>
> On 2015-10-09 03:40, Paul Tan wrote:
>> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
>>> Johannes Schindelin writes:
>>>
Brendan Forster noticed that we no longer see the helpful message after
a failed `git pull --
Hi Junio & Paul,
On 2015-10-09 03:40, Paul Tan wrote:
> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>
>>> Brendan Forster noticed that we no longer see the helpful message after
>>> a failed `git pull --rebase`. It turns out that the builtin `am` calls
>
On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Brendan Forster noticed that we no longer see the helpful message after
>> a failed `git pull --rebase`. It turns out that the builtin `am` calls
>> the recursive merge function directly, not via a separate p
Johannes Schindelin writes:
> Brendan Forster noticed that we no longer see the helpful message after
> a failed `git pull --rebase`. It turns out that the builtin `am` calls
> the recursive merge function directly, not via a separate process.
>
> But that function was not really safe to be calle
Brendan Forster noticed that we no longer see the helpful message after
a failed `git pull --rebase`. It turns out that the builtin `am` calls
the recursive merge function directly, not via a separate process. But
that function was not really safe to be called that way, as it die()s
pretty liberall
17 matches
Mail list logo