Re: [Qemu-devel] [PATCH] char: Fix removing wrong GSource that be found by fd_in_tag

[Hailiang Zhang <zhang.zhanghailiang@huawei.com>]

On 2017/4/18 21:36, Eric Blake wrote:
> On 04/14/2017 05:10 AM, Marc-André Lureau wrote:
>> Hi
>>
>> ----- Original Message -----
>>> We use fd_in_tag to find a GSource, fd_in_tag is return value of
>>> g_source_attach(GSource *source, GMainContext *context), the return
>>> value is unique only in the same context, so we may get the same
>>> values with different 'context' parameters.
>>>
>>> It is no problem to find the right fd_in_tag by using
>>>   g_main_context_find_source_by_id(GMainContext *context, guint source_id)
>>> while there is only one default main context.
>>>
>>> But colo-compare tries to create/use its own context, and if we pass wrong
>>> 'context' parameter with right fd_in_tag, we will find a wrong GSource
>>> to handle. We tied to fix the related codes in commit b43dec, but it didn't
>> tied->tried
>>
>> Please use a bit longer commit sha1, or full sha1, it will likely conflict otherwise in the future.
> 6 chars is indeed short, 7 is git's default as usually long enough,
> although I've encountered collisions that require 8 chars.  [And google
> has proved that you can have a collision across the entire hash,

Thanks for your explanation.  I didn't notice that before,
I have been always using the 6 chars hash to get the commit ...

> although that is harder to generate.] I generally use 8 or so when
> writing commit messages.  Fortunately, even if a collision is introduces
> later, someone that is motivated enough can still resolve the collision
> by filtering out any collisions that resolve to non-commits, and among
> the remaining colliding SHA1 focus on the one that has a commit date
> which predates the message with the reference.

Agreed, but I'd better to update the comment to make it clearer. thanks.