Re: Announcing creation of Fedora Source-git SIG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux