Sérgio Basto venit, vidit, dixit 18.05.2012 22:25: > On Sex, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote: >> I've been seeing this ugliness more and more to the point where I just >> can't keep writing individual emails. Repeat after me: git is not CVS. >> >> When you have 2 branches with identical content and history (typically >> right after branching or when the maintainer is updating all releases >> together) then DO NOT manually redo fix for every branch. Do not even >> use cherry-pick! Just *merge* for the love of whatever is holy to you. >> >> $ git checkout master (or fedpkg switch-branch) >> ... do a fix, test, commit, build etc... >> $ git checkout f17 >> $ git merge master >> $ git/fedpkg push && fedpkg build >> DONE > > this git process is describe here: > http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Update_Your_Branches_.28if_desired.29 > > > but should also be in http://fedoraproject.org/wiki/Package_update_HOWTO > or maybe better, where : > https://fedoraproject.org/wiki/Using_git_FAQ_for_package_maintainers#How_do_I_import_a_SRPM_package.3F > > >> >> So please. Merge as long as it makes sense (i.e. unless something needs >> to be changed specifically in one branch). >> >> Thanks, >> > > Thanks, Just like we have mandatory packaging guidelines, we should have mandatory git guidelines simply because it is part of the build system, not just a random developer's source repository. And yes, every sane project uses a merge based approach (either "down" or "up"). The main points should be: * work on master=rawhide for adjustments to upstream changes * merge down to release N, release N-1 and so on as far as they still get updates * merge to epel from the respective base fedora; or from master then epel cascade (to be specified in epel guidelines) * put compatibility cludges for older releases on their respective branches (this gets rid of many if's in spec) * use standardised commit messages, e.g.: - subject line as a short summary (for the commit notification e-mails) - message body in the style of current changelog That way fedpkg update and buildsys can extract what they need for the build messages as well as the rpm changelog. + (maybe) make systematic use of tags, e.g. git tag $(fedpkg verrel) Note that the biggest git-offenders these days are the build and release scripts (automatic rebuild and such)! And there's no way to override this by a rewrite because of the installed hooks permitting only fast-forwards. Michael -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
