Extend wstool info with branch data

[tkruse]

This depends on vcstools/vcstools#98 changes being merged and released first

This should supercede #35 which can be closed.

• test wstool info with diverse circumstances
• add --fetch option (probably requires another extension to vcstools
• fix info command for single repository wstool info xyz

[tkruse]

I have another idea, we could add a wstool command that invokes the respective VCS to give a summary:

git branch --list master -vv --no-color
hg summary --remote
bzr missing -S
svn status -u

The output would be a right mess in a chaotic workspace, but may still be useful. This could be combined with selecting all repos of one type, like wstool summary --git

An alternative would be to implement the feature request here
#29
such that something like wstool custom --git 'git branch --list master -vv --no-color'
would be possible.

[wkentaro]

Yeah, I think it is useful, so why don't we implement it as --summary option? like wstool info vcstool_0 --summary.
The options are:

• implement as another command
• implement as another option

and both is okay, but the version information is info so I think adding option is better.

Anyway, your another idea is as alternative to displaying remote branch in wstool-info-table, or another extention? I think adding remote-branch information to info-table is useful, and it should be another extention.

[wkentaro]

such that something like wstool custom --git 'git branch --list master -vv --no-color'
would be possible.

I think that kind of command is expected by many users. ( as an user of wstool I also )
in git, git submodule foreach "git pull origin master" is same.

This command is also useful and should be implement as another feature.
so I think (if possible) add following features are good::

1. Display remote version and branch in wstool info table.
2. Add --summary option as verbose version of wstool info. (it would be unable to be a table because too many information)
3. Add customcommand to execute custom commands in repos in workspace.

[tkruse]

Displaying the remote branch should go ahead as implemented already.

I believe the out put of the summary would be very different from info, and it would not be very compatible to the other --options of info (like --summary --yaml). So I would prefer that to be a command of it's own.

Also that should be a PR of it's own.

If you have the time, making a separate PR for a #29 implementation would be nice. The details of how to implement custom/foreach should be discussed at #29.

[tkruse]

@wkentaro: there is still an open bug, the new information is not displayed when specifying a single repository wstool info repo1. If you want, you can fix that, else I will do that tomorrow.

[wkentaro]

I made fix at: tkruse#7
Please review it.

[tkruse]

ok, I squashed all commits. The logic in cli_common.py is a nightmare to review, not sure what to do about it. Since the tests might break after vcstools/vcstools#99, it might be better to just wait until that one is done, adapt the tests / api calls, and then merge.

[wkentaro]

Any idea why the test fails
What should we do next?

[tkruse]

todo:

• new release of vcstools
• upgrade wstool dependency version to new release of vcstools
• wait for travis to build ok with new version
• release wstool

Possibly both vcstools and wstool could also be released in one step as a shortcut.

[wkentaro]

Alright, thanks.

[wjwwood]

It doesn't look like there are any outstanding pr's or issues that can be easily resolved on vcstools, so I'll go ahead and make a release. Then we can fixup this pr.

[wjwwood]

Ok, vcstools 0.1.37 is out. I'm still working on getting the deb synced to public, but it is in pip.

[wkentaro]

thanks.

upgrade wstool dependency version to new release of vcstools

I sent PR: tkruse#8

[tkruse]

rebased and merged dependency update

[wkentaro]

Moved to https://github.com/vcstools/wstool/tree/divergence ?
I mean origin/divergence not tkruse/divergence.

[tkruse]

yes, sorry, I get confused over remotes. fixed.

[wkentaro]

fails in Python2.6, please merge:
tkruse#11

[wkentaro]

test passed. so we need squash commits as next step?

[tkruse]

i think they are as squashed as they should. We wait for @wjwwood to merge

[wjwwood]

Thanks for the work on this guys.

[NikolausDemmel]

Thanks for this! It is oh-so useful.

What was the consensus on also showing which way the difference in commits between local branch is going (like e.g. <>, <, or > in the status line)? Is this still being discussed somewhere else?

This information would be extremely valuable for my use case where I often have local commits across multiple repos lying around until all repos are ready and can be pushed at the same time. While I have the local commits unpushed, wstool info doesn't tell me if I need to pull / rebase one of my repos to test with the latest upstream changes.

IIRC one concern was that it is not fast to compute (no?), but it seems fast enough (for git) to show it on every git status. I would be happy with an additional switch like --fetch.

[wkentaro]

that is discussed at #35 (comment) ,
but it is not yet implemented to check ahead/behind (that seems harder than just comparing the commit hash).

wstool info does not fetch by default, and has --fetch option.

Options:
  -h, --help            show this help message and exit
  --root                Show workspace root path
  --data-only           Does not provide explanations
  --only=ONLY           Shows comma-separated lists of only given comma-
                        separated attribute(s).
  --yaml                Shows only version of single entry. Intended for
                        scripting.
  --fetch               When used, retrieves version information from remote
                        (takes longer).
  -u, --untracked       Also show untracked files as modifications
  -t WORKSPACE, --target-workspace=WORKSPACE
                        which workspace to use
  -m, --managed-only    only show managed elements

See: http://www.ros.org/wiki/rosinstall for details

[tkruse]

The different flags are discussed here:
#35

The reasons I gave for not (yet) supporting more detailed information about the divergence types were:

• would require extention to vcstools API
• the extended API would be even more complex difficult to support for SVN, HG, BZR
• It might be sufficient to suport C, then people can check for themselves

Of course the last point could be handled by just saying the other VCSes do not support a new method, and gracefully return None or something neutral. I understand most ROS code is now using git anyway.

So basically, it can be hacked rather quickly, but finding and implementing a clean solution would take some effort and thinking.

The computation time itself was not yet looked at. It would not make wstool info any faster, but probably also not significantly slower (2 shell comands to git per repo that work on local repository).

If you want to discuss this more, maybe open a new issue on that.

It might be interesting if something convenient can be hacked using wstool info --yaml or wstool foreach.

[NikolausDemmel]

I startet a new issue #63.

wstool info does not fetch by default, and has --fetch option.

Yes I know. I use it and it is a great feature. Thanks for implementing!