Re: [Geany-devel] Commit messages on merges
Am 27.02.2012 08:44, schrieb Lex Trotman: > [...] >> >> I guess if we can filter out merge commits and only show the real commit >> information it should be good? >> >> (See other message with individual commit messages) > > Yeah, IMO git gives us lots of un-needed merge messages, not much more > we can really say other than merged master into branch, so we will > have to filter them for human consumption in newsletters anyway. It's not git. It's most likely githubs's webinterface which is causing the entries I'm not happy about. Using command line git merge -m "I just did some cool stuff" would be a bit better. Now git log e.g. looks like commit 3bcd7fc40078efd601f0e9bed8efec971d505db2 Merge: 3d4e8b4 5cc8a96 Author: Matthew Brush Date: Sun Feb 26 21:04:50 2012 -0800 Merge pull request #19 from techee/fixes Fixes commit 3d4e8b41d419255ee1b0764fb60e45ea588bd800 Merge: d7d5a6d ca9dca9 Author: Matthew Brush Date: Sun Feb 26 20:50:01 2012 -0800 Merge pull request #25 from techee/project_patches Project patches > The alternative is to always re-base before committing merged branches > to master, which is probably better since we don't care how the > developer got to the end point and all the commits and merges she made > on the way, we just care what the commit to master does. No. This will remove most probably of e.g. additional contributors. Cheers, Frank signature.asc Description: OpenPGP digital signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
On Mon, 27 Feb 2012 08:23:41 +1100 Lex Trotman wrote: > [...] > >> My personal preference would be some shared static function that > >> any plugin using markers could access. > > > > A simple ui_utils function to find and return the first available > > marker based on SC_MARK_AVAILABLE would suffice. > > The absolute minimum we need is for Geany to set unused markers to > available. Geany has to do this, it is the only thing *guaranteed* to > run before all plugins. Fraser #2 states this, but it won't be enough. In fact, it may be useful only for programs with a single SciObj, such as SciTE. > It is not clear to me if it has to be done for each scintilla buffer, > each view or once only. For each buffer (each SciObj), I guarantee... > Plugins or Geany can then simply search for the next available one. > and allocate it by setting it to something other than available. Since a plugin may not need to set [all of] it's markers for each file, and we may even have 0 buffers open, a guint map seems required, and I was probably wrong to suggest AVAILABLE. Can't query/define Scintilla markers without at least 1 SciObj... > Since every mark using plugin should do it it is probably better to > have a common function in Geany. utils_ui_get_marker(), utils_ui_free_marker(). > It can then also generate a message > to the user suggesting unloading a plugin if it runs out of markers. Shoudn't the plugin handle this? It may reduce the number of markers used, work without them if non-critical, or do something else. > Bookmarks should also be re-written to only use the number of markers > as current bookmarks, not grab ten at startup. Ten markers? Wow, that's heavy. Different colors or what? -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Commit messages on merges
Am 27.02.2012 08:44, schrieb Lex Trotman: [...] I guess if we can filter out merge commits and only show the real commit information it should be good? (See other message with individual commit messages) Yeah, IMO git gives us lots of un-needed merge messages, not much more we can really say other than merged master into branch, so we will have to filter them for human consumption in newsletters anyway. git log --no-merges ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
