Junio C Hamano wrote:
quoted text
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>> ---
>>
>>
>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html