On 11.03.2013 01:07, Michael T. Pope wrote: > > On Sun, 10 Mar 2013 03:33:45 PM Michael Vehrs wrote: > > > We have fine-tuned the order in which modifiers are applied to such > a degree > > > that adding unattended production before or after the application of > > > other modifiers fails to produce the expected results. > > Quite so. Anything other than one call to applyModifier* per > production is doomed. > > > By the way, is there any rhyme or reason to the selection of commit > > > messages one receives? And I must say I find the old svn commit messages > > > rather more interesting than the new ones. > > Not quite sure what you are after here. I tend to look at the log with: > > alias glog='git log --pretty=oneline', so the logs look like this to me: > > ... > > 0035d58780f4a3512614d92114a86148f393a23d Tidy serialization #28, > ExportData. > > 89e1fd31b1709290a33de55ef117f82a733ca357 Add support for European > Nation Types to generated documentation. > > 5b140565d82656ef0ccc181459a1babeea44e41e Improve handling of founding > fathers in generated documentation. > > 19e1717119f3cf2d8e3b9c93822449ae140311eb Merge branch 'master' of > ssh://git.code.sf.net/p/freecol/git > > ... > > There is not much to be done about the monster hex commit id, which is > indeed less friendly than the svn counterpart. I have heard of > projects that started out doing some tagging scheme to get a > sequential numbering back, but apparently people either just got used > to the big tags or had to admit that with a distributed vcs the > central repo and any notion of strict commit sequentiality is just a > convention rather than a necessity, and indeed, potentially misleading. >
Actually, I meant the email notifications. In the svn days, I got an email for every commit, containing the commit message, the files changed and up to 100k of diff. That was quite useful for keeping up to date. Today, I occasionally get an email when something is pushed to git, but I haven't figured out when that happens, yet. And the mail only contains the commit message, which is a lot less informative. > We can safely assume you are not concerned by your own text, and > hopefully not about the ongoing "Tidy serialization" series, which are > unimaginative but needed and with several more to go:-S. The > > "Merge branch 'master' of ssh://git.code.sf.net/p/freecol/git" > > is less informative. I think these happen when merging into master > from a branch that is not based on the current version of master. I > avoid that by doing a "git rebase master" from a branch I am about to > commit as that allows you to sort out any conflicts safely within that > branch context. Then (assuming that master is up to date wrt > sourceforge), the subsequent "git checkout master; git merge <branch>; > git push"[1] is then guaranteed to proceed cleanly, and the merge will > be a so-called "fast-forward" merge which does not generate "Merge > branch 'master'" messages. However, this is more a case of making a > virtue of a necessity--- when the last step was for git to push to the > svn repo there was some limitation that *only* allowed fast-forward > merges. So we have a new choice between less work and a cleaner commit > log. I do not have a strong preference, just a habitual working > method. Less work is good too. > > Cheers, > > Mike Pope > Regards Michael > [1] Which I tend to follow up with a call to following: > > #! /bin/sh > > # Rebase all branches to master, except those marked "old*", "_*" and > numeric > > # branches (which are usually releases). > > # > > for b in `git branch | sed -e '/^..master$/d' -e '/^..[0-9]/d' -e > '/^.._/d' -e '/^..old/d' -e 's/^..\(.*\)$/\1/'` ; do > > if git checkout -q "$b" ; then > > if git rebase master 1> /dev/null 2>&1 ; then > > echo "$b OK" >&2 > > else > > git rebase --abort > > echo "$b Failed" >&2 > > fi > > fi > > done > > git checkout master > > ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
