From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, tboegi@web.de
Subject: Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge
Date: Fri, 8 Jul 2016 19:13:40 +0200 [thread overview]
Message-ID: <f78fa94d-abd2-05a2-c411-15e2ffdb7dae@web.de> (raw)
In-Reply-To: <xmqqmvlsm6hu.fsf@gitster.mtv.corp.google.com>
On 07/08/2016 06:36 PM, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
>>> I dunno. I really do not like that extra sha1 argument added all
>>> over the callchain by this patch.
>>>
>>> Or did you mean other calls to add_cacheinfo()?
>>
>> I didn't mean too much - the whole call chain touches code where I
>> am not able to comment on details.
>> I'm happy to test other implementations, if someone suggests a
>> path, so to say.
>
> I did a bit of experiment.
>
> When 1/3 alone is applied, and then only changes for t/t6038 from
> 3/3 is picked, (i.e. we do not add the extra "don't look at index,
> check this contents"), your "Merge addition of text=auto eol=CRLF"
> test would fail.
>
> And then with this further on top:
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index b880ae5..628c8ed 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -202,6 +202,9 @@ static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
> const char *path, int stage, int refresh, int options)
> {
> struct cache_entry *ce;
> +
> + if (!stage)
> + remove_file_from_cache(path);
> ce = make_cache_entry(mode, sha1 ? sha1 : null_sha1, path, stage,
> (refresh ? (CE_MATCH_REFRESH |
> CE_MATCH_IGNORE_MISSING) : 0 ));
>
Thanks :-)
Did that experiment made it to a branch somewhere ?
next prev parent reply other threads:[~2016-07-08 17:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 23:21 What's cooking in git.git (Jun 2016, #09; Mon, 27) Junio C Hamano
2016-06-28 8:01 ` [PATCH v3 0/3] unified auto CRLF handling, V3 tboegi
2016-06-28 8:01 ` [PATCH v3 1/3] convert: unify the "auto" handling of CRLF tboegi
2016-06-28 8:01 ` [PATCH v3 2/3] read-cache: factor out get_sha1_from_index() helper tboegi
2016-06-28 8:01 ` [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge tboegi
2016-06-29 16:14 ` Junio C Hamano
2016-06-30 16:52 ` Torsten Bögershausen
2016-07-01 22:11 ` Junio C Hamano
2016-07-02 18:41 ` Torsten Bögershausen
2016-07-06 14:57 ` Junio C Hamano
2016-07-07 17:16 ` Torsten Bögershausen
2016-07-07 18:43 ` Junio C Hamano
2016-07-07 22:19 ` Junio C Hamano
2016-07-08 7:52 ` Torsten Bögershausen
2016-07-08 16:36 ` Junio C Hamano
2016-07-08 17:13 ` Torsten Bögershausen [this message]
2016-07-08 17:25 ` Junio C Hamano
2016-07-08 17:59 ` Junio C Hamano
2016-07-08 19:01 ` Junio C Hamano
2016-07-08 20:50 ` Junio C Hamano
2016-07-11 20:07 ` Junio C Hamano
2016-07-12 2:23 ` Torsten Bögershausen
2016-07-12 19:54 ` Junio C Hamano
2016-07-08 15:00 ` Torsten Bögershausen
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=f78fa94d-abd2-05a2-c411-15e2ffdb7dae@web.de \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.