Re: [PATCH 2/2] Loop index increases monotonically when reading unmerged entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think this line is dangerous, if add_cache_entry is not able to
remove higher-stages it will be looping forever, as happens in the
case of this thread.
I cannot see why it's even needed, and removing it doesn't break any test.

On Sun, Aug 24, 2014 at 7:57 PM, Jaime Soriano Pastor
<jsorianopastor@xxxxxxxxx> wrote:
> Signed-off-by: Jaime Soriano Pastor <jsorianopastor@xxxxxxxxx>
> ---
>  read-cache.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index c1a9619..3d70386 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1971,7 +1971,6 @@ int read_index_unmerged(struct index_state *istate)
>                 if (add_index_entry(istate, new_ce, 0))
>                         return error("%s: cannot drop to stage #0",
>                                      new_ce->name);
> -               i = index_name_pos(istate, new_ce->name, len);
>         }
>         return unmerged;
>  }
> --
> 2.0.4.1.g0b8a4f9.dirty
>
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]