"Alex Riesen" <raa.lkml@xxxxxxxxx> writes: > ...otherwise it not clear what happened when update-ref fails. > > E.g., git checkout -b a/b/c HEAD would print nothing if refs/heads/a > exists and is a directory (it does return 1, so scripts checking for > return code should be ok). > > I'm attaching two patches, because I'm not quite sure where it should > be done: git-checkout is the least intrusive, but only builtin-update-ref.c > has enough info to help user to resolve the problem (errno is ENOTDIR, > which is selfexplanatory). And I happen to use git-update-ref directly > sometimes. My gut feeling is that complaining from update-ref is fine, but I am still tired after a long week and not thinking straight, so I will not be applying this tonight. git-applypatch, git-am, and git-branch would be helped by update-ref complaining. Porcelains? BTW, I wonder what happens when .git/logs/refs/a is a directory (by mistake or malice), .git/refs/a does not exist, and the user does "git checkout -b a/b/c HEAD". Or when .git/logs/refs/a/b/c does exist but is not writable. My preference is just warn but do not interrupt the primary operation, since ref-log is just an optional part of the system, but that would probably lead to confusion, so we might be better off erroring the caller out in such a case. Opinions? git-resolve does not check exit value from update-ref, which is *BAD*, but we should be deprecating it anyway. git-reset has the same problem of not checking the exit status from update ref. Worse yet, it calls update-ref with wrong parameter ($@ in its parameter should be $*). Patches to fix these two and half problems should be trivial but I won't be doing that myself tonight. - : 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