git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Marco Costalba <mcostalba@gmail.com>, git <git@vger.kernel.org>
Subject: Ideas for qgit
Date: Mon, 20 Feb 2006 20:16:20 -0500	[thread overview]
Message-ID: <1140484580.5282.54.camel@dv> (raw)

Hello, Marco!

Many thanks for releasing qgit 1.1!  Here are things I'd like to be
fixed in the next version.

The pop-up menu on revisions gets duplicate entries for tags after using
the file viewer (try qgit on the qgit repository).  This is a pure bug
that may merit a minor release (1.1.1 perhaps).

Tags should be in a submenu.  There are too many of them in some
projects.  Maybe there should be a limit of e.g. 10 tags, and the "more
tags" entry that would invoke a dialog for searching tags (and possibly
other things).

If all branches are loaded, it would be nice to be able to switch
between branches in a similar way.

The "check working dir" feature picks up files unknown to git, such as
editor backups and diff files.  It is very rare that a commit only has
added files but no files are modified.  Maybe I need to learn a habit of
adding any file I'm not going to commit to .gitignore, but as it stands
now, this feature of qgit seems too obtrusive to me.  Neither "cg-diff"
not "stg diff" will pick untracked files, and it's not even an option
for either of them.

Current StGIT creates entries for all patches under .git/refs/patches,
which makes all corresponding entries purple.  I think qgit should
specifically recognize entries under .git/refs/patches
and .git/refs/bases and use other ways to highlight them.  At very
least, .git/refs/patches should be ignored.  More elaborate approach
would be to draw applied StGIT patches differently, e.g. as pluses or
hollow circles.

qgit doesn't display tags except by yellow highlight.  There is no tag
name and no way to see the tag object.  I think one way to do it would
be to draw marks in the description column, like gitk does.  Another
approach would be to put all corresponding information in the patch
description pane, perhaps highlighted.

It would be great to store the cache file somewhere under .git, perhaps
under a simpler name, such as .git/qgit-cache.  The trailing ".z" should
probably be dropped, since the users are not supposed to decompress the
file or know anything about its internal structure.

Settings should be reviewed for usefulness.  Some show go to the menu,
such as "Relative time in date column".  It's hard to imagine that
somebody would use this option permanently.  "Diff against working dir"
is already in the menu, and I don't think it merits to be in the
settings.  qgit can simply remember the menu setting.  "Load file names
in background" should probably become a pair of radio buttons, since the
antithesis is not obvious.


As far as I know, qgit is unique among git front-ends for being written
in a non-interpreted language.  This fits well with git being designed
for speed.  It would be great if qgit received its fair share of
attention from GUI experts that happen to be in the git list ;-)

-- 
Regards,
Pavel Roskin

             reply	other threads:[~2006-02-21  1:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-21  1:16 Pavel Roskin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-06-23  4:08 Ideas for qgit Pavel Roskin
2006-06-23 18:12 ` Marco Costalba
2006-06-23 20:59   ` 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=1140484580.5282.54.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).