git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Improve tags

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Mar 26, 2009, 16:02 UTC
Message-ID
<49CBA713.4040605@drmicha.warpmail.net>
In-Reply-To
<49CB798B.4090107@gmail.com>
Etienne Vallette d'Osia venit, vidit, dixit 26.03.2009 13:48:
Show 83 quoted lines
> 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...
You described your motivation and use case very clearly!

Maybe "label" would be an appropriate name for "non-unique tags". I assume they should be local and non-versioned. It sounds as if a file storing a list of sha1s could be the simplest approach (one file per label in a new subdir of .git), although this may not scale well. A first step could be implementing a command "git label" in shell which sets and displays labels. Later on, various builtins would need to be taught about it if you want labels displayed in log etc.

Michael
Previous: Etienne Vallette d'OsiaNext: Etienne Vallette d'Osia
Message 2 of 7 in “Improve tags”
  1. Etienne Vallette d'OsiaMar 26, 2009
  2. Michael J GruberMar 26, 2009
  3. Etienne Vallette d'OsiaMar 27, 2009
  4. Jakub NarebskiMar 27, 2009
  5. Etienne Vallette d'OsiaMar 27, 2009
  6. Nanako ShiraishiMar 26, 2009
  7. Etienne Vallette d'OsiaMar 27, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.