Op 14-3-2012 14:11, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
I see that in some cases of 2. additional commit are applied but we
shouldn't value clean commit history at such high rates.
These additional commits are the number 1 reason for me to propose what I
proposed. To my liking, there are way too many commits that fix a typo, fix
a warning on a different platform, fix a commit error, fix whitespace, fix
monolithic build, commit a forgotten file, etc.
Yes, that's where we disagree. I don't see these additional commits as
good enough reason to drown people in branching mania. Unless someone
develops new nifty feature or particularly tough bug, he shouldn't
recognize there is some difference between svn and git.
You seem to have an aversion to branches, while I can't work without
them anymore.
Fine. If I understand correctly the shift "stage"->"devel" stable can
help you to rewrite history (e.g. by merging fix of fix commits). So
then we would have 2 incompatible histories in two repos.
No, the staging repo has no own fixed history.
Now, you plan to to replace "stage" after main release by "devel" tree
and start from there again development, now with clearer history? What
commit checksum is primary for the pruposes of trac for example then?
Whenever a feature gets into the official repo, it will not change
anymore, and the sha1 will be definite.
You only have to test the less stable one.
You mean staging, right?
Yes.
Vincent
