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#Upd...
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_...
>
> 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