Hello,
On Tue, Dec 1, 2009 at 2:09 AM, Michael J Gruber
<git@xxxxxxxxxxxxxxxxxxxx> wrote:
> 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.
>
"Derived" in my case means that E is processed from a snapshot of the
tree at, say, A.
> Are these diagrams really disconnected from each other?
Yes. I started the history of E with plumbing using git commit-tree,
without a -p flag specifying a parent
>
>> 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?
>
I wish to be concrete, so let us suppose you use a default clone of
git.git. Further, suppose you are on origin/master.
Then, with my patch,
git rev-list --bouquet
should be an---admittedly less efficient---equivalent to
git rev-list --all --not refs/remotes/origin/html
refs/remotes/origin/man refs/remotes/origin/todo
> Michael
>
Thanks,
Nathan Panike
--
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