4 ms·

Fascinating. Can someone detail the pros/cons of this? Are they copying/cherry-picking commits from a dev track?

justinlaster 10y ago
Probably rebasing more than anything. cherry-picking is a messier, yet easier way to get the same history, you just need to clean up after yourself. Merge commits are useful, in my opinion, if there was significant work done to get two branches to "align" with each other. Otherwise, just rebase your work for a cleaner history. So in short: Merging: More "accurate" history about the work done to bring the work into the main/dev branch, yet messier. Rebasing/cherry-picking: cleaner history, potentially at the expense of context and "accurate" history about the work done to bring in code to the main/dev branch.
vog 10y ago
I think that's the only explaination.
geekone 10y ago
Might be dated, but check out the No Merge Commits section of the article at https://lwn.net/Articles/409635/ https://lwn.net/Articles/409635/ for possible reasoning they had/have.
deleted 10y ago
[deleted]
anarazel 10y ago
I think there's two different discussions here. One about cherry-picking for back-branch releases, one about development for the new version. Re back-branches: It's not particularly practical to use merges from/to stable branches. It may sound nice at first, but there's enough fixes that don't apply to all versions (because a feature didn't exist yet, because refactorings made bugs "accidentally" disappear, ...) that merging either to or from back-branches leads to very very messy merges, where the merge commit has to back out changes and such. I don't know of any larger project that successfully uses merges to merge to/from stable branches. So yes, it's just cherry-picking. Re development: The case here is a lot less clear. The project used CVS for a long while, and during the migration it was decided to not make the migration harder by changing workflows even more significantly than just CVS->git. So the, enforced, policy became that no merge commits are to appear. It hasn't become a significant problem since, so that policy hasn't evolved at this point. Given the relatively small number of active committers in the project, and the fact that commits in the project are expected to "stand on their own" (i.e. are complete and working), rebasing changes before committing them isn't a problem. Several contributors, including committers, do their development in separate repositories / branches, however. But usually the history there is messy enough that they wouldn't be merged anyway. I think merging is more of a benefit when you have a more hierarchically organized project like the kernel, with subsystem maintainers that aggregate a large volume of changes, which then get pushed to Linus, who then integrates all of those. Hope that roughly answers your question? If not, feel free to ask more about specifics. (For context: I'm one of the committers in the project)
- anarazel 10y ago
  Oh, and because it's relevant for the question: There's a tool in the tree (https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/tools/git_changelog;hb=HEAD https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f...) that shows (by heuristics) which branches a commit has been cherry-picked to. Looks like this: Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [9d4ca0131] 2017-01-26 12:18:07 -0500 Branch: REL9_6_STABLE [2dfc12647] 2017-01-26 12:17:47 -0500 Branch: REL9_5_STABLE [423ad86f4] 2017-01-26 12:17:47 -0500 Branch: REL9_4_STABLE [2c1976a6c] 2017-01-26 12:17:47 -0500 Branch: REL9_3_STABLE [2e024f83b] 2017-01-26 12:17:47 -0500 Branch: REL9_2_STABLE [fe6120f9b] 2017-01-26 12:17:47 -0500 Ensure that a tsquery like '!foo' matches empty tsvectors. !foo means "the tsvector does not contain foo", and therefore it should match an empty tsvector. ts_match_vq() overenthusiastically supposed that an empty tsvector could never match any query, so it forcibly returned FALSE, the wrong answer. Remove the premature optimization. Our behavior on this point was inconsistent, because while seqscans and GIST index searches both failed to match empty tsvectors, GIN index searches would find them, since GIN scans don't rely on ts_match_vq(). That makes this certainly a bug, not a debatable definition disagreement, so back-patch to all supported branches. Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me. Discussion: https://postgr.es/m/20170126025524.1434.97828@wrigleys.postgresql.org Edit: fighting with formatting #2
  - richardwhiuk 10y ago
    This is fairly easy to do, if you enforce a policy of requiring cherry-picks to reference the original commit (i.e. requiring -x in the git cherry-pick command). You can the grep the log for all the commits which contain the commit ID you are interested in (and any that mention those commits).
    - anarazel 10y ago
      That's not always that helpful, because you often will want to cherry-pick from another branch than master. E.g. when cherry-picking a change from master into 9.6, 9.5, 9.4, 9.3, 9.2 it'll e.g. often be easier to cherry-pick from 9.3 into 9.2, rather than master into 9.2 (due to conflicts increasing the further back you go). Obviously you could do that manually or script it regardless. But the current heuristics have worked without problems for years, so there seems little reason to change things ;)

Probably rebasing more than anything. cherry-picking is a messier, yet easier way to get the same history, you just need to clean up after yourself. Merge commits are useful, in my opinion, if there was significant work done to get two branches to "align" with each other. Otherwise, just rebase your work for a cleaner history. So in short: Merging: More "accurate" history about the work done to bring the work into the main/dev branch, yet messier. Rebasing/cherry-picking: cleaner history, potentially at the expense of context and "accurate" history about the work done to bring in code to the main/dev branch.

vog 10y ago

I think that's the only explaination.

geekone 10y ago

Might be dated, but check out the No Merge Commits section of the article at https://lwn.net/Articles/409635/ https://lwn.net/Articles/409635/ for possible reasoning they had/have.

deleted 10y ago

[deleted]

anarazel 10y ago

I think there's two different discussions here. One about cherry-picking for back-branch releases, one about development for the new version. Re back-branches: It's not particularly practical to use merges from/to stable branches. It may sound nice at first, but there's enough fixes that don't apply to all versions (because a feature didn't exist yet, because refactorings made bugs "accidentally" disappear, ...) that merging either to or from back-branches leads to very very messy merges, where the merge commit has to back out changes and such. I don't know of any larger project that successfully uses merges to merge to/from stable branches. So yes, it's just cherry-picking. Re development: The case here is a lot less clear. The project used CVS for a long while, and during the migration it was decided to not make the migration harder by changing workflows even more significantly than just CVS->git. So the, enforced, policy became that no merge commits are to appear. It hasn't become a significant problem since, so that policy hasn't evolved at this point. Given the relatively small number of active committers in the project, and the fact that commits in the project are expected to "stand on their own" (i.e. are complete and working), rebasing changes before committing them isn't a problem. Several contributors, including committers, do their development in separate repositories / branches, however. But usually the history there is messy enough that they wouldn't be merged anyway. I think merging is more of a benefit when you have a more hierarchically organized project like the kernel, with subsystem maintainers that aggregate a large volume of changes, which then get pushed to Linus, who then integrates all of those. Hope that roughly answers your question? If not, feel free to ask more about specifics. (For context: I'm one of the committers in the project)

anarazel 10y ago
Oh, and because it's relevant for the question: There's a tool in the tree (https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/tools/git_changelog;hb=HEAD https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f...) that shows (by heuristics) which branches a commit has been cherry-picked to. Looks like this: Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [9d4ca0131] 2017-01-26 12:18:07 -0500 Branch: REL9_6_STABLE [2dfc12647] 2017-01-26 12:17:47 -0500 Branch: REL9_5_STABLE [423ad86f4] 2017-01-26 12:17:47 -0500 Branch: REL9_4_STABLE [2c1976a6c] 2017-01-26 12:17:47 -0500 Branch: REL9_3_STABLE [2e024f83b] 2017-01-26 12:17:47 -0500 Branch: REL9_2_STABLE [fe6120f9b] 2017-01-26 12:17:47 -0500 Ensure that a tsquery like '!foo' matches empty tsvectors. !foo means "the tsvector does not contain foo", and therefore it should match an empty tsvector. ts_match_vq() overenthusiastically supposed that an empty tsvector could never match any query, so it forcibly returned FALSE, the wrong answer. Remove the premature optimization. Our behavior on this point was inconsistent, because while seqscans and GIST index searches both failed to match empty tsvectors, GIN index searches would find them, since GIN scans don't rely on ts_match_vq(). That makes this certainly a bug, not a debatable definition disagreement, so back-patch to all supported branches. Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me. Discussion: https://postgr.es/m/20170126025524.1434.97828@wrigleys.postgresql.org Edit: fighting with formatting #2
- richardwhiuk 10y ago
  This is fairly easy to do, if you enforce a policy of requiring cherry-picks to reference the original commit (i.e. requiring -x in the git cherry-pick command). You can the grep the log for all the commits which contain the commit ID you are interested in (and any that mention those commits).
  - anarazel 10y ago
    That's not always that helpful, because you often will want to cherry-pick from another branch than master. E.g. when cherry-picking a change from master into 9.6, 9.5, 9.4, 9.3, 9.2 it'll e.g. often be easier to cherry-pick from 9.3 into 9.2, rather than master into 9.2 (due to conflicts increasing the further back you go). Obviously you could do that manually or script it regardless. But the current heuristics have worked without problems for years, so there seems little reason to change things ;)