{"thread":{"id":"60653","subject":"[FEATURE REQUEST] New method of commits range selection","startedAt":"2023-12-25T02:07:25Z","lastAt":"2023-12-25T02:07:25Z","messageCount":1,"participants":["Andry"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"486018","messageId":"31177532.20231225050845@inbox.ru","threadId":"60653","inReplyTo":null,"subject":"[FEATURE REQUEST] New method of commits range selection","fromName":"Andry","fromEmail":"andry@inbox.ru","sentAt":"2023-12-25T01:08:45Z","receivedAt":"2023-12-25T02:07:25Z","isPatch":false,"sender":{"key":"andry@inbox.ru","avatar":null},"body":"Hello Git,\n\nI've described the details in the GitHub discussion: https://github.com/orgs/community/discussions/56342#discussioncomment-7882789\n\nBut because the problem is related to the Git commands like `git log`: https://git-scm.com/docs/git-log\n\nThen I think it have to requested from the Git developers.\n\n---\n\nEven more reliable variant is to reverse the second end point search direction in the commit range.\n\nInstead of search from the top to the bottom of a tree beginning a branch tip, there is another way to search from the bottom to the top beginning a commit or a tag. This is better because there is no need to exclude anything else, because the search path is an intersection of both search directions in any potential tree if both ends exists.\n\nExamples:\n\nSearch from the top to the bottom:\n\nrange: `d3^...dev`, where `...dev` - includes and searches back, `d3^...` - excludes first parent and searches back\n\n```\nExample #1               Example #2\n\nm1 -o- master            m1 -o- master\n    |                        |\n    |   o- d1 dev            |   o- d1 dev\nm2 -o   |                m2 -o   |\n    |\\  |  o- tags/t1        |\\  |  o- tags/t1\n    | \\ | /                  | \\ | /\nm3 -o  \\|/               m3 -o  \\|/\n    |   o- d2                |   o- d2\n    |  /|                    |  /|\n    | / |                    | / |\n    |/  |                    |/  |\nm4 -o   |                m4 -o   |\n    |   o- d3                |\\  |\n    |  /                     | \\ |\n    | /                      |  \\|\n    |/                       |   o- d3\nm5 -o                        |  /\n                             | /\n                             |/\n                         m5 -o\n```\n\nSelection result:\n\nExample `#1`: `d1, d2, m4, d3`\nhttps://github.com/andry81-tests/commits-range-selection-test-1/compare/d3^...dev\n\nExample `#2`: `d1, d2, m4, d3`\nhttps://github.com/andry81-tests/commits-range-selection-test-2/compare/d3^...dev\n\nTo exclude the master commits, there is need to add more exclusions: `{d3^,m4}..dev`\n\nThis will give invalid selection for the second example, because `d3` would be excluded from `m4`, because we need to include *at least* all `dev` commits.\n\nInstead of add more exclusion, we can just reverse the second end point search direction: `--intersect d3..dev`, where `..dev` - includes and searches back, `d3..` - includes and searches forward.\n\nSelection result:\n\nExample `#1`: `d1, d2, d3`\nExample `#2`: `d1, d2, m4, d3`\n\nThis does not require to actually search from the `d3` up, because only requires to collect all merge commits down from the `dev` which might has path to the `d3`.\n\nIt does not exclude all the master branch commits, but gives a cleaner result without additional excludes.\n\n"}]}