Hi,
I search a way to track commits in function of their aim.
I tried to use branches (test, debugger, etc).
For example if I search the commits related to tests,
I can search all commits what are in branch test and not in branch debugger,
but it's boring (I need to exclude all other branches than test)
Moreover, if I remove a branch, it will complicate the search.
In addition, branches are a way to specify streams,
not a way to specify an aim for a commit.
(like in ruby a class is a method container, not a type)
So branch names are often like next, pu, dev, test, stupid-idea, etc.
They are totally useless for tracking aims.
The method used in every repositories I looked into
is to use the "aim: subject" form in their commit messages.
So search all commits related to a specific aim is equivalent
to grep "my-aim:" in commit messages.
The problem is that this method is not used in all commits
("aim - subject" or just "subject" are used too),
so I can't assume to find all commits with a such method...
And if a search a more generic form ("test"), I might find
useless commits that will pollute my results...
The last method I can find, is to use tags.
But, as CVS and many others do, tags are unique.
It is usefull for tagging a software version number,
but not for tracking.
So, we have branches, which are not stable,
tags, which are unique,
and commit messages, which are not normalized.
What can we do ?
In my mind, the good ways are to improve the commit message way,
or, better, to change the current tag concept.
One improvement could be to add a mechanism similar to "signed-off-by:"
message: add an option in git-commit to facilitate the creation of "tags"
and make sure these "tags" will be normalized...
example: `git commit -t test,debugger -m "add test for debugger"`
this will create a commit and add automatically
"test: debugger:" at begin or
"tags: test, debugger" at end of the message
(like the "signed-off-by: xxx" lines)
It's not really better this current solution,
but it's a first step to normalization.
There is still a big problem with this solution : this tags are immutable,
as they are stored inside the commit.
An other improvement would be to create new version of tags.
`git tag v1.6.3` would create a unique tag, and
`git tag --no-unique test` would create a simple tag.
(until we can change the default)
The -t option of git-commit is still possible,
but it will call the new git-tag.
Note: Theses tags may be treated like refs (git log fault-tolerance),
but they can't be stored in $GIT_DIR/refs directory,
as they reference a list a commits...
So, I see 2 solutions:
- Normalize the way to write tags but keep them into commit message:
(-) There will be 2 sorts of tags: static immutable and dynamic unique
(+) This way is totally retro-compatible
- Change the tags concept:
(-) Need to change the tag object format (ouch)
(+) More powerful
Maybe I have missed a better tool to do my job ?
Or there is a better improvement which is more simple ?
Best regards,
Etienne Vallette d'Osia
ps: I'm really sorry if my message is full of English errors...
--
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
