Hi Dave, I quite agree with you..git is pretty smart at this-merging changes to a single files, and conflicting lines can be nicely shown. Of course, it's the matter of who gets merged first and the other PR needs rework (actually, if the code is not too tricky, this is usually work of the repo manager).
The situation with CMake is trickier as the files are new (but related to Makefiles), so git doesn't trigger any conflicts and the files need to be re-read by hand (eye) again carefully. I suggest two solutions to this: merge cmake stuff early in (even if not used yet), keep using makefiles and ask anyone changing some logic in makefile to fix the change in cmake too (or atleast #TODO it). Other way would be you ignore the (more or less) minor changes in master for now, and when you feel ready we all reread the files and try to spot differences and fix them.. With best regards, Mark On Wed, Sep 11, 2013 at 12:53 AM, David Ragazzi <[email protected]>wrote: > Hi Matt and Mark, > > My fear is the famous "war of commits". In my case with CMake, I spent > several hours (to not say weeks) working on convert Autotools files to > CMake in addition to port Nupic c++ files to Windows. However repo state > changes everyday, and so CMake files (that still are in PR) couldn't > accommodate these future new changes (a new file, some new build flag, > etc). So rework is inevitable until CMake PR being finally analysed. > > My suggestion (from my brief experience with open-source) to avoid rework: > - You could group PR by function (ex: build, core algorithm, support code, > etc) and rank them according that they are delivered to you in order that a > PR don't makes conflicts with others. Ex: someone create a pull request > changing some simple compiler flags, however there's already an another PR > that change 80% of the same Makefile with this flag. If the commit of the > first developer is accepted (even he requested later), the second one will > have to rewrite his Makefile to accommodate this new change (what means > compare file to file in order to avoid loose code). But if the commit of > the first developer is accepted, then we have a logical and fair sequence > and so we avoid loose code in this "war". I mean we could have a FIFO > (first in, first out) sequence for analysis of pull requests (when > convenient, of course). > > Only my suggestion, please do not get me wrong. > > Best regards, David > > -- Marek Otahal :o)
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
