Re: Ambiguous sha-1 during a rebase

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

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
> Mike Hommey <mh@xxxxxxxxxxxx> writes:
> 
> > Yeah, that definitely is a weird corner case. Interestingly, it was
> > complaining about "error: short SHA1 e34ff55 is ambiguous." when apply
> > *other* commits that were in the list prior to it,
> 
> I think it did before: when normalizing the list to long sha1, i.e.
> right after you closed your editor and befor starting anything else.

In that case, I'm surprised that the rebase didn't stop before doing
any action.

I am guessing that the "error: short SHA1 e34ff55 is ambiguous." is
comming from either 'check_commit_sha' called by 'check_todo_list' or
by 'transform_todo_ids' called by 'expand_todo_ids'.

If my guess is correct {

 - If the former, it means that 'check_commit_sha' is not doing its
   job properly (it did not return an error code, which would have
   triggered a 'die' later and stopped the rebase at the beginning).

 - If the latter, it means that 'check_commit_sha' and
   'check_todo_list' missed an occasion to error out.

}

On a side note, is there a way to test for ambiguous SHA1?

Thanks,
Rémi
--
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]