Stop the git abuse

[Stanislav Ochotnicky]

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 at redhat.com>
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120521/b023f495/attachment.sig>