gitk with submodules does not show new commits on other branches

> 
> Hello,
> 
> boost.git, is using submodules. 
> 
> If I run gitk after a pull, there are some messages along the lines of 
> 
> 
>     Update preprocessor from develop.
> 
>   Submodule libs/preprocessor 9d2d1ff..1422fce:
>     Merge branch 'master' into develop
> 
> 
> That is, it shows only the merge. 
> 
> If I then run 
> 
>  git log --oneline 9d2d1ff..1422fce 
> 
> I can see the commits which were made on master and then merged into 
> develop. Please show the same information (ie all commits newly reachable 
> from develop) in the submodule gitk output.

>> Please show the same information (ie all commits newly reachable
>> from develop) in the submodule gitk output.
> 
> This should not happen by default. If you have a feature branch based
> workflow, the merge is just what you want to see.

>> But I agree that this is suboptimal for your workflow. What about adding
>> a "Visualize These Changes In The Submodule" menu entry for the context
>> menu of a change in gitk just like the one git gui already has?
> 
> Can you tell me how to find and try that out in git gui?

> Jens Lehmann wrote:
> 
>> Am 22.06.2014 16:09, schrieb Stephen Kelly:
>> But I agree that this is suboptimal for your workflow. What about adding
>> a "Visualize These Changes In The Submodule" menu entry for the context
>> menu of a change in gitk just like the one git gui already has?
> 
> Can you tell me how to find and try that out in git gui?

> Am 22.06.2014 17:45, schrieb Stephen Kelly:
>> Jens Lehmann wrote:
>> 
>>> Am 22.06.2014 16:09, schrieb Stephen Kelly:
>>> But I agree that this is suboptimal for your workflow. What about adding
>>> a "Visualize These Changes In The Submodule" menu entry for the context
>>> menu of a change in gitk just like the one git gui already has?
>> 
>> Can you tell me how to find and try that out in git gui?
> 
> Sure, you'll find that in the pop-up menu when right clicking the
> submodule summary in the diff pane (where you can choose to stage
> or unstage hunks or lines for regular files).

> I see that gitk is showing the output of git diff --submodule, similar to
> git submodule summary.
> 
> Assuming that is not going to be changed, maybe I can hack
> parseblobdiffline locally. I have not really tried to read of write tcl
> code before though, so I'd still prefer a 'proper' solution somehow.

> I dug deeper and came up with this patch which suits my needs:
> 
> diff --git a/submodule.c b/submodule.c
> index b80ecac..0dacd61 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -297,7 +297,7 @@ static int prepare_submodule_summary(struct rev_info 
> *rev, const char *path,
>         init_revisions(rev, NULL);
>         setup_revisions(0, NULL, rev, NULL);
>         rev->left_right = 1;
> -       rev->first_parent_only = 1;
> +  rev->max_parents = 1;
>         left->object.flags |= SYMMETRIC_LEFT;
>         add_pending_object(rev, &left->object, path);
>         add_pending_object(rev, &right->object, path);
> 
> 
> The 'merge pull request' merges are only noise to me.

> Am 23.06.2014 20:24, schrieb Stephen Kelly:
>> Stephen Kelly wrote:
>> 
>>> I see that gitk is showing the output of git diff --submodule, similar
>>> to git submodule summary.
> 
> Right, and for your use case --submodule would have to learn a
> different value in addition to 'log' and 'short'. And the default
> is already configurable via the 'diff.submodule' config option.

>>> Assuming that is not going to be changed, maybe I can hack
>>> parseblobdiffline locally. I have not really tried to read of write tcl
>>> code before though, so I'd still prefer a 'proper' solution somehow.
> 
> I'd prefer a proper solution too, which is exactly why I tried
> to understand your use case first before speculating about how
> it could be solved.