On Thu, Apr 15, 2021 at 04:30:26PM +0200, Tomas Tomecek wrote:
Daniel, thank you for sharing your experience!
More comments inline.
On Wed, Apr 14, 2021 at 5:26 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote>
> > 4. Some project have a weird git workflow between minor releases. I know at
> > least one project that uses Git tags with cherry-picked and manually
> > backported commits. Such detached tags cannot be merged into master branch
> > without resolving merge conflicts.
>
> I woudn't expect Fedora to track the git-master in most cases. You
> generally still want Fedora to be base off releases, so you'd want
> to track starting fron a release tag or branch.
Correct, the branches are meant to use upstream release git-tags as a base.
> > 5. Force pushes must be enabled, which is too dangerous IMO.
>
> There are several ways you can do source git and they don't all
> imply force pushes, so I think this is probably inventing a
> problem where none yet exists.
>
> One example approach to source-git I've used...
>
> Rather than having source-git branch names matching dist-git,
> use a different naming convention that is based off the upstream
> version primarily.
>
> eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33'
> branch, and if I rebase Fedora to v1.2, then I'd just switch to
> using a v1.2-f33 branch instead. The v1.0-f33 history remains
> intact forever, no force push required to rebase to new version.
>
> If upstream has stable branches v1.0-maint and v1.2-maint, then
> v1.0-f33 branch might be initialized with v1.0-maint content.
> If upstream adds more commits to v1.0-maint branch, then you
> wouldn't force push v1.0-f33, you'd just do a git merge to pull
> them in.
That's interesting: merge commits make it hard to work with the
git-history - how do you solve that? Daniel, does your tooling account
for a merge commit and is it able to still pick up commits and turn
them into patch files correctly?
I've not actually hit situations where I've needed merge commits
in general, except by my own mistake. My tooling merely consists
of running "git format-patch vN.M..." where "vN.M" is the tag
associated with the release the RPM is based off.
Our current solution to rebases is to create new branches for every
upstream release.
Yes, that's the good way IMHO. I was only mentioning merge commits
in the context of tracking changes within a release stream. eg some
projects may have stable branches in their upstream git, but don't
do releases off them very frequently. So you'd conceivably want to
periodically do a merge against upstream stable branche.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|