All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnav Bhate <bhatearnav@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [GSoC PATCH v2] rm: fix sign comparison warnings
Date: Mon, 17 Mar 2025 22:35:43 +0530	[thread overview]
Message-ID: <741cda93-5dd0-4e7c-9ecf-66af84603cca@gmail.com> (raw)
In-Reply-To: <xmqq1puvbo3s.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

> Arnav Bhate <bhatearnav@gmail.com> writes:
> 
>> -static int get_ours_cache_pos(const char *path, int pos)
>> +static int get_ours_cache_pos(const char *path, unsigned int inverted_pos)
> 
> This renaming of parameter is not right.  
> 
> At this point when the value comes to this function, it *IS* the
> position, there is nothing inverted about it.  It points at the
> position in the .cache[] array where an cache_entry at a higher
> stage would appear.
> 
> It is perfectly fine to state that the value that is returned from
> index_name_pos() is potentially inverted.  The function is given a
> path name (without any stage information) and
> 
>  - returns a non-negative number, the position in the .cache[] array,
>    where a cache_entry at stage #0 (i.e. an entry for a path that does
>    not require conflict resolution), or
> 
>  - returns a negative number, when there is no such cache_entry
>    exists.  The caller can "invert" the value to recover a position
>    in the .cache[] array, where a cache_entry for the path at stage
>    #0 _would_ _have_ been found, if existed.  Due to the way the
>    cache entries are sorted in the .cache[] array, when you are
>    interested in finding cache entries for a path at higher stages,
>    like this function is, you can start scanning at this point until
>    you see an entry for a different path.
> 
> Calling the parameter "pos" is the right thing to do.  The value
> used to come here _could_ have been called "inverted", and the
> result of (-inverted_pos-1) can be assigned to "pos".  But because
> the patch moves the inversion to the caller, what the code in the
> while loop sees is no longer "inverted".

My logic was that it was the inversion of the variable pos, but your
logic makes more sense. I'll make the change.
 
>>  {
>> -	int i = -pos - 1;
>> -
>> -	while ((i < the_repository->index->cache_nr) && !strcmp(the_repository->index->cache[i]->name, path)) {
>> -		if (ce_stage(the_repository->index->cache[i]) == 2)
>> -			return i;
>> -		i++;
>> +	while ((inverted_pos < the_repository->index->cache_nr) && !strcmp(the_repository->index->cache[inverted_pos]->name, path)) {
>> +		if (ce_stage(the_repository->index->cache[inverted_pos]) == 2)
>> +			return inverted_pos;
>> +		inverted_pos++;
>>  	}
>>  	return -1;
>>  }
>> @@ -58,7 +55,7 @@ static void print_error_files(struct string_list *files_list,
>>  			      int *errs)
>>  {
>>  	if (files_list->nr) {
>> -		int i;
>> +		unsigned int i;
>>  		struct strbuf err_msg = STRBUF_INIT;
>>  
>>  		strbuf_addstr(&err_msg, main_msg);
>> @@ -83,7 +80,7 @@ static void submodules_absorb_gitdir_if_needed(void)
>>  
>>  		pos = index_name_pos(the_repository->index, name, strlen(name));
>>  		if (pos < 0) {
> 
> Here is where the caller notices that index_name_pos() did not see a
> stage #0 entry.  This caller wants to see "ours" entry at stage #2,
> so it "inverts" the returned value and asks the helper function if
> it sees such an entry in the .cache[] array.
> 
> A handful of prerequisite pieces of knowledge to understand this
> code are:
> 
>  - The index (i.e. the .cache[] array) is sorted by full path name
>    (down from the top level of the working tree).
> 
>  - The index can have at most one stage #0 entry for each path name.
>    When a stage #0 entry exists for a path name, there cannot be
>    higher stage entries (the path is called "resolved").
> 
>  - The cache entries in the .cache[] array for the same path name
>    are sorted by their stage number.
> 
>  - There can be at most one stage #2 entry for each path name, which
>    are called "ours".  Entries at stage #1 are from common ancestor,
>    entries at stage #3 are from "their" tree.  These higher (i.e.
>    more than zero) stage entries appear only for "conflicting"
>    paths in the .cache[] array.
> 
> With the understanding above, you can see why "our" position is
> computed only when index_name_pos() returns negative in this hunk.

Thanks for the explanation, I was not able to get this from the code.

> 
>> -			pos = get_ours_cache_pos(name, pos);
>> +			pos = get_ours_cache_pos(name, -pos - 1);
>>  			if (pos < 0)
>>  				continue;
>>  		}
>> @@ -131,7 +128,7 @@ static int check_local_mod(struct object_id *head, int index_only)
>>  			 * Skip unmerged entries except for populated submodules
>>  			 * that could lose history when removed.
>>  			 */
>> -			pos = get_ours_cache_pos(name, pos);
>> +			pos = get_ours_cache_pos(name, -pos - 1);
>>  			if (pos < 0)
>>  				continue;
> 
> The above hunks are perfectly fine.  
> 
>> @@ -314,7 +311,7 @@ int cmd_rm(int argc,
>>  	if (pathspec_needs_expanded_index(the_repository->index, &pathspec))
>>  		ensure_full_index(the_repository->index);
>>  
>> -	for (i = 0; i < the_repository->index->cache_nr; i++) {
>> +	for (unsigned int i = 0; i < the_repository->index->cache_nr; i++) {
>>  		const struct cache_entry *ce = the_repository->index->cache[i];
>>  
>>  		if (!include_sparse &&
> 
> OK.
> 
> Thanks.

-- 
Regards,
Arnav Bhate
(He/Him)


  reply	other threads:[~2025-03-17 17:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-12 20:19 [GSoC PATCH] rm: fix sign comparison warnings Arnav Bhate
2025-03-13  7:16 ` Junio C Hamano
2025-03-13 11:25   ` Karthik Nayak
2025-03-13 14:30     ` Arnav Bhate
2025-03-13 14:45       ` Karthik Nayak
2025-03-13 15:25     ` Junio C Hamano
2025-03-13 14:26   ` Arnav Bhate
2025-03-16 10:13 ` [GSoC PATCH v2] " Arnav Bhate
2025-03-17 16:47   ` Junio C Hamano
2025-03-17 17:05     ` Arnav Bhate [this message]
2025-03-17 17:07   ` [GSoC PATCH v3] " Arnav Bhate
2025-03-17 17:12     ` Arnav Bhate
2025-03-17 17:10   ` Arnav Bhate
2025-03-29  6:03     ` [GSoC PATCH v4] " Arnav Bhate
2025-03-29  6:07       ` Arnav Bhate

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=741cda93-5dd0-4e7c-9ecf-66af84603cca@gmail.com \
    --to=bhatearnav@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.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.