While I'm whining about tags: Tagging is most useful by having multiple tags per target. My blog post can be tagged [vacation] [swaziland] [photos] [family], and then later I can find all posts about family.
Git messages are forced to one tag. That's unhelpful because commits ideally update code, tests, and documentation. A useful tag might be [ui] but I could get the same thing by looking at the history of src/fauxton/. It is marginally useful at a very dear cost: 4-10 characters per commit message. On Wed, Dec 4, 2013 at 11:24 PM, Jason Smith <[email protected]> wrote: > -1 > > We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit of > ceremony with little benefit. For me at least, I never want to see "only > [foo] commits" I want to see "only commits in subdirectory foo/". Otherwise > I see the commits through `git blame`. > > That's my opinion, but I am comfortable being overruled. > > > On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <[email protected]>wrote: > >> Hi all, >> >> I would like to propose that we start to tag our commits. The reasonning >> behind that is to distinct easily the changes concerning the doc, the ui >> and the core and filter them immediately and force us to make a change >> atomic. So I would like to propose that we tag the commit line with >> >> [DOC] >> [UI] >> [CORE] >> >> other ? Another way to distinct the changes would also be to have all of >> these as subprojects eventually but it may require too much changes. >> >> Thoughts? >> >> - benoit >> > >
