How to use git merge-base on remote?

Question

How can use merge-base with Git on a remote repository without checking it out? Using ls-remote works fine e.g. for determining branches like this:

git ls-remote --heads $REPO_URL/$REPO_NAME

The documentation contains no clue, wether the use of merge-base with ls-remote is possible. Maybe it is also possible, to use alternatives to merge-base to find the common ancestor for branches/commits.

At the moment, i have to checkout the repository locally, which takes a lot of time for big projects.

Answer 1

In general, no: ls-remote shows you the commit IDs on the remote for the requested references, but for each commit-ID, if you do not have that commit locally you cannot determine its parent commit(s).

There is no need to check out the commits though. Just use git fetch to bring over any missing objects, and you will then have the full repository history. A future git fetch will continue to bring over only missing objects, which will be new objects that you would need anyway in order to find items.

I do not know what you are attempting to do with git merge-base but it requires only commit-IDs for all but the new --fork-point operation, where it uses your local reflog and therefore requires a local reference-name. For instance:

$ git merge-base 9b1c2a3a8e625ea7f56e9ba3d3c0e31938faa738 \
> bba6acb335e296ed692b4aea224b50fd098f693c
ebc5da3208824e25a89672a3b91bd13629b215fe

This tells me that the merge-base of 9b1c2a... and bba6acb... is ebc5da3.... (All of these are commit IDs within the repository containing the source to git itself.) And:

$ git branch -a --contains ebc5da3208824e25a89672a3b91bd13629b215fe
* master
  remotes/origin/maint
  remotes/origin/master
  remotes/origin/next
  remotes/origin/pu

tells us that the merge-base is contained within four remote branches: maint, master, next, and pu, plus the local branch master (which is in sync with origin/master anyway). More interestingly:

$ git describe ebc5da3208824e25a89672a3b91bd13629b215fe
v2.0.2

tells us that the merge-base is tagged as git version 2.0.2, so these two other commits (chosen arbitrarily out of the log) have common ancestry at that particular tag.