All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Marco Costalba <mcostalba@gmail.com>
Cc: git@vger.kernel.org
Subject: Navigating remote branches in qgit
Date: Sun, 04 Feb 2007 02:41:29 -0500	[thread overview]
Message-ID: <1170574889.21644.38.camel@dv> (raw)

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

             reply	other threads:[~2007-02-04  7:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-04  7:41 Pavel Roskin [this message]
2007-02-04  9:28 ` Navigating remote branches in qgit Marco Costalba
2007-02-04 11:00 ` Marco Costalba
2007-02-05  3:13   ` Pavel Roskin
2007-02-05 17:45     ` Marco Costalba
2007-02-07  8:31       ` Pavel Roskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1170574889.21644.38.camel@dv \
    --to=proski@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=mcostalba@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.