-
Notifications
You must be signed in to change notification settings - Fork 157
Documentation/git-merge-tree.adoc: clarify the --merge-base option #1980
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation/git-merge-tree.adoc: clarify the --merge-base option #1980
Conversation
The --merge-base option for merge-tree has a few slightly awkward
constructions or omissions:
* Split the initial long sentence describing the option into two,
making the instructions and the limitations clearer for readers.
* Add context to the final sentence that might be obvious to some
readers but isn't immediately obvious to all.
* The discussion about lack of support for multiple merge bases
simply leave folks wondering why that matters and could help or
hurt. Separate it out and add a brief explanation.
Signed-off-by: Elijah Newren <newren@gmail.com>
|
Ah, the usual Meson failures, and of course without any useful information (which probably was in Back when the idea was still to use CMake as the next build system, we did not have such unhelpful CI failures. Will re-run, 🤞that it will "magically succeed" now. |
dscho
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the original wording is on me. Sorry.
Thanks for digging into this for me.
Thanks, looks like it didn't work but since this is just a documentation change that couldn't cause those build failures, I think I'll just ignore it...
From blame, 2 of the 3 commits that led to the current wording was from Kyle Zhao (and most of the text was from those 2 commits), leaving only 1 to you. Regardless of what blame says, though, I was the reviewer of all three commits on the mailing list, so it's much more on me than on you. |
|
/submit |
|
Submitted as pull.1980.git.1759444487406.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
This patch series was integrated into seen via git@8d41f61. |
|
This branch is now known as |
|
This patch series was integrated into seen via git@eed6af7. |
|
This patch series was integrated into seen via git@cdc1761. |
|
This patch series was integrated into next via git@787ff6f. |
|
There was a status update in the "New Topics" section about the branch Clarify the "--merge-base" command line option in "git merge-tree". Will merge to 'master'. source: <pull.1980.git.1759444487406.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@bbc277f. |
|
This patch series was integrated into seen via git@9061279. |
|
There was a status update in the "Cooking" section about the branch Clarify the "--merge-base" command line option in "git merge-tree". Will merge to 'master'. source: <pull.1980.git.1759444487406.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@d513a6f. |
|
This patch series was integrated into seen via git@472c3f5. |
|
This patch series was integrated into master via git@472c3f5. |
|
This patch series was integrated into next via git@472c3f5. |
|
Closed via 472c3f5. |
Prepare config handling for the upcoming GitHub Action
This PR is part 3 of addressing #609, and it is stacked on top of #1980 and #1981 (and therefore contains also the commits of those PRs), therefore I will leave this in draft mode until those PRs are merged. The grand idea is to bundle the `CIHelper` class together with all its direct and transitive dependencies into one big, honking `dist/index.js`, and then add a set of really minimal GitHub Actions that call into `CIHelper`. The Actions are added in sub-directories so that they can be called in GitHub workflows via e.g. `- uses: gitgitgadget/gitgitgadget/update-prs@1`. The component used for bundling `CIHelper` is [`@vercel/ncc` ](https://www.npmjs.com/package/@vercel/ncc). To support acting as a GitHub Action, [`@actions/core`](https://www.npmjs.com/package/@actions/core) is installed. To allow for really minimal GitHub Actions, the `CIHelper` class is augmented accordingly to re-implement more logic that is currently either in `misc-helper.ts` or in the (non-public 😞) Azure Pipelines definitions. The naming convention for specifying the necessary tokens as GitHub Actions inputs is: - `upstream-repo-token`: This is to comment on PRs in `git/git` - `pr-repo-token`: This is to comment on PRs in `gitgitgadget/git` (as well as to be able to push to that repository) - `test-repo-token`: This is to comment on PRs in `dscho/git` (used exclusively for testing) To clarify, here is a diagram: ```mermaid graph TD user["user (contributor)"] upstream-repo["upstream-repo (authoritative project repo)"] pr-repo["pr-repo (GitGitGadget-enabled GitHub repo)"] GitGitGadget["GitGitGadget"] mailing-list["mailing-list"] user -->|"opens PR"| pr-repo user -->|"opens PR (if GitHub App installed)"| upstream-repo upstream-repo -->|"GitGitGadget syncs branches to"| pr-repo pr-repo -->|"slash commands"| GitGitGadget upstream-repo -->|"slash commands (if App installed)"| GitGitGadget GitGitGadget -->|"sends patch series"| mailing-list ```
No description provided.