On Tue, Jan 13, 2015 at 11:54:32AM +0100, Henning Moll wrote:
> . error: short SHA1 c4095c1 is ambiguous.
> . fatal: Needed a single revision
> . Invalid commit name: c4095c1
>
> Now that the command failed, i checked for ambigous c4095c1. But there is only one:
> $ git log -1 c4095c1
> . commit c4095c1f5e7c126accf93ba68e2fa72bb055f567
> . ...
>
> Just as a test:
> $ git log -1 c409
> . error: short SHA1 c409 is ambiguous.
> . error: short SHA1 c409 is ambiguous.
Hmm. There are some instances in git where we know we are looking for an
object of a particular type, and we can disambiguate a short-sha1 based
on the type. And "git log" is just such a place, whereas a generic "git
rev-parse" used by the git-rebase script would not be.
Try:
git rev-list --objects --all |
grep ^c4095c1 |
cut -d' ' -f1 |
git cat-file --batch-check
If my hunch is right, then you may find multiple objects, only one of
which is a commit.
And if so, the solution is likely one of:
1. Teach rev-parse a "prefer committish" option and use it in the
appropriate spot in git-rebase.
2. Teach whatever is generating the shortended sha1s to report a truly
unambiguous result, not one that depends on the type. I don't think
we _have_ a codepath to do type-dependent shortening, though, which
is maybe an indication that this is a red herring.
It's also possible that part of the rebase sequence generates a new
object that creates the ambiguity. That would be consistent with your
statement that rolling back and running the commands again makes it
work. I'm not sure how to defend against that, aside from adding a
character or two to the shortened ids, which reduces the likelihood of a
collision.
-Peff
--
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