Stop the git abuse

[Michael J Gruber]

Stanislav Ochotnicky venit, vidit, dixit 21.05.2012 14:49:
> 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".

That is the other way round, but still better.

It's just that I've been burned by fedpkg surprises (read: my fedpkg
ignorance) so often that I much rather use git commands directly. I kind
of know my way around git...

>> + (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. 

Rewriting commits in the fedora-scm repo wasn't my idea either: I want
release scripts to play nicely so that no rewrite is necessary!

We do need to be able to create merge commits (as we are now), of
course, otherwise we wouldn't even need branches, or else they'd only be
moving tags on the same linear history.

At least, we need them to rejoin artificially diverged history...

> 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. 

Exactly!

Michael