Navigating remote branches in qgit

Hello, Marco!

The forthcoming git 1.5 uses a different layout for the remote branches. git-pull loads updates for all remote branches by default. However, most remote branches don't have a local branch corresponding to them. The refs for remote branches are kept under refs/remotes.

It's easy to select qgit tags and local branches using the popup menu. However, remote branches cannot be selected like this.

It's a pity, because it makes it hard for users to explore development on remote branches, even though that information is available locally and is shown by qgit.

It would be great if qgit added remote branches to the popup menu. I think the menu needs some grouping, which would be beneficial for new users who don't know what is what. Branches should be under "branches", remote branches should be under "remotes", grouped by remotes, and tags should be under "tags".

While at that, we should think how to show refs in a more compact manner in the revision list. I think "refs/" can be dropped in any case, since qgit only scans under refs. Any rectangle implies "refs/" already. That's what gitk does.

We probably don't what to show StGIT bases at all, since they are rarely useful for the users, and they are apparent as the first non-StGIT commit.

Remote refs should recognized and be shown in a new color. gitk uses orange (#ffddaa) on the left and green on the right. I think qgit should use orange for the whole rectangle and drop "remotes/" in addition to "refs/", since the color will imply it.

We may want to consider fancy shapes for the identifiers, like gitk-style triangular tags for tags, some indicator of remoteness for remotes and some indicator of "weirdness" for the refs we cannot interpret specifically. My concern is users with non-standard color vision. If we rely on an increasing number of colors, we should provide a backup in case the colors cannot be distinguished.

It would be nice to have a refs browser that would show both loaded and non-loaded refs, but I realize that it's not a quick fix type of change.

Please feel free to ask for help with testing and design of the weirdness indicator :)

Hello Pavel,

I will post a quick patch, just to get the idea.

Well, perhaps is not so hard, we already have

Git::getAllRefNames(uint mask, bool onlyLoaded)

that seems to fit. First parameter 'mask' could have following or-ed flags:

	enum RefType {
		TAG        = 1,
		BRANCH     = 2,
		RMT_BRANCH = 4,
		CUR_BRANCH = 8,
		REF        = 16,
		APPLIED    = 32,
		UN_APPLIED = 64,
		ANY_REF    = 127
	};

It should be great :-)

Marco

P.S: Grouped menu items patch will follow :-)

On 2/4/07, Pavel Roskin <proski@gnu.org> wrote:

After the posted two patches "refs/" is shown only in StGIT bases. Currently qgit uses 'git show-ref -d' to retrieve ref list and "ref/" prefix is already in git-show-ref output, so as a general rule I would try to avoid 'massaging' git output as much as is possible to have more chances thing do not break after a git behaviour change.

It is difficult now to say it's (and will be) true that refs are only under "refs/". Perhaps in the future someone came up with an idea to use "refs_of_some_kind/" directory and this would break stuff.

So last line is: if git-show-ref prints this info, perhaps it's better to keep.

  Marco

Hello, Marco!

Many many thanks for being such a great magician and granting my wishes so quickly :)

On Sun, 2007-02-04 at 12:00 +0100, Marco Costalba wrote:

OK, I understand. I feel quite ambivalent on this if we stop showing StGIT bases. They seem internal details of StGIT to me.

Generally, if qgit shows unrecognized refs, it's a sign that it needs to be taught about them. So indeed, massaging things we don't fully understand would be bad.

Thanks for making the remote branches appear in a unique way, but I think you used a darker color than gitk, so they seem even more noticeable than the local branches.

I've made a patch that makes qgit use the same color as gitk. It looks much better to my eyes.

I think the popup menu for remote branches should have one more level of hierarchy. The branches should be grouped by remotes:

Remote branches -> wireless-2.6 -> master
                                   upstream
                   wireless-dev -> master
                                   for-linus

It may not be as quick to access, but jumping the branches is not going to happen often. It's more important to provide a good visualization.

Also, qgit seems to be confused on one of my repositories. It doesn't show any tags in the main menu and shows tags with branches under "More". I guess there are too many remote branches. The tarball is in http://www.red-bean.com/proski/qgit/

Hello Pavel,

Probably you are right. Patch pushed.
 >

Thanks, applied.

In your interesting test case at http://www.red-bean.com/proski/qgit/ all the remotes are on "origin", so in that case I don't see how things could go better. Or perhaps I don't have understand the grouping logic. In this case please give me some example based on your repo, so I can understand the algorithm to use.

Thanks. Fixed and patch pushed.

  Marco

Hello, Marco!

Thank you for all your fixes! You have greatly improved usability of qgit for me.

On Mon, 2007-02-05 at 18:45 +0100, Marco Costalba wrote:

Well, the only example with multiple remotes is my Linux repository, and I'm afraid it would be too large. So I'm attaching compressed output of git-show-refs.

Actually, I'm not sure if multiple remotes is such a common case to add a level in menu hierarchy just to support them.

My feeling is that the popup menu is already heavily overloaded, and some things just need to be accessed from specialized dialogs.

I think some design decisions should come from git. What are we going to do if there are thousands of tags and branches? How are we going to sort them in git?