"Nathan W. Panike" <nathan.panike@xxxxxxxxx> writes:
>>> include_forks ()
>>> {
>>> local head="$(git show -s --pretty=format:'%H' HEAD)";
>>> echo "HEAD $(git for-each-ref --format='%(refname)' \
>>> refs/heads refs/remotes | while read ref; do \
>>> if test "$(git merge-base HEAD ${ref}^{commit})" != ""; \
>>> then echo ${ref}; fi; done)"
>>> }
Because you have to traverse the entire history from tips of refs to know
if the histories to reach them are disjoint, this is fundamentally a very
expensive operation and will not scale to projects with deep histories.
If a low-level support for this kind of thing is necessary, then I do not
think it should just be "give me set of refs that is related to HEAD". I
suspect that is too inflexible to be useful in other situations.
A command to list refs (i.e. not as rev-list argument that shows list of
commits, but as a new feature of for-each-ref) with new criteria might
have wider use (I am just thinking aloud). Something like
- among these refs (you would specify this with --all, --heads, or prefix
'refs/heads refs/remotes'), list only the ones related to this and that
ref (here you would give HEAD or whatever you want to check with as
argument)"; and
- its counterpart "list the ones that are _not_ related" with the same
input.
As to the implementation, instead of running get_merge_bases() number of
times (a naive implementation would be O(n*m), I guess), I think it may
make sense to run the traversal in parallel, similar to the way done in
show-branches (but the termination condition would be different).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html