{"thread":{"id":"16112","subject":"commit type","startedAt":"2008-10-31T17:58:25Z","lastAt":"2008-11-03T01:34:39Z","messageCount":8,"participants":["7rans","David Symonds","Samuel Lucas Vaz de Mello","Johannes Schindelin","bd_"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94430","messageId":"loom.20081031T174821-603@post.gmane.org","threadId":"16112","inReplyTo":null,"subject":"commit type","fromName":"7rans","fromEmail":"transfire@gmail.com","sentAt":"2008-10-31T17:58:25Z","receivedAt":"2008-10-31T17:58:25Z","isPatch":false,"sender":{"key":"transfire@gmail.com","avatar":"https://gravatar.com/avatar/f98ccb7e9a9a79b343086463300c72cc330cf53bc5731867b662874c9fe1ccca?d=mp&s=160"},"body":"Hi--\n\nI have a feature request.\n\nI'd like to be a able to add a commit type to my commits, like 'major', 'minor',\n'bug', etc. it would be useful in reviewing changes, especially when listing\nchanges for end-users to see, because then miscellaneous/administrative commits\ncould be omitted and only changes important to users listed.\n\nCurrently I achieve this by adding \"[type]\" to the end of my commit messages.\nBut of course that's less than optimal. I think being able to add a commit type\nwould be generally useful to everyone, and really has no downside becuase you do\nnot need to use it if you prefer not.\n\nThanks,\ntrans.\n"},{"id":"94431","messageId":"ee77f5c20810311104m6044bf70r1d9d405fa04454e0@mail.gmail.com","threadId":"16112","inReplyTo":"loom.20081031T174821-603@post.gmane.org","subject":"Re: commit type","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-10-31T18:04:22Z","receivedAt":"2008-10-31T18:04:22Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Fri, Oct 31, 2008 at 10:58 AM, 7rans wrote:\n\n> Currently I achieve this by adding \"[type]\" to the end of my commit messages.\n> But of course that's less than optimal.\n\nWhy is that less than optimal? It seems a lot less intrusive than what\nyou suggest.\n\n\nDave.\n"},{"id":"94437","messageId":"490B54C5.3070108@datacom.ind.br","threadId":"16112","inReplyTo":"ee77f5c20810311104m6044bf70r1d9d405fa04454e0@mail.gmail.com","subject":"Re: commit type","fromName":"Samuel Lucas Vaz de Mello","fromEmail":"samuellucas@datacom.ind.br","sentAt":"2008-10-31T18:56:05Z","receivedAt":"2008-10-31T18:56:05Z","isPatch":false,"sender":{"key":"samuellucas@datacom.ind.br","avatar":null},"body":"David Symonds wrote:\n> On Fri, Oct 31, 2008 at 10:58 AM, 7rans wrote:\n> \n>> Currently I achieve this by adding \"[type]\" to the end of my commit messages.\n>> But of course that's less than optimal.\n> \n> Why is that less than optimal? It seems a lot less intrusive than what\n> you suggest.\n> \n\nAlso, you can use a hook to check that the commit message contains a valid \"type\".\n\n - Samuel\n"},{"id":"94440","messageId":"loom.20081031T191102-81@post.gmane.org","threadId":"16112","inReplyTo":"ee77f5c20810311104m6044bf70r1d9d405fa04454e0@mail.gmail.com","subject":"Re: commit type","fromName":"7rans","fromEmail":"transfire@gmail.com","sentAt":"2008-10-31T19:20:57Z","receivedAt":"2008-10-31T19:20:57Z","isPatch":false,"sender":{"key":"transfire@gmail.com","avatar":"https://gravatar.com/avatar/f98ccb7e9a9a79b343086463300c72cc330cf53bc5731867b662874c9fe1ccca?d=mp&s=160"},"body":"David Symonds gmail.com> writes:\n\n> \n> On Fri, Oct 31, 2008 at 10:58 AM, 7rans gmail.com> wrote:\n> \n> > Currently I achieve this by adding \"[type]\" to the end of my commit messages.\n> > But of course that's less than optimal.\n> \n> Why is that less than optimal? It seems a lot less intrusive than what\n> you suggest.\n\nBecause it becomes formalized. Which means people can write tools other people\ncan use to work with them.\n\nHaving the type embedded in commit message not only clutters up the commit\nmessages, but different people would do it differently, using different brackets\nor putting it the start or the end of the message, etc. \n\nAnd of course it would be easier to ask git to list certain types of commits if\nit knew about them.\n\n7rans.\n"},{"id":"94488","messageId":"alpine.DEB.1.00.0811010025570.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16112","inReplyTo":"loom.20081031T191102-81@post.gmane.org","subject":"Re: commit type","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-31T23:27:19Z","receivedAt":"2008-10-31T23:27:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 31 Oct 2008, 7rans wrote:\n\n> David Symonds gmail.com> writes:\n> \n> > On Fri, Oct 31, 2008 at 10:58 AM, 7rans gmail.com> \n> > wrote:\n> > \n> > > Currently I achieve this by adding \"[type]\" to the end of my commit \n> > > messages. But of course that's less than optimal.\n> > \n> > Why is that less than optimal? It seems a lot less intrusive than what \n> > you suggest.\n> \n> Because it becomes formalized. Which means people can write tools other \n> people can use to work with them.\n\nSo you want to force this onto all Git users?\n\nIf yes: that murmur you hear in the background, it might well be the \ncollective \"thanks, but no thanks\" of people who do not want that type of \ndistinction between different commits.\n\nIf no: what would be the real difference from that suffix in the oneline?\n\nCiao,\nDscho\n"},{"id":"94533","messageId":"loom.20081101T034635-562@post.gmane.org","threadId":"16112","inReplyTo":"alpine.DEB.1.00.0811010025570.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: commit type","fromName":"7rans","fromEmail":"transfire@gmail.com","sentAt":"2008-11-01T04:15:10Z","receivedAt":"2008-11-01T04:15:10Z","isPatch":false,"sender":{"key":"transfire@gmail.com","avatar":"https://gravatar.com/avatar/f98ccb7e9a9a79b343086463300c72cc330cf53bc5731867b662874c9fe1ccca?d=mp&s=160"},"body":"Johannes Schindelin gmx.de> writes:\n\n> So you want to force this onto all Git users?\n\nNot at all. It would be a purely optional. You would never even need to know the\nfeature existed if you didn't want to use it. So I'm not sure how that is\nforcing it upon anyone.\n\nMoreover, I suggested it b/c I would find such a feature very useful, and, by\nextension, thought others might as well. Perhaps others have done something\nsimilar, in which case it would be interesting the hear their take, or on the\nother hand they've never considered it before, but now can consider the\npotential utility of just such a feature.\n \n> If yes: that murmur you hear in the background, it might well be the \n> collective \"thanks, but no thanks\" of people who do not want that type of \n> distinction between different commits.\n\nThere is no need to make one. It's purely annotative.\n\nT.\n"},{"id":"94700","messageId":"3e8340490811021502p70ab40a1ocdc9fca012769a29@mail.gmail.com","threadId":"16112","inReplyTo":"loom.20081101T034635-562@post.gmane.org","subject":"Re: commit type","fromName":"bd_","fromEmail":"bdonlan@gmail.com","sentAt":"2008-11-02T23:02:09Z","receivedAt":"2008-11-02T23:02:09Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Fri, Oct 31, 2008 at 11:15 PM, 7rans wrote:\n> Johannes Schindelin gmx.de> writes:\n>\n>> So you want to force this onto all Git users?\n>\n> Not at all. It would be a purely optional. You would never even need to know the\n> feature existed if you didn't want to use it. So I'm not sure how that is\n> forcing it upon anyone.\n>\n> Moreover, I suggested it b/c I would find such a feature very useful, and, by\n> extension, thought others might as well. Perhaps others have done something\n> similar, in which case it would be interesting the hear their take, or on the\n> other hand they've never considered it before, but now can consider the\n> potential utility of just such a feature.\n>\n>> If yes: that murmur you hear in the background, it might well be the\n>> collective \"thanks, but no thanks\" of people who do not want that type of\n>> distinction between different commits\n>\n> There is no need to make one. It's purely annotative.\n\nThe problem with this approach is that it begins to dictate a set of\nannotations which are considered 'more important' by the git core than\nothers. By allowing in your 'commit type', it sets a precedent that\ngit will add random, possibly not backwards compatible metadata\nchanges just to support the local policies of some subset of git\nusers. It's far better to provide a generic feature that will cover\nall users; and using the commit description, with hooks to enforce\nproper format according to local policy, is just that.\n\nIf using the commit description, with hooks to enforce whatever\nformatting you prefer, is not sufficient for your needs, then it would\nbe useful to discuss exactly how this would be deficient, and then\npossibly think about adding a /generic/ feature that meets your needs.\n"},{"id":"94711","messageId":"loom.20081103T011526-296@post.gmane.org","threadId":"16112","inReplyTo":"3e8340490811021502p70ab40a1ocdc9fca012769a29@mail.gmail.com","subject":"Re: commit type","fromName":"7rans","fromEmail":"transfire@gmail.com","sentAt":"2008-11-03T01:34:39Z","receivedAt":"2008-11-03T01:34:39Z","isPatch":false,"sender":{"key":"transfire@gmail.com","avatar":"https://gravatar.com/avatar/f98ccb7e9a9a79b343086463300c72cc330cf53bc5731867b662874c9fe1ccca?d=mp&s=160"},"body":"bd_ gmail.com> writes:\n\n> The problem with this approach is that it begins to dictate a set of\n> annotations which are considered 'more important' by the git core than\n> others. By allowing in your 'commit type', it sets a precedent that\n> git will add random, possibly not backwards compatible metadata\n> changes just to support the local policies of some subset of git\n> users. It's far better to provide a generic feature that will cover\n> all users; and using the commit description, with hooks to enforce\n> proper format according to local policy, is just that.\n> \n> If using the commit description, with hooks to enforce whatever\n> formatting you prefer, is not sufficient for your needs, then it would\n> be useful to discuss exactly how this would be deficient, and then\n> possibly think about adding a /generic/ feature that meets your needs.\n\nExcept for going so far as to add full-on tagging to commits, I'd don't see how\nit could be more generic. Perhaps I'm misunderstood. I'm not suggesting any\nparticular set of types, if that's what you think. Just the ability to add one.\nFor example:\n\n git commit -m \"describe some change\" --type anything-at-all\n\nSo the types *I* would use are 'major', 'minor' and 'bug', but others could use\nwhatever types they'd like. Ie. developers could have their one type policies.\nAnd I agree, it would be cool to define hooks to enforce the policy.\n\nThe problem with adding them to the description is that other tools have no idea\nabout them and so can't not display them when they aren't wanted --a logging\ntool is a good example. It is also means more complicated scripting is required\nto do anything with them, not a huge deal, but a pita nonetheless.\n"}]}