2009/5/20 Johannes Schindelin <Johannes.Schindelin@xxxxxx>:
> On Mon, 11 May 2009, Alex Riesen wrote:
>
>> Some path names which transitioned from file to a directory were not
>> updated in the final part of the merge (loop around unmerged entries in
>> merge_trees), because the branch in process_renames which filtered out
>> updates for the files with the same content ("merged same as existing")
>> has left the rename entry in processed state. In this case, the
>> processing cannot be finished at the process_renames phase (because
>> the old file still blocks creation of directory where new files should
>> appear), and must be postponed until the update_entry phase.
>
> I know that as a German, I am supposed to like long sentences and crowded
> paragraphs. Maybe I am not that German after all.
>
Will be shortened.
>> diff --git a/merge-recursive.c b/merge-recursive.c
>> index a3721ef..3c5420b 100644
>> --- a/merge-recursive.c
>> +++ b/merge-recursive.c
>> @@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,
>>
>> if (mfi.clean &&
>> sha_eq(mfi.sha, ren1->pair->two->sha1) &&
>> - mfi.mode == ren1->pair->two->mode)
>> + mfi.mode == ren1->pair->two->mode) {
>> /*
>> * This messaged is part of
>> * t6022 test. If you change
>> * it update the test too.
>> */
>> output(o, 3, "Skipped %s (merged same as existing)", ren1_dst);
>> - else {
>> + ren1->dst_entry->processed = 0;
>> + } else {
>
> So basically, you say that a dst_entry has not been processed, when it
> _has_ been? That cannot be correct...
>
My feeling exactly. I'm afraid I just zeroed the effect of the branch
which should avoid rewriting of files with known same content.
It's just that the code has grown a little confusing...
I'm still thinking about how to avoid unneeded rewrites of the files
with same content under same name.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html