Thanks for sharing that, Simo. I respect your opinion. Believe me, I do like my git history clean and I go to great lengths to keep it clean. I certainly don't think I'm lazy when it comes to that. However, I don't think that maintaining a linear history helps with readability and understandability of the history. Quite the opposite - keeping the branching helps to see which changes are related and in what context a certain change was made. Just to be clear, when I say "rebase", I literally mean the act of changing the merge base. On the other hand, squashing commits and similar things to have a nice series of logical changes is a must for me. But I don't want to veer too much off topic here. I believe this was discussed at length in a LWN article (which just happens to be centered around the Linux kernel ;)). https://lwn.net/Articles/791284/ Ondřej Simo Sorce <simo@xxxxxxxxxx> writes: > 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 _______________________________________________ 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
