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

From: Nathan W. Panike <nathan.panike@gmail.com>
Date: Dec 1, 2009, 17:31 UTC
Message-ID: <d77df1110912010931l40472723v80ad675a92d23fa3@mail.gmail.com>
In-Reply-To: <4B14CF47.5020808@drmicha.warpmail.net>

Hello,

On Tue, Dec 1, 2009 at 2:09 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 25 quoted lines

> 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@gmail.com>
>> ---
>> 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

Show 27 quoted lines

>
>> 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