Navigating remote branches in qgit

Navigating remote branches in qgit

[Pavel Roskin]

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

-- 
Regards,
Pavel Roskin

Re: Navigating remote branches in qgit

[Marco Costalba]

Hello Pavel,

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

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

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

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
	};


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

It should be great :-)

Marco

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

Re: Navigating remote branches in qgit

[Marco Costalba]

On 2/4/07, Pavel Roskin <proski@gnu.org> wrote:
> Hello, Marco!
>
> 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.
>

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

Re: Navigating remote branches in qgit

[Pavel Roskin]

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

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/

-- 
Regards,
Pavel Roskin

Re: Navigating remote branches in qgit

[Marco Costalba]

Hello Pavel,

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

Probably you are right. Patch pushed.
 >
> I've made a patch that makes qgit use the same color as gitk.  It looks
> much better to my eyes.
>

Thanks, applied.

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

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.

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

Thanks. Fixed and patch pushed.


  Marco

Re: Navigating remote branches in qgit

[Pavel Roskin]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

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:

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

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?

-- 
Regards,
Pavel Roskin

[-- Attachment #2: showref.bz2 --]
[-- Type: application/x-bzip, Size: 3876 bytes --]