On other hand when you see commit message: Add foo/bar config option
What is your first though? Oh, new config option! But no, that was missed option description in docs. To resolve such collision I may tag my commit message: Docs: add foo/bar config option // now you know what have changed! or imagine something like: Add missed foo/bar/config option description in docs // too long How I could solve this problem? -- ,,,^..^,,, On Wed, Dec 4, 2013 at 8: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 >>
