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.
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
[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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
