On 19/02/14 14:55, David Seikel wrote: > On Wed, 19 Feb 2014 14:44:27 +0000 Tom Hacohen > <tom.haco...@samsung.com> wrote: > >> On 19/02/14 14:37, David Seikel wrote: >>> On Wed, 19 Feb 2014 15:17:05 +0100 Boris Faure <bo...@fau.re> wrote: >>> >>>> On 14-02-19 14:03, Tom Hacohen wrote: >>>> […] >>>>> One of the things I'd love seeing in 1.10 that will make your life >>>>> much easier is tagging changes in the commit log. So for example, >>>>> having #fix/#feature in the commit log will indicate a fix and a >>>>> feature respectively. I went with the hashtag, because that's what >>>>> people are used to from the web world, however we can use whatever >>>>> identifier we would like. It's good to have a unique identifier, >>>>> because it's easier to grep. >>>> >>>> I like the idea, but using '#' as first character can be a pita >>>> with git since it would strip lines starting with '#' after >>>> editing the commit message. >>> >>> Didn't we try this already, "tagging" commits with "feature:" or >>> "bug:"? Putting another symbol in front of it wont make a lot of >>> difference. >> >> No we didn't, it's only done in e at the moment, not the efl. >> Also, I don't like the way it's done in e. In e it's taking the place >> of the relevant component (e.g "Evas textblock:") and has to be in >> the summary line. >> >> I'd rather have something like. >> >> "Evas textblock: Fixed a bug with bla. >> >> More bla bla bla about the issue. >> @fix" > > Ah so you are replacing something that was simple and required no > searching with something a bit more tricky to process.
Both require searching. You have a lot of commits, most of them are neither fixes nor features. Fixes and features are only things that have changed since the version before. Most commits are fixes (or changes) to recently changed code. The "feature:" is searchable thanks to the colon, so it's essentially the same as what I'm suggestion, but the # there is a colon and at the end and not the beginning. The only different to that in my suggestion, is that I'm allowing it to be anywhere in the commit message, as to not litter the all too short summary line. > >> While allowing: >> >> "Evas textblock: @fix issue with bla." > > That would actually be a better choice. Some git tools show you a list > of just the summaries. Plus, if we keep it to the summary, there's > less chance of what ever arbitrary symbol is chosen being mistaken for > some languages token. > It's not meant for git tools or humans. It's meant for machines. Machines can easily look at the whole log, find the relevant commits, and then print the list in whatever way the maintainer likes. -- Tom. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
