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. > When looking at the commits after a week of absence, I should get an easy > overview of which features are being developed To me new branch is worth for work like bigger chunk of lyx2lyx commits done last year by Richard or perhaps IPA-inset from last days. If these get branches you have easy overview of features developed but I believe that most of nowadays commit traffic doesn't belong to this category. It's rather chaotic mixture of cherishing things here and there and trying to impose branch structure on that is more annoying tham having not so clean history. > Would it be better for you if you could commit directly on the staging repo > of my proposal ? Yes, probably (Richard's note about being overwhelmed apllies to me as well, I don't see clearly into your proposal.) > In principle, one should see this staging repo as current trunk. 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. 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? > You only have to test the less stable one. You mean staging, right? Pavel
