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.

Thanks,

Steve.

Am 22.06.2014 16:09, schrieb Stephen Kelly:

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.

This should not happen by default. If you have a feature branch based
workflow, the merge is just what you want to see. And "git submodule
summary" is giving you the exact same information.

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? Then the
user could examine the merges in more detail if he wants.

Jens Lehmann wrote:

Am 22.06.2014 16:09, schrieb Stephen Kelly:

quoted

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.

In my case, it is not what I 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?

Thanks,

Steve.

Stephen Kelly wrote:

quoted

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?

In particular, I don't see it in my git gui. Is it only in master?

My versions:

 git-gui version 0.18.0.14.g1b2c7
 git version 1.9.1

 Tcl/Tk version 8.6.1
 Aspell 0.60.7-20110707, en_US

Thanks,

Steve.

Am 22.06.2014 17:45, schrieb Stephen Kelly:

Jens Lehmann wrote:

quoted

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

Jens Lehmann wrote:

Am 22.06.2014 17:45, schrieb Stephen Kelly:

quoted

Jens Lehmann wrote:

quoted

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

Thanks. I see it the feature now.

Jens Lehmann wrote:

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? Then the
user could examine the merges in more detail if he wants.

Such a menu entry might be useful,  but it is still different workflow. It 
would be useful in the 'that commit sounds interesting - show me' case. I 
would need to see the commit title to know if it sounds interesting though. 

Your suggestion involves a different window and context, but all I want to 
see is a list of commit titles so I can press 'up' to see the next ones, not 
have to close a window first before I can see the next list, and then have 
to right-click to see the list of commits.

Is it so difficult to list the titles of all of the newly-reachable commits? 
Even with a config option? Even an undocumented option? 

Failing all of that, can you show me where the code would need to be changed 
to list all of the newly-reachable commits? I can keep a commit for myself 
then.

Thanks,

Steve.

Stephen Kelly wrote:

Failing all of that, can you show me where the code would need to be
changed to list all of the newly-reachable commits? I can keep a commit
for myself then.

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.

Thanks,

Steve.

Stephen Kelly wrote:

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.

Thanks,

Steve.

Am 23.06.2014 20:24, schrieb Stephen Kelly:

Stephen Kelly wrote:

quoted

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.

quoted

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.

Yup, I think that's the core of the change necessary to help
your workflow.

Jens Lehmann wrote:

Am 23.06.2014 20:24, schrieb Stephen Kelly:

quoted

Stephen Kelly wrote:

quoted

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.

Right.

quoted

quoted

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.

Thanks for your help!

quoted

I dug deeper and came up with this patch which suits my needs:

Yup, I think that's the core of the change necessary to help
your workflow.

Ok, so I guess we can add --summary=commits ?

I don't write C code generally, so I'm not certain how that needs to be 
propagated.

Thanks,

Steve.