Sorry little reant ahead: In general, merge commits are hideous, they can conceal merge conflict resolution that can a) introduce bugs, b) make it hard to figure out when bugs were introduced by preventing use of git bisect and c) generally make it very hard to understand the history of changes. In general rebase and squash requirement tend to generate much cleaner changes, and catches errors before they are merged. Merge commits are useful for gigantic projects like the Linux kernel where A) the maintainers are extremely knowledgeable and can properly resolve merge conflicts B) the people proposing the merge may not actually know how to properly resolve a merge conflict as it is happening outside of their area of expertise C) the feedback loop would be excessive and dwarf the history linearity benefits. Those projects are rare, using merge commits on small projects is just lazyness that you pay later. It's accruing technical debts unnecessarily. That said, for non-code projects history may no matter that much, as you do not need to resolve "bugs", and introducing "bugs" via merge commits conflict resolution is rare, so for those it may not matter what do you use to merge in stuff, you are using the SCM just as a central repository and "merge tool" and sometimes as a way to apply release tags. Whenever using the history is useful I find I *really* hate merge commits as they muddy everything, and make the work of figuring out what happened after the fact (and sometimes *during the fact*) very hard. Simo. On Tue, 2020-05-05 at 15:29 +0200, Ondřej Lysoněk wrote: > Tomas Tomecek <ttomecek@xxxxxxxxxx> writes: > > > Thank you all for raising all the questions and concerns. > > > > Before I reply, I'd like to stress that we are still in a prototype > > phase - not everything is solved (clearly) and at this point, we > > experiment with the workflow mostly. > > > > Luckily, force-pushes are not allowed in dist-git, which makes the > > update/sync process easier (knowing that history cannot be changed). > > Therefore when a new commit lands in dist-git, we'd just "transform" > > it to source-git and pushed it to the source-git repo. We could even > > ask all the contributors to rebase their PRs when this happens. > > This "rebase all PRs" thing seems to be a recurring theme... What is the > reason to ask contributors to rebase? (I mean, are we trying to go back > to the days of centralized version control systems?) > > In my experience, there is rarely a good reason to rebase (rebasing > because the CI system tests the contributor's branch rather than the > resulting merge is not a good reason; the CI system should be fixed > instead) and asking everyone to rebase just slows things down. Please > let's not go down that road, if possible. > > Other than that, I like the idea of source git and I'm looking forward > to using it, once the synchronization issues are resolved. Thanks for > working on it. > > Ondřej Lysoněk > > > On the other hand, when a new commit lands in the source-git repo, we > > could either transform and push to dist-git directly or open a PR. The > > maintainer should be in control of this process. > > I understand the synchronisation adds friction to the overall > > architecture and may be the cause of many problems in the future - > > hence we are starting this discussion and using the technology > > ourselves to catch these issues asap. Víťo, does this answer your > > question? > > > > Miro, you are talking about conflicts: I'd say that conflicts on the > > git level are normal and git has solid tools to resolve them. For the > > use case of 2 different people changes the same thing, we would treat > > dist-git as the authoritative place and let the person in source-git > > know about the conflict. But this can happen nowadays easily as well: > > 2 different people can open the same PR or even push to dist-git > > directly while only one would succeed. > > > > Petr, I should have probably stressed that our target is Fedora (or > > even all Red Hat operating systems). Yes, there are hundreds of > > distributions and we cannot solve their problems. We are open for > > collaboration though - we cannot drive changes in distributions which > > we don't know or use. > > > > > > Tomas > > > > On Tue, May 5, 2020 at 8:56 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote: > > > On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote: > > > > Over the years there have been multiple tools created to improve the > > > > development experience: > > > > rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g. > > > > the way Fedora kernel developers work on kernel [k]). > > > > > > > > In the packit project, we work in source-git repositories. These are > > > > pretty much upstream repositories combined with Fedora downstream > > > > packaging files. > > > > > > And then come another distribution with a request to combine its dist-git into > > > the upstream. Fedora is not the only distribution. Do you know how many > > > distributions exist? From my point of view as a upstream it's one big NO. > > > > > > From point of view of a Fedora packager, it's just moving Fedora bits into > > > another repository with the burden of synchronizing that repository with > > > dist-git (and back because of what an authoritative source for Fedora is). > > > > > > If you want to introduce an intermediary third repository between the upstream > > > and the distribution, a repository that would normalize (read git-ify) the > > > upstream and overlay downstream patches and metadata, then, ehm, it's a nice > > > project for exploration how far we go with unification among the > > > distributions. But I'm quite sceptical regarding it's adoption. But don't take > > > my prognosis seriously. I can be mistaken. There are some positive prior arts > > > like release-monitoring.org. > > > > > > -- Petr > > > _______________________________________________ > > > 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 > > _______________________________________________ > > 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 > _______________________________________________ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
