On Wed, 19 Feb 2014 15:12:14 +0000 Tom Hacohen <tom.haco...@samsung.com> wrote:
> 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. First word of the summary line doesn't require searching, it's a fixed position, you know where it is, no need to search for it. > 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. Ah THAT's the relevant part of your suggestion. Keeping the summary line short. We are artificially keeping summary lines short for the benefit of *some* humans, in the same way that we insist on keeping code to less than 80 characters per line to suit *some* humans. Then we create function names like emotion_generic_players_swizzle_thine_hypervisors_intensification_thingamabob_widershins_as_well_as_gangnam_style_to_appease_thy_thrice_headed_chickens just to annoy people, not to mention not using CamelCase, so such names are nineteen characters longer, and I wear out my underscore key quicker with my long fingernails (photographic proof available on request). So long as we are the same page now. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
