All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <johannes.schindelin@gmx.de>
To: Paul Tan <pyokagan@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Brendan Forster <shiftkey@github.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails
Date: Fri, 09 Oct 2015 11:50:29 +0200	[thread overview]
Message-ID: <4a99ca8724b3604cbbec48d559e134fd@dscho.org> (raw)
In-Reply-To: <CACRoPnSPVMt+FtK6bwfa7Z3jBheTEkBnhU+B7qL8JrAsSmAmkQ@mail.gmail.com>

Hi Junio & Paul,

On 2015-10-09 03:40, Paul Tan wrote:
> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Johannes Schindelin <johannes.schindelin@gmx.de> 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 called that way, as it
>>> die()s pretty liberally.
> 
> I'm not too familiar with the merge-recursive.c code, but I was under
> the impression that it only called die() under fatal conditions. In
> common use cases, such as merge conflicts, it just errors out and the
> helpful error message does get printed. Is there a reproduction recipe
> for this?

Yes. Sorry, I should have added that as part of the patch series. Actually, I should have written it *before* making those patches. Because it revealed that the underlying problem is completely different: *Normally* you are correct, if `pull --rebase` fails with a merge conflict, the advice is shown.

The problem occurs with CR/LF.

I have a reproducer and will wiggle it down to a proper test case.

>> 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 its exit status.
> 
> We could do that, but I don't think it would be worth the overhead to
> spawn an additional process for every patch just to print an
> additional message should merge_recursive() call die().

I would hope that we do not go that direction! The benefit of making `am` a builtin was to *avoid* spawning, after all. Let's not make the experience for Windows users *worse* again.

> 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 message will
> be printed as well. fast-import.c and http-backend.c seem to do this.

This looks more like a work-around to me. In general, I think it is not really a good idea to treat each and every code path as if it is safe to die(). That would just preclude the code from being used as a library function.

But it looks more and more as if the problem lies with the CR/LF handling of Git. Will keep you posted.

Ciao,
Dscho

  reply	other threads:[~2015-10-09  9:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-08 20:35 [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails Johannes Schindelin
2015-10-08 20:35 ` [PATCH 1/2] merge_recursive_options: introduce the "gentle" flag Johannes Schindelin
2015-10-08 20:35 ` [PATCH 2/2] pull --rebase: reinstate helpful message on abort Johannes Schindelin
2015-10-09 18:36   ` Junio C Hamano
2015-10-12  9:16     ` Johannes Schindelin
2015-10-12 20:33       ` Junio C Hamano
2015-10-09  0:52 ` [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails Junio C Hamano
2015-10-09  1:40   ` Paul Tan
2015-10-09  9:50     ` Johannes Schindelin [this message]
2015-10-09 10:11       ` Johannes Schindelin
2015-10-09 20:49         ` Junio C Hamano
2015-10-10  4:58         ` Torsten Bögershausen
2015-10-10 16:05         ` Torsten Bögershausen
2015-10-12 10:45           ` Johannes Schindelin
2015-10-09 18:15     ` Junio C Hamano
2015-10-09 18:40       ` Junio C Hamano
2015-10-09 18:55         ` Junio C Hamano
2015-10-12  9:46           ` Johannes Schindelin
2015-10-09 20:46         ` Junio C Hamano
2015-10-12  9:40         ` Johannes Schindelin
2015-10-12 20:28           ` Junio C Hamano
2015-10-13 11:48             ` Johannes Schindelin

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=4a99ca8724b3604cbbec48d559e134fd@dscho.org \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pyokagan@gmail.com \
    --cc=shiftkey@github.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.