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#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. 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@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
Attachment:
signature.asc
Description: signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
