gitk with submodules does not show new commits on other branches

gitk with submodules does not show new commits on other branches

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

Thanks,

Steve.

Re: gitk with submodules does not show new commits on other branches

[Jens Lehmann]

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.

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Jens Lehmann wrote:

> Am 22.06.2014 16:09, schrieb Stephen Kelly:

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

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Stephen Kelly 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?
> 
> 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.

Re: gitk with submodules does not show new commits on other branches

[Jens Lehmann]

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

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Jens Lehmann wrote:

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

Thanks. I see it the feature now.

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

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.

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

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.

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

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.

Re: gitk with submodules does not show new commits on other branches

[Jens Lehmann]

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.

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

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

Re: gitk with submodules does not show new commits on other branches

[Stephen Kelly]

Jens Lehmann wrote:

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

Right.

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

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