Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH/RFC] Add a --bouquet option to git rev-list

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:48

"Nathan W. Panike" [off-list ref] writes:
quoted
quoted
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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help