Stop the git abuse

[Michael J Gruber]

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