Björn Engelmann <BjEngelmann@xxxxxx> 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. - : 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