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@xxxxxxxxxx> 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 :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
