Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: >> How do things look at this point? This version is what I ended up >> queuing in 'pu', but I took your "Thanks" in $gmane/299120 to only >> mean "Thanks for feeding some ideas to help me move forward", not >> necessarily "Tnanks that looks like the

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

How do things look at this point? This version is what I ended up queuing in 'pu', but I took your "Thanks" in $gmane/299120 to only mean "Thanks for feeding some ideas to help me move forward", not necessarily "Tnanks that looks like the right approach." yet, so right now both topics are

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Junio C Hamano writes: > Subject: [PATCH] merge: avoid "safer crlf" during recording of merge results > ... > We can work this around by not refreshing the new cache entry in > make_cache_entry() called by add_cacheinfo(). After add_cacheinfo() > adds the new entry, we can

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Junio C Hamano writes: > I've tentatively queued the following (it's the same as "Here is > another approach." I sent earlier, but with a real log message) on > 'pu'. And here is yet another approach, which probably is even less intrusive. Whatever alternative we would end

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: > Did that experiment made it to a branch somewhere ? I've tentatively queued the following (it's the same as "Here is another approach." I sent earlier, but with a real log message) on 'pu'. -- >8 -- Subject: [PATCH] merge: avoid "safer crlf" during

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Junio C Hamano writes: > Not yet. As I called it "experiment", it was merely to demonstrate > that there are less intrusive ways to kill the "safer crlf" we may > want to consider first before passing an extra blob object name > around. Here is another approach, that

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: >> 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,

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/08/2016 06:36 PM, Junio C Hamano wrote: Torsten Bögershausen 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

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen 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

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/07/16 20:43, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> This is the call stack: >> >> merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, >>const char *path, int stage, int refresh, int options) >> { >>

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 07/07/16 20:43, Junio C Hamano wrote: Torsten Bögershausen writes: This is the callstack: merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh, int options) { struct cache_entry *ce;

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Junio C Hamano writes: > I am however not convinced passing the full SHA-1 is a good > solution. The make_cache_entry() function may be creating a cache > entry to stuff in a non-default index (i.e. not "the_index"), but > its caller does not have a way to tell it which index

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: > This is the callstack: > > merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, > const char *path, int stage, int refresh, int options) > { > struct cache_entry *ce; > ce = make_cache_entry >

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 2016-07-06 16.57, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> At some point inside the merge, Git calls read-cache.c/ce_compare_data(), >> to check if the path named "file" is clean. >> According to the tree information, the path "file" has the sha1 99b633. >>

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: > At some point inside the merge, Git calls read-cache.c/ce_compare_data(), > to check if the path named "file" is clean. > According to the tree information, the path "file" has the sha1 99b633. > #Note: > #sha1 99b633 is "first line\nsame

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 2016-07-02 00.11, Junio C Hamano wrote: [snip] diff --git a/read-cache.c b/read-cache.c index a3ef967..c109b6d 100644 --- a/read-cache.c +++ b/read-cache.c @@ -163,7 +163,9 @@ static int ce_compare_data(const struct cache_entry *ce, struct stat *st) if (fd >= 0) {

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: >> The checkout process hopefully does not blindly turn LF into CRLF, >> making it "first line \r\r\nsame line\r\rn". Instead the (virtual) >> working tree file will have "first line\r\nsame line\r\n". > Yes >> >> Then "git add" should turn that CRLF

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 29.06.16 18:14, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen >> >> The following didn't work as expected: > > Sorry for being slow (not in response but in understanding), but > let's examine the expectation first. Thanks for the patience.

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

tbo...@web.de writes: > From: Torsten Bögershausen > > The following didn't work as expected: Sorry for being slow (not in response but in understanding), but let's examine the expectation first. > - In a middle of a merge > - merge.renormalize is true, gitattributes(5) tells