Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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

Re: [PATCH 1/2] test-path-utils.c: remove incorrect assumption

On Fri, Oct 9, 2015 at 2:05 AM, Junio C Hamano wrote: > I'll squash this in as part of your first patch that removes the > test from test-path-utils.c. That makes it clearer why it is the > right thing to remove the test, I'd think. > Great, many thanks! > Thanks. > -- To

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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

Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options

Junio C Hamano writes: > Then used_atom[] could become something like > > struct { > const char *str; /* e.g. "align:position=left,32" */ > struct { > const char *part0; /* everything before '=' */ > const char *part1; /* optional

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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

Re: [PATCH] t0027: Improve test for not-normalized files

Torsten Bögershausen writes: This patch is seriously broken and I do not know how you managed to do so. Notice how "+create_NNO_files" is indented but no other added lines in the same hunk, for example. I tried to hand-munge, but gave up. > +commit_chk_wrnNNO () { Squashing

Re: [PATCH 0/1] merge: fix cache_entry use-after-free

David Turner writes: >> > + assert(removed == dir); >> > + drop_ce_ref(dir->ce); >> >> This is curious. In remove_name_hash() you do not have the >> corresponding assert. Why is it necessary here (or is it >> unnecessary over there)? > > It is

Re: [PATCH v2] filter-branch: remove multi-line headers in msg filter

James McCoy venit, vidit, dixit 09.10.2015 02:21: > df062010 (filter-branch: avoid passing commit message through sed) > introduced a regression when filtering commits with multi-line headers, > if the header contains a blank line. An example of this is a gpg-signed > commit: > > $ git

Re: [PATCH 0/1] merge: fix cache_entry use-after-free

+Duy Nguyen, who knows the split index better. On Thu, 2015-10-08 at 13:00 -0700, Junio C Hamano wrote: > David Turner writes: > > > From: Keith McGuigan > > > > During merges, we would previously free entries that we no longer need > > in the

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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

[PATCH v2] t0027: Improve test for not-normalized files

When a text file with mixed line endings is commited into the repo, it is called "not normalized" (or NNO) in t0027. The existing test case using repoMIX did not fully test all combinations: (Especially when core.autocrlf = true) Files with NL are not converted at commit, but at checkout, so a

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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:

Hello

Chevrolet auto mobile company selected your email for the electronic Balloting. 900,000.00 USD was issued to you as winner send name,address and mobile for claim: chev.cla...@yandex.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --

Re: [PATCH v2] filter-branch: remove multi-line headers in msg filter

Michael J Gruber writes: >> Set IFS to an empty string for the “read” call, thus disabling the word >> splitting, which causes $header_line to be set to the non-empty value ' >> '. This allows the loop to fully consume the header lines before >> emitting the original,

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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

Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options

Matthieu Moy writes: > Junio C Hamano writes: > >> Then used_atom[] could become something like >> >> struct { >> const char *str; /* e.g. "align:position=left,32" */ >> struct { >> const char *part0; /* everything

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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,

Re: [PATCH 2/2] pull --rebase: reinstate helpful message on abort

Johannes Schindelin writes: > When calling `git pull --rebase`, things can go wrong. In such a case, > we want to tell the user about the most common ways out of this fix: > ... > builtin/am.c | 1 + > 1 file changed, 1 insertion(+) It is strange to see a patch to

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

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