Junio C Hamano wrote: > Brandon Casey <casey@xxxxxxxxxxxxxxx> writes: > >> Signed-off-by: Brandon Casey <casey@xxxxxxxxxxxxxxx> >> --- >> >> >> Sometimes the repository to link to is not under your control. >> If it contains files or unreadable directories, git-relink will >> die without this patch. > > I am not so sure if dying is a bad behaviour, if it is because > you are trying to link against an object store that you may not > be able to read. I actually think we should actively refuse to, > in order to prevent future problems. After seeing the command > die, you will talk to the owner of that "master" object store > and ask him to fix permissions (or he may choose to say "please > do not share with me"). The case for me was that the objects directory contained temporary pack files. This is a perfectly valid state for a git repository, but relink() currently aborts the whole effort when it encounters a non-directory. Stale tmp packs can remain if the user aborted a git command before it was finished. (hmm, maybe git-gc --prune could remove these too?) I only mentioned the unreadable directory case as another possibility. You're probably right about that one. -brandon - 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
