Hi,
I hope this time I got it right. Is there some kind of style-guide I can
refer to in future ?
> Another question is if the QA data expected to be amended or
> annotated later, after it is created.
>
> If the answer is yes, then you probably would not want tags --
> you can create a new tag that points at the same commit to
> update the data, but then you have no structural relationships
> given by git between such tags that point at the same commit.
> You could infer their order by timestamp but that is about it.
> I think you are better off creating a separate QA project that
> adds one new file per commit on the main project, and have the
> file identify the commit object on the main project (either
> start your text file format for QA data with the commit object
> name, or name each such QA data file after the commit object
> name). Then your automated procedure could scan and add a new
> file to the QA project every time a new commit is made to the
> main project, and the data in the QA project can be amended or
> annotated and the changes will be version controlled.
>
Great idea ! Thanks a lot. Originally it was not planned to alter the
results once committet, but this way it would even be possible to rescan
a commit with a different tool and merge the results. Git would also be
able to use delta-encoding when packing what can be considered extremly
efficient since most probably most scan-results won't differ much.
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.
When thinking about this very elegant way to handle meta-data, I got
another idea:
The quality assurance system also works distributed. For scalability
reasons there are multiple scanners, each scanning one commit at a time.
Do you think git could also be used to handle "locking" ? The scanners
would then push a commit with an empty result-file into the
annotations-repository so all other scanners who are looking for
currently unscanned commits would ignore it in future. When finished the
result can be inserted by pushing a subsequent commit. This way one
avoids the need for a seperate job-server / protocol.
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 ?
Or could simultaniously pushing into the same branch f.e. break the
repository ?
Hmm.. 2 more things on my mind:
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)
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), optionally
omitting writing it to the database (-n = no-write) (like
git-hash-object), by default validating its input (overriding with -f)
(like git-mktag, git-mktree) and maybe even able to add a reference to
it with -r (like git-tag).
Bj
-
: 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