Quoting Michael J Gruber (2012-05-21 11:52:40)
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.
You can already do that. Put most important message (subject) as the
first item in changelog. Do "fedpkg commit -c".
+ (maybe) make systematic use of tags, e.g. git tag $(fedpkg verrel)
Yeah. koji should tag repos after build finishes.
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.
That was *so* not my idea. I am against allowing non-ff merges.
It would make verification of rpms impossible. No, when I was talking
about merging I always meant fast-forward only merges. Spec files are
not very suitable for common merges, but if someones wants to do it...be
my guest. I would hate to touch such repo though.
As Kevin said in other messages: ff-merges don't hide anything, don't
clutter logs. The only "downside" is that changelog will contain those
mass rebuild items. That seems like a valid price to pay for simplifying
work of so many people.
That said, I would be in favour of generating changelogs from git logs.
Yes, they will contain more detailed information. So what? I would
gladly sacrifice a bit of changelog readability for huge amount of work
deduplication.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc.
http://cz.redhat.com