Ideas for qgit

Ideas for qgit

[Pavel Roskin]

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

Ideas for qgit

[Pavel Roskin]

Hi, Marco!

As promised, here's what I would like to see in qgit:

1) Bookmarks or quick tags (qtags).  It may be useful to mark some
commits to make it easier to navigate qgit.  Yet I don't want them to
mix with real tags.  Perhaps qgit could save them separately, e.g.
in .git/refs/qtags to facilitate navigation.  qtags should appear
separately in the popup menu.

2) The "Patch" tab should be redesigned so that the diff can be shown
against the parent or against head/tag/qtag.  Users are not supposed to
enter SHA1.  If they have to, then it only confirms that qgit needs
qtags.

3) It would be nice to have some minimal navigating capabilities on the
Patch tab.  At least it should be possible to go up and down the
revision list and go to any head/tag/qtag/stgit patch.  It would
eliminate the need to switch to the "Rev list" too often.

4) Some bisect support would be nice, at least as good as in gitk.
Actually, I'm not using bisect too much, but it's probably because I'm
not debugging Wine these days.  Everything else is intelligible :-)

5) Branch view based on reflog.  Probably there should be an interface
allowing to limit the displayed revisions to one branch.  I think qgit
should still load all revisions that it loads now, but if users start
complaining about performance too much, maybe qgit should have an option
to load only the logged branch.  The problem is that some parents will
be unavailable in the view.

6) Try to unload some stuff from the popup menus to the main menu.  It
will be too log if we use it for tags, qtags, branch heads and branch
logs.

7) qgit command line should be documented.  "qgit --help" should display
help on stdout.

That said, qgit is in a pretty decent shape right now (except the
"macro" interface, but I'm sure it will be improved before the next
release).  I actually used qgit as an important argument for one project
to go with git rather than with Subversion of Mercurial.  qgit for
Mercurial would be cool, but I'd leave it to Mercurial fans.

-- 
Regards,
Pavel Roskin

Re: Ideas for qgit

[Marco Costalba]

On 6/23/06, Pavel Roskin <proski@gnu.org> wrote:
> Hi, Marco!
>
> As promised, here's what I would like to see in qgit:
>
> 1) Bookmarks or quick tags (qtags).  It may be useful to mark some
> commits to make it easier to navigate qgit.  Yet I don't want them to
> mix with real tags.  Perhaps qgit could save them separately, e.g.
> in .git/refs/qtags to facilitate navigation.  qtags should appear
> separately in the popup menu.
>

Currently we have two types of tags, signed and simple. If it is
possible I would really like to stay with git tags, because bookmarks
seems to me like reinventing the (broken) wheel.

Git is very good in tagging and untagging and IMHO we should stay with
them, perhaps in the simple version. I really don't see any advantage
nor immediate and less in the long term to almost duplicate that
functionality and loosing proven git native tag handling features.

> 2) The "Patch" tab should be redesigned so that the diff can be shown
> against the parent or against head/tag/qtag.  Users are not supposed to
> enter SHA1.  If they have to, then it only confirms that qgit needs
> qtags.
>

Well, you can write also a ref name in SHA1 field. Try with
"v2.6.17-rc6" or "v1.4.0".
Perhaps this should be better documented and the SHA1 name is misleading.

> 3) It would be nice to have some minimal navigating capabilities on the
> Patch tab.  At least it should be possible to go up and down the
> revision list and go to any head/tag/qtag/stgit patch.  It would
> eliminate the need to switch to the "Rev list" too often.
>

This make me think of biting the bullet and append patch information
_also_ below revision description, yes, a la gitk. I think this is
really what you feel is missing.

> 4) Some bisect support would be nice, at least as good as in gitk.
> Actually, I'm not using bisect too much, but it's probably because I'm
> not debugging Wine these days.  Everything else is intelligible :-)
>

I don't use bisect and I don't know the gitk implementation.
I will investigate when I found some time. Not a top priority, at
least for my kind of workflow ;-)

> 5) Branch view based on reflog.  Probably there should be an interface
> allowing to limit the displayed revisions to one branch.  I think qgit
> should still load all revisions that it loads now, but if users start
> complaining about performance too much, maybe qgit should have an option
> to load only the logged branch.  The problem is that some parents will
> be unavailable in the view.
>

I think I didn't understand this. Isn't there command line arguments
for narrowing loaded revision set?

> 7) qgit command line should be documented.  "qgit --help" should display
> help on stdout.
>

All the stuff in command line is sent directly to git-rev-parse. I
think this is good because avoids any overlapping between qgit and git
options and guarantees future compatibility with _any_  git option.

Again, being qgit a GUI tool we could avoid some command line only
application's habits. In the latter case there's nothing better to do,
but we can run a nicely formatted handbook in an independent window
just pressing F1 and be sure to never mess with any current and future
possible git option.

        Marco

Re: Ideas for qgit

[Pavel Roskin]

On Fri, 2006-06-23 at 20:12 +0200, Marco Costalba wrote:
> On 6/23/06, Pavel Roskin <proski@gnu.org> wrote:
> > Hi, Marco!
> >
> > As promised, here's what I would like to see in qgit:
> >
> > 1) Bookmarks or quick tags (qtags).  It may be useful to mark some
> > commits to make it easier to navigate qgit.  Yet I don't want them to
> > mix with real tags.  Perhaps qgit could save them separately, e.g.
> > in .git/refs/qtags to facilitate navigation.  qtags should appear
> > separately in the popup menu.
> >
> 
> Currently we have two types of tags, signed and simple.

I guess they should be shown a bit differently.

>  If it is
> possible I would really like to stay with git tags, because bookmarks
> seems to me like reinventing the (broken) wheel.

OK, I don't insist.  Then we need a user-friendlier implementation of
Ctrl-Rightclick in the revision list.  I stumbled upon it accidentally,
and it looked like a bug at the first glance, when the file box suddenly
went turquoise and stopped showing modified files.  I still couldn't
figure out how to turn it off without going to the Patch tab and setting
diff to parent.

> Git is very good in tagging and untagging and IMHO we should stay with
> them, perhaps in the simple version. I really don't see any advantage
> nor immediate and less in the long term to almost duplicate that
> functionality and loosing proven git native tag handling features.

OK

> > 2) The "Patch" tab should be redesigned so that the diff can be shown
> > against the parent or against head/tag/qtag.  Users are not supposed to
> > enter SHA1.  If they have to, then it only confirms that qgit needs
> > qtags.
> >
> 
> Well, you can write also a ref name in SHA1 field. Try with
> "v2.6.17-rc6" or "v1.4.0".
> Perhaps this should be better documented and the SHA1 name is misleading.

I think it also shows that a wrong widget is used.  Probably an editable
listbox with all tag and branch names would be better.

> > 3) It would be nice to have some minimal navigating capabilities on the
> > Patch tab.  At least it should be possible to go up and down the
> > revision list and go to any head/tag/qtag/stgit patch.  It would
> > eliminate the need to switch to the "Rev list" too often.
> >
> 
> This make me think of biting the bullet and append patch information
> _also_ below revision description, yes, a la gitk. I think this is
> really what you feel is missing.

Maybe.  "Rev list" and "Patch" represent essentially the same thing
shown differently.  They can be replaced with one tab if it offers
enough flexibility to use the screen space differently for different
tasks.

> > 4) Some bisect support would be nice, at least as good as in gitk.
> > Actually, I'm not using bisect too much, but it's probably because I'm
> > not debugging Wine these days.  Everything else is intelligible :-)
> >
> 
> I don't use bisect and I don't know the gitk implementation.
> I will investigate when I found some time. Not a top priority, at
> least for my kind of workflow ;-)

I agree.

> > 5) Branch view based on reflog.  Probably there should be an interface
> > allowing to limit the displayed revisions to one branch.  I think qgit
> > should still load all revisions that it loads now, but if users start
> > complaining about performance too much, maybe qgit should have an option
> > to load only the logged branch.  The problem is that some parents will
> > be unavailable in the view.
> >
> 
> I think I didn't understand this. Isn't there command line arguments
> for narrowing loaded revision set?

As far as I understand, reflog is only used to resolve references
specified as branch@date.  It doesn't seem to be well integrated with
the rest of git.

> > 7) qgit command line should be documented.  "qgit --help" should display
> > help on stdout.
> >
> 
> All the stuff in command line is sent directly to git-rev-parse. I
> think this is good because avoids any overlapping between qgit and git
> options and guarantees future compatibility with _any_  git option.

This also means that features not related to git-rev-parse (including
StGIT and possible reflog support) cannot be controlled from the command
line.  It's not critical now, but it may become more important.

-- 
Regards,
Pavel Roskin