Nathan W. Panike venit, vidit, dixit 30.11.2009 21:55:
> Add a command line option to rev-list so the command 'git rev-list --bouquet'
> shows all revisions that are ancestors of refs which share history with HEAD.
>
> Signed-off-by: Nathan W. Panike <nathan.panike@xxxxxxxxx>
> ---
> I have a repository with the following structure:
>
> B
> /
> A'--A--C
> \
> D
>
> E'--E
>
> Thus the command 'git merge base E A' returns nothing, as there is no common
> history. The E history contains stuff that is derived from the other history
> (A, B, C, or D). Often I find myself doing the following:
Either I don't understand the diagram or your term "derived". If
"derived" means "on some branch of a merge" and E is derived from A, B,
C, or D, then (since B, C, D is derived from A, and from A') E is
derived from A', and they will have a merge base.
Are these diagrams really disconnected from each other?
> git checkout C
> gitk $(include_forks) &
> <View history, make changes, merges, et cetera>
> git checkout E
> <go back to gitk, only see history for B, C, etc>
>
> Now the 'include_forks' command is a bash function in my .bashrc:
>
> 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)"
> }
>
> The shell thus intercepts my command and I must restart gitk to see the history
> of E.
>
> With this patch, I can issue the command 'gitk --bouquet' and when I checkout
> E, I can 'reload' in gitk and see the history of E automatically.
What would your patch do in the example you gave above? Which refs would
it cause gitk (rev-list) to show?
Michael
--
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