Skip to content

git-merge-base: add page #9382

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Dec 11, 2022
Merged

git-merge-base: add page #9382

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
878c90a
git-merge-base: add page
Lodifice Oct 27, 2022
fb20dc1
git-merge-base: improve wording
Lodifice Oct 29, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions pages/common/git-merge-base.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# git merge-base

> Find a common ancestor of two commits.
> More information: <https://git-scm.com/docs/git-merge-base>.

- Output a best common ancestor of two commits:

`git merge-base {{commit_1}} {{commit_2}}`

- Output all best common ancestors of two commits:
Copy link
Collaborator

@navarroaxel navarroaxel Oct 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

best can only be 1.

Suggested change
- Output all best common ancestors of two commits:
- Print all merge bases for two commits:

Copy link
Contributor Author

@Lodifice Lodifice Oct 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the way git weighs merge bases, there actually can be two "best" ones, which means two of the same quality. But I agree that the wording is confusing, so maybe "all suitable" should be used?

Copy link
Collaborator

@navarroaxel navarroaxel Oct 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok


`git merge-base --all {{commit_1}} {{commit_2}}`
Copy link
Collaborator

@navarroaxel navarroaxel Oct 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`git merge-base --all {{commit_1}} {{commit_2}}`
`git merge-base --all {{commit1}} {{commit2}}`

Copy link
Member

@CleanMachine1 CleanMachine1 Nov 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not commit_hash instead

Copy link
Contributor Author

@Lodifice Lodifice Nov 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the git subcommand pages are not consistent in this matter, but the majority uses just commit.

Copy link
Contributor

@EmilyGraceSeville7cf EmilyGraceSeville7cf Dec 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the git subcommand pages are not consistent in this matter, but the majority uses just commit.

It means that consistency should be fixed. For instance we can write script to do that like in #9578 PR.


- Return 0 if the first commit is an ancestor of the second commit, else 1:

`git merge-base --is-ancestor {{commit_1}} {{commit_2}}`