Re: [PATCH 0/2] tagsize < 8kb restriction

Björn Engelmann [off-list ref] writes:

I am currently wondering where to store the reference to such a
sub-repository. It certainly is a head, but I would like to avoid anyone
commiting code into this "branch". Maybe I will create a new directory
.git/refs/annotations.

I would recommend against that.  Why shouldn't it be an ordinary
branch that is different from the default "master"?

If you are in a shared repository settings, then update hook is
there for you to prevent people who do not have any business
touching that branch head from mucking with it.

I am not sure how git would perform in such an environment. Do you think
the "git-push"-implementation is sufficiently "thread-save" for this ?

Yes.

And I do not necessarily think your workflow would want to have
such "an empty file works as a lock" convention.

Just do things locklessly.  If two people in the group happened
to do duplicated work, the first push would succeed and the
second person would be prevented from pushing (and suggested to
merge in the work first).  When the second person pulls, he
would realize the scan result by the first person is already
there.  If that is considered to be too much wasted work, then
it means your distributed workflow did not have sufficient
communication among people.  Being able to work distributed does
not mean you need no coordination, and a distributed SCM is not
a substitute for comminication among paticipants.

1.) Do you intend to add some more advanced metadata-functionality to
git in the future or should I send a patch with my implementation once
it is finished ? Will be just some scripts using similar commands to
what Linus sent me (thanks for that, btw)

Neither, until/unless we have a clear design.

I think the annotation branch (or a separate repository) is a
very natural consequence of what the tool already give you, and
the tools work just fine as they are.  There is nothing
innovative in what I suggested above nor Linus outlined in the
other message.

If you are talking about an application that builds on top of
git to do issue management (or QA or whatever), that uses
metadata linked to the commits on the main development branch,
that would be a wonderful system, but that does not necessarily
have to come with git (it's just an application on top of git,
and the workflow of your organization may or may not match other
people's workflow).

2.) Searching for a way to add objects to the database I spent quite a
while to find the right command. Don't you think it would be much more
intuitive having an

    git-create-object [-t <type>] [-n] [-f] [-z] [--stdin] <file> [-r
<ref-name>]

command for creating any type of object (-t blob as default).

No, I do not think we would want to make it too easy and relaxed
to create arbitrary object-looking thing.  Each type have
defined format and semantics, and creation of an object of each
type should be validated.  I do not want to encourage bypassing
it by introducing such a backdoor.  The backdoor is easy to
write, but I suspect it would actively harm us, instead of
helping us, by encouraging "let's build a custom type of object,
we do not care if other people would not understand it"
mentality.

quoted

2.) Searching for a way to add objects to the database I spent quite a
while to find the right command. Don't you think it would be much more
intuitive having an

    git-create-object [-t <type>] [-n] [-f] [-z] [--stdin] <file> [-r
<ref-name>]

command for creating any type of object (-t blob as default).
    

No, I do not think we would want to make it too easy and relaxed
to create arbitrary object-looking thing.  Each type have
defined format and semantics, and creation of an object of each
type should be validated.  I do not want to encourage bypassing
it by introducing such a backdoor.  The backdoor is easy to
write, but I suspect it would actively harm us, instead of
helping us, by encouraging "let's build a custom type of object,
we do not care if other people would not understand it"
mentality.
  

Well, this is exactly what you have now in
    git-hash-object -w -t foo

That is why I said, all input should be validated by default. All I
proposed was
a) unify the tools in order to have less duplicate code (git-mktag,
git-mktree & git-hash-object do merely the same except for the
validating part)
b) remove the possibility to introduce unchecked objects of arbitrary
type (or only allow it with the -f = "force, use with caution"-option)

maybe I should have written "blob, tag, tree or commit" instead of
"arbitrary". I did not mean really arbitrary like it is implemented
right now in git-hash-object.

Bj