2010/11/22 Anselm R Garbe <garb...@gmail.com>: > > I don't mind if you set up a git repo where each patch from the > website resides in a separate branch, but I think you just organise > the existing approach just differently. You don't fix the problem, > which is having a suitable process to determine the best feature set > for the software by default. So far the patch based approach was good > enough to count the downloads and to decide on popularity or necessity > of some patches to be applied to the mainstream repo at some point. > And everyone can easily add a patch file to the wiki, apart from > having a central place for the patch files.
Hello, Just to mention the possibility to record patches into hg patch repositories instead of the wiki. http://mercurial.selenic.com/wiki/MqTutorial#Indicate_that_you_want_to_use_mq_on_this_repository The advantage is to have a dedicated repo to clone and a possibility to select what patch to merge by editing series file (and there are more chances to update them this way). For example with a patch repo named dmenu-patches, you have to link this repo to dmenu/.hg/patches. But note this solution is not immediate since you have to set an alias (not sure but should be done directly in .hgrc with mercurial 1.7): alias mq='hg -R $(hg root)/.hg/patches' BW -- J u l i e n J e h a n n e t