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
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 warn
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 unnecessary in any case: it's an
+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 destination index. But those entries might also be
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 warn into wrn or
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
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 am that does not talk anything
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 before '=' */
>> const char *part1; /*
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
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, intact commit message.
>>
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
--
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 unsubscribe from this
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
>
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 */
> } *modifi
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 cat-file
19 matches
Mail list logo
