{"thread":{"id":"18572","subject":"Improve tags","startedAt":"2009-03-26T12:48:11Z","lastAt":"2009-03-27T14:39:26Z","messageCount":7,"participants":["Etienne Vallette d'Osia","Michael J Gruber","Nanako Shiraishi","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109525","messageId":"49CB798B.4090107@gmail.com","threadId":"18572","inReplyTo":null,"subject":"Improve tags","fromName":"Etienne Vallette d'Osia","fromEmail":"dohzya@gmail.com","sentAt":"2009-03-26T12:48:11Z","receivedAt":"2009-03-26T12:48:11Z","isPatch":false,"sender":{"key":"dohzya@gmail.com","avatar":"https://gravatar.com/avatar/2ec58d74d930356327523e6b5fe992a0a9b2d2748b733ba63a9d1298798853c3?d=mp&s=160"},"body":"Hi,\n\nI search a way to track commits in function of their aim.\n\nI tried to use branches (test, debugger, etc).\nFor example if I search the commits related to tests,\nI can search all commits what are in branch test and not in branch debugger,\nbut it's boring (I need to exclude all other branches than test)\nMoreover, if I remove a branch, it will complicate the search.\n\nIn addition, branches are a way to specify streams,\nnot a way to specify an aim for a commit.\n(like in ruby a class is a method container, not a type)\nSo branch names are often like next, pu, dev, test, stupid-idea, etc.\nThey are totally useless for tracking aims.\n\nThe method used in every repositories I looked into\nis to use the \"aim: subject\" form in their commit messages.\nSo search all commits related to a specific aim is equivalent\nto grep \"my-aim:\" in commit messages.\nThe problem is that this method is not used in all commits\n(\"aim - subject\" or just \"subject\" are used too),\nso I can't assume to find all commits with a such method...\nAnd if a search a more generic form (\"test\"), I might find\nuseless commits that will pollute my results...\n\nThe last method I can find, is to use tags.\nBut, as CVS and many others do, tags are unique.\nIt is usefull for tagging a software version number,\nbut not for tracking.\n\nSo, we have branches, which are not stable,\ntags, which are unique,\nand commit messages, which are not normalized.\n\nWhat can we do ?\n\nIn my mind, the good ways are to improve the commit message way,\nor, better, to change the current tag concept.\n\nOne improvement could be to add a mechanism similar to \"signed-off-by:\"\nmessage: add an option in git-commit to facilitate the creation of \"tags\"\nand make sure these \"tags\" will be normalized...\nexample: `git commit -t test,debugger -m \"add test for debugger\"`\n         this will create a commit and add automatically\n         \"test: debugger:\" at begin or\n         \"tags: test, debugger\" at end of the message\n           (like the \"signed-off-by: xxx\" lines)\nIt's not really better this current solution,\nbut it's a first step to normalization.\n\nThere is still a big problem with this solution : this tags are immutable,\nas they are stored inside the commit.\n\nAn other improvement would be to create new version of tags.\n`git tag v1.6.3` would create a unique tag, and\n`git tag --no-unique test` would create a simple tag.\n(until we can change the default)\nThe -t option of git-commit is still possible,\nbut it will call the new git-tag.\n\nNote: Theses tags may be treated like refs (git log fault-tolerance),\nbut they can't be stored in $GIT_DIR/refs directory,\nas they reference a list a commits...\n\nSo, I see 2 solutions:\n- Normalize the way to write tags but keep them into commit message:\n  (-) There will be 2 sorts of tags: static immutable and dynamic unique\n  (+) This way is totally retro-compatible\n- Change the tags concept:\n  (-) Need to change the tag object format (ouch)\n  (+) More powerful\n\nMaybe I have missed a better tool to do my job ?\nOr there is a better improvement which is more simple ?\n\n\nBest regards,\n\n\nEtienne Vallette d'Osia\n\nps: I'm really sorry if my message is full of English errors...\n"},{"id":"109548","messageId":"49CBA713.4040605@drmicha.warpmail.net","threadId":"18572","inReplyTo":"49CB798B.4090107@gmail.com","subject":"Re: Improve tags","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-26T16:02:27Z","receivedAt":"2009-03-26T16:02:27Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Etienne Vallette d'Osia venit, vidit, dixit 26.03.2009 13:48:\n> Hi,\n> \n> I search a way to track commits in function of their aim.\n> \n> I tried to use branches (test, debugger, etc).\n> For example if I search the commits related to tests,\n> I can search all commits what are in branch test and not in branch debugger,\n> but it's boring (I need to exclude all other branches than test)\n> Moreover, if I remove a branch, it will complicate the search.\n> \n> In addition, branches are a way to specify streams,\n> not a way to specify an aim for a commit.\n> (like in ruby a class is a method container, not a type)\n> So branch names are often like next, pu, dev, test, stupid-idea, etc.\n> They are totally useless for tracking aims.\n> \n> The method used in every repositories I looked into\n> is to use the \"aim: subject\" form in their commit messages.\n> So search all commits related to a specific aim is equivalent\n> to grep \"my-aim:\" in commit messages.\n> The problem is that this method is not used in all commits\n> (\"aim - subject\" or just \"subject\" are used too),\n> so I can't assume to find all commits with a such method...\n> And if a search a more generic form (\"test\"), I might find\n> useless commits that will pollute my results...\n> \n> The last method I can find, is to use tags.\n> But, as CVS and many others do, tags are unique.\n> It is usefull for tagging a software version number,\n> but not for tracking.\n> \n> So, we have branches, which are not stable,\n> tags, which are unique,\n> and commit messages, which are not normalized.\n> \n> What can we do ?\n> \n> In my mind, the good ways are to improve the commit message way,\n> or, better, to change the current tag concept.\n> \n> One improvement could be to add a mechanism similar to \"signed-off-by:\"\n> message: add an option in git-commit to facilitate the creation of \"tags\"\n> and make sure these \"tags\" will be normalized...\n> example: `git commit -t test,debugger -m \"add test for debugger\"`\n>          this will create a commit and add automatically\n>          \"test: debugger:\" at begin or\n>          \"tags: test, debugger\" at end of the message\n>            (like the \"signed-off-by: xxx\" lines)\n> It's not really better this current solution,\n> but it's a first step to normalization.\n> \n> There is still a big problem with this solution : this tags are immutable,\n> as they are stored inside the commit.\n> \n> An other improvement would be to create new version of tags.\n> `git tag v1.6.3` would create a unique tag, and\n> `git tag --no-unique test` would create a simple tag.\n> (until we can change the default)\n> The -t option of git-commit is still possible,\n> but it will call the new git-tag.\n> \n> Note: Theses tags may be treated like refs (git log fault-tolerance),\n> but they can't be stored in $GIT_DIR/refs directory,\n> as they reference a list a commits...\n> \n> So, I see 2 solutions:\n> - Normalize the way to write tags but keep them into commit message:\n>   (-) There will be 2 sorts of tags: static immutable and dynamic unique\n>   (+) This way is totally retro-compatible\n> - Change the tags concept:\n>   (-) Need to change the tag object format (ouch)\n>   (+) More powerful\n> \n> Maybe I have missed a better tool to do my job ?\n> Or there is a better improvement which is more simple ?\n> \n> \n> Best regards,\n> \n> \n> Etienne Vallette d'Osia\n> \n> ps: I'm really sorry if my message is full of English errors...\n\nYou described your motivation and use case very clearly!\n\nMaybe \"label\" would be an appropriate name for \"non-unique tags\". I\nassume they should be local and non-versioned. It sounds as if a file\nstoring a list of sha1s could be the simplest approach (one file per\nlabel in a new subdir of .git), although this may not scale well. A\nfirst step could be implementing a command \"git label\" in shell which\nsets and displays labels. Later on, various builtins would need to be\ntaught about it if you want labels displayed in log etc.\n\nMichael\n"},{"id":"109583","messageId":"20090327065356.6117@nanako3.lavabit.com","threadId":"18572","inReplyTo":"49CB798B.4090107@gmail.com","subject":"Re: Improve tags","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-03-26T21:53:56Z","receivedAt":"2009-03-26T21:53:56Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting \"Etienne Vallette d'Osia\" <dohzya@gmail.com>:\n\n> In addition, branches are a way to specify streams,\n> not a way to specify an aim for a commit.\n> (like in ruby a class is a method container, not a type)\n> So branch names are often like next, pu, dev, test, stupid-idea, etc.\n> They are totally useless for tracking aims.\n\nWhy should that be?  'next' clearly states the aim (it is to serve as an\nintegration testing area for the possible new features for the next\nrelease).\n\nQuoting http://article.gmane.org/gmane.comp.version-control.git/113812\n\n (1) Name your (eh, \"my\") branch just like you name your function.\n\n     You probably learned in programming 101 course the importance of\n     giving a good name to your functions.  The same principle applies.\n     When I see kb/checkout-optim branch, I know it is about optimizing\n     the checkout command, and it came from Kjetil Barvik.  I can tell\n     that jc/maint-1.6.0-read-tree-overlay is about the bugfix to the\n     \"overlay\" feature of read-tree command, and the fix would apply as\n     far back as the 1.6.0.X series, not just the current maintenance.\n\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"109628","messageId":"gqi8cc$7vq$1@ger.gmane.org","threadId":"18572","inReplyTo":"20090327065356.6117@nanako3.lavabit.com","subject":"Re: Improve tags","fromName":"Etienne Vallette d'Osia","fromEmail":"etienne.vallettedosia@gmail.com","sentAt":"2009-03-27T10:05:00Z","receivedAt":"2009-03-27T10:05:00Z","isPatch":false,"sender":{"key":"etienne.vallettedosia@gmail.com","avatar":null},"body":"Nanako Shiraishi a écrit :\n> Quoting \"Etienne Vallette d'Osia\" <dohzya@gmail.com>:\n> \n>> In addition, branches are a way to specify streams,\n>> not a way to specify an aim for a commit.\n>> (like in ruby a class is a method container, not a type)\n>> So branch names are often like next, pu, dev, test, stupid-idea, etc.\n>> They are totally useless for tracking aims.\n> \n> Why should that be?  'next' clearly states the aim (it is to serve as an\n> integration testing area for the possible new features for the next\n> release).\n> \nIt is not an aim (maybe \"aim\" is not the right term ?), it a status.\nFor me the aim is 'this commit is related to the documentation', 'this \ncommit is related to test and to the debugger'.\n"},{"id":"109630","messageId":"49CCAAD3.4070104@gmail.com","threadId":"18572","inReplyTo":"49CBA713.4040605@drmicha.warpmail.net","subject":"Re: Improve tags","fromName":"Etienne Vallette d'Osia","fromEmail":"dohzya@gmail.com","sentAt":"2009-03-27T10:30:43Z","receivedAt":"2009-03-27T10:30:43Z","isPatch":false,"sender":{"key":"dohzya@gmail.com","avatar":"https://gravatar.com/avatar/2ec58d74d930356327523e6b5fe992a0a9b2d2748b733ba63a9d1298798853c3?d=mp&s=160"},"body":" > You described your motivation and use case very clearly!\n >\n > Maybe \"label\" would be an appropriate name for \"non-unique tags\". I\n > assume they should be local and non-versioned. It sounds as if a file\n > storing a list of sha1s could be the simplest approach (one file per\n > label in a new subdir of .git), although this may not scale well. A\n > first step could be implementing a command \"git label\" in shell which\n > sets and displays labels. Later on, various builtins would need to be\n > taught about it if you want labels displayed in log etc.\n >\n > Michael\n\nThanks a lot\n\n\"label\" is perfect !\n\nIn fact, I was thinking about non-local labels.\nBut keeping information in a separate file and not in commit directly is \na very nice idea (and closer than the current tag implementation).\nI love your approach, you have just make this idea realizable\n"},{"id":"109649","messageId":"m3bprn2gs7.fsf@localhost.localdomain","threadId":"18572","inReplyTo":"49CCAAD3.4070104@gmail.com","subject":"Re: Improve tags","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-03-27T14:15:42Z","receivedAt":"2009-03-27T14:15:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Etienne Vallette d'Osia\" <dohzya@gmail.com> writes:\n\n>  > You described your motivation and use case very clearly!\n>  >\n>  > Maybe \"label\" would be an appropriate name for \"non-unique tags\". I\n>  > assume they should be local and non-versioned. It sounds as if a file\n>  > storing a list of sha1s could be the simplest approach (one file per\n>  > label in a new subdir of .git), although this may not scale well. A\n>  > first step could be implementing a command \"git label\" in shell which\n>  > sets and displays labels. Later on, various builtins would need to be\n>  > taught about it if you want labels displayed in log etc.\n> \n> Thanks a lot\n> \n> \"label\" is perfect !\n> \n> In fact, I was thinking about non-local labels.\n> But keeping information in a separate file and not in commit directly\n> is a very nice idea (and closer than the current tag implementation).\n> I love your approach, you have just make this idea realizable\n\nThis is a bit argument for (abandoned / dropped) 'notes' commit header\nidea... But only a tiny bit.\n\nMore seriously: take a look at 'notes' idea; I'm not sure what state\nthey are currently, but they are in active (more or less) development.\nThey are extension of tags, allowing post-fact annotation of commits.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"109650","messageId":"49CCE51E.10203@gmail.com","threadId":"18572","inReplyTo":"m3bprn2gs7.fsf@localhost.localdomain","subject":"Re: Improve tags","fromName":"Etienne Vallette d'Osia","fromEmail":"dohzya@gmail.com","sentAt":"2009-03-27T14:39:26Z","receivedAt":"2009-03-27T14:39:26Z","isPatch":false,"sender":{"key":"dohzya@gmail.com","avatar":"https://gravatar.com/avatar/2ec58d74d930356327523e6b5fe992a0a9b2d2748b733ba63a9d1298798853c3?d=mp&s=160"},"body":"on 27.03.2009 15:15, Jakub Narebski wrote:\n > More seriously: take a look at 'notes' idea; I'm not sure what state\n > they are currently, but they are in active (more or less) development.\n > They are extension of tags, allowing post-fact annotation of commits.\n >\ngit notes store a message related to _a specific_ commit.\nIt doesn't allow to find some commits.\n\nIn my mind, the best way to bind labels and notes (which would be great) \nis to allow to create a note related to a label.\n\nRegards,\n\n--\nEtienne Vallette d'Osia\n"}]}