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 right approach."
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 stalle
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 call refresh_cache_ent
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 up picking, in the lo
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 recording of me
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 probably is less intrusive.
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, const
>> unsigned
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 touches code where I
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 comment on details.
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)
>> {
>>struct cache_entry *
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;
ce = ma
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 the resulting
> cac
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
> if (!ce)
>
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.
>> #Note:
>> #
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 line\n"
I thought
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) {
uns
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 into LF, which
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.
There is one detail
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 us that this wo
From: Torsten Bögershausen
The following didn't work as expected:
- In a middle of a merge
- merge.renormalize is true,
- .gitattributes = "* text=auto"
- core.eol = crlf
Merge a blob with CRLF "first line\r\nsame line\r\n" and a blob
with LF "first line\nsame line\n".
The expected result
20 matches
Mail list logo
