{"thread":{"id":"4632","subject":"Ideas for qgit","startedAt":"2006-06-23T04:08:31Z","lastAt":"2006-06-23T20:59:05Z","messageCount":3,"participants":["Pavel Roskin","Marco Costalba"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"22332","messageId":"1151035711.25640.6.camel@dv","threadId":"4632","inReplyTo":null,"subject":"Ideas for qgit","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-23T04:08:31Z","receivedAt":"2006-06-23T04:08:31Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hi, Marco!\n\nAs promised, here's what I would like to see in qgit:\n\n1) Bookmarks or quick tags (qtags).  It may be useful to mark some\ncommits to make it easier to navigate qgit.  Yet I don't want them to\nmix with real tags.  Perhaps qgit could save them separately, e.g.\nin .git/refs/qtags to facilitate navigation.  qtags should appear\nseparately in the popup menu.\n\n2) The \"Patch\" tab should be redesigned so that the diff can be shown\nagainst the parent or against head/tag/qtag.  Users are not supposed to\nenter SHA1.  If they have to, then it only confirms that qgit needs\nqtags.\n\n3) It would be nice to have some minimal navigating capabilities on the\nPatch tab.  At least it should be possible to go up and down the\nrevision list and go to any head/tag/qtag/stgit patch.  It would\neliminate the need to switch to the \"Rev list\" too often.\n\n4) Some bisect support would be nice, at least as good as in gitk.\nActually, I'm not using bisect too much, but it's probably because I'm\nnot debugging Wine these days.  Everything else is intelligible :-)\n\n5) Branch view based on reflog.  Probably there should be an interface\nallowing to limit the displayed revisions to one branch.  I think qgit\nshould still load all revisions that it loads now, but if users start\ncomplaining about performance too much, maybe qgit should have an option\nto load only the logged branch.  The problem is that some parents will\nbe unavailable in the view.\n\n6) Try to unload some stuff from the popup menus to the main menu.  It\nwill be too log if we use it for tags, qtags, branch heads and branch\nlogs.\n\n7) qgit command line should be documented.  \"qgit --help\" should display\nhelp on stdout.\n\nThat said, qgit is in a pretty decent shape right now (except the\n\"macro\" interface, but I'm sure it will be improved before the next\nrelease).  I actually used qgit as an important argument for one project\nto go with git rather than with Subversion of Mercurial.  qgit for\nMercurial would be cool, but I'd leave it to Mercurial fans.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"22368","messageId":"e5bfff550606231112l6ca67799m7dddfabcee055045@mail.gmail.com","threadId":"4632","inReplyTo":"1151035711.25640.6.camel@dv","subject":"Re: Ideas for qgit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-23T18:12:26Z","receivedAt":"2006-06-23T18:12:26Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/23/06, Pavel Roskin <proski@gnu.org> wrote:\n> Hi, Marco!\n>\n> As promised, here's what I would like to see in qgit:\n>\n> 1) Bookmarks or quick tags (qtags).  It may be useful to mark some\n> commits to make it easier to navigate qgit.  Yet I don't want them to\n> mix with real tags.  Perhaps qgit could save them separately, e.g.\n> in .git/refs/qtags to facilitate navigation.  qtags should appear\n> separately in the popup menu.\n>\n\nCurrently we have two types of tags, signed and simple. If it is\npossible I would really like to stay with git tags, because bookmarks\nseems to me like reinventing the (broken) wheel.\n\nGit is very good in tagging and untagging and IMHO we should stay with\nthem, perhaps in the simple version. I really don't see any advantage\nnor immediate and less in the long term to almost duplicate that\nfunctionality and loosing proven git native tag handling features.\n\n> 2) The \"Patch\" tab should be redesigned so that the diff can be shown\n> against the parent or against head/tag/qtag.  Users are not supposed to\n> enter SHA1.  If they have to, then it only confirms that qgit needs\n> qtags.\n>\n\nWell, you can write also a ref name in SHA1 field. Try with\n\"v2.6.17-rc6\" or \"v1.4.0\".\nPerhaps this should be better documented and the SHA1 name is misleading.\n\n> 3) It would be nice to have some minimal navigating capabilities on the\n> Patch tab.  At least it should be possible to go up and down the\n> revision list and go to any head/tag/qtag/stgit patch.  It would\n> eliminate the need to switch to the \"Rev list\" too often.\n>\n\nThis make me think of biting the bullet and append patch information\n_also_ below revision description, yes, a la gitk. I think this is\nreally what you feel is missing.\n\n> 4) Some bisect support would be nice, at least as good as in gitk.\n> Actually, I'm not using bisect too much, but it's probably because I'm\n> not debugging Wine these days.  Everything else is intelligible :-)\n>\n\nI don't use bisect and I don't know the gitk implementation.\nI will investigate when I found some time. Not a top priority, at\nleast for my kind of workflow ;-)\n\n> 5) Branch view based on reflog.  Probably there should be an interface\n> allowing to limit the displayed revisions to one branch.  I think qgit\n> should still load all revisions that it loads now, but if users start\n> complaining about performance too much, maybe qgit should have an option\n> to load only the logged branch.  The problem is that some parents will\n> be unavailable in the view.\n>\n\nI think I didn't understand this. Isn't there command line arguments\nfor narrowing loaded revision set?\n\n> 7) qgit command line should be documented.  \"qgit --help\" should display\n> help on stdout.\n>\n\nAll the stuff in command line is sent directly to git-rev-parse. I\nthink this is good because avoids any overlapping between qgit and git\noptions and guarantees future compatibility with _any_  git option.\n\nAgain, being qgit a GUI tool we could avoid some command line only\napplication's habits. In the latter case there's nothing better to do,\nbut we can run a nicely formatted handbook in an independent window\njust pressing F1 and be sure to never mess with any current and future\npossible git option.\n\n        Marco\n"},{"id":"22373","messageId":"1151096345.10112.41.camel@dv","threadId":"4632","inReplyTo":"e5bfff550606231112l6ca67799m7dddfabcee055045@mail.gmail.com","subject":"Re: Ideas for qgit","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-23T20:59:05Z","receivedAt":"2006-06-23T20:59:05Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Fri, 2006-06-23 at 20:12 +0200, Marco Costalba wrote:\n> On 6/23/06, Pavel Roskin <proski@gnu.org> wrote:\n> > Hi, Marco!\n> >\n> > As promised, here's what I would like to see in qgit:\n> >\n> > 1) Bookmarks or quick tags (qtags).  It may be useful to mark some\n> > commits to make it easier to navigate qgit.  Yet I don't want them to\n> > mix with real tags.  Perhaps qgit could save them separately, e.g.\n> > in .git/refs/qtags to facilitate navigation.  qtags should appear\n> > separately in the popup menu.\n> >\n> \n> Currently we have two types of tags, signed and simple.\n\nI guess they should be shown a bit differently.\n\n>  If it is\n> possible I would really like to stay with git tags, because bookmarks\n> seems to me like reinventing the (broken) wheel.\n\nOK, I don't insist.  Then we need a user-friendlier implementation of\nCtrl-Rightclick in the revision list.  I stumbled upon it accidentally,\nand it looked like a bug at the first glance, when the file box suddenly\nwent turquoise and stopped showing modified files.  I still couldn't\nfigure out how to turn it off without going to the Patch tab and setting\ndiff to parent.\n\n> Git is very good in tagging and untagging and IMHO we should stay with\n> them, perhaps in the simple version. I really don't see any advantage\n> nor immediate and less in the long term to almost duplicate that\n> functionality and loosing proven git native tag handling features.\n\nOK\n\n> > 2) The \"Patch\" tab should be redesigned so that the diff can be shown\n> > against the parent or against head/tag/qtag.  Users are not supposed to\n> > enter SHA1.  If they have to, then it only confirms that qgit needs\n> > qtags.\n> >\n> \n> Well, you can write also a ref name in SHA1 field. Try with\n> \"v2.6.17-rc6\" or \"v1.4.0\".\n> Perhaps this should be better documented and the SHA1 name is misleading.\n\nI think it also shows that a wrong widget is used.  Probably an editable\nlistbox with all tag and branch names would be better.\n\n> > 3) It would be nice to have some minimal navigating capabilities on the\n> > Patch tab.  At least it should be possible to go up and down the\n> > revision list and go to any head/tag/qtag/stgit patch.  It would\n> > eliminate the need to switch to the \"Rev list\" too often.\n> >\n> \n> This make me think of biting the bullet and append patch information\n> _also_ below revision description, yes, a la gitk. I think this is\n> really what you feel is missing.\n\nMaybe.  \"Rev list\" and \"Patch\" represent essentially the same thing\nshown differently.  They can be replaced with one tab if it offers\nenough flexibility to use the screen space differently for different\ntasks.\n\n> > 4) Some bisect support would be nice, at least as good as in gitk.\n> > Actually, I'm not using bisect too much, but it's probably because I'm\n> > not debugging Wine these days.  Everything else is intelligible :-)\n> >\n> \n> I don't use bisect and I don't know the gitk implementation.\n> I will investigate when I found some time. Not a top priority, at\n> least for my kind of workflow ;-)\n\nI agree.\n\n> > 5) Branch view based on reflog.  Probably there should be an interface\n> > allowing to limit the displayed revisions to one branch.  I think qgit\n> > should still load all revisions that it loads now, but if users start\n> > complaining about performance too much, maybe qgit should have an option\n> > to load only the logged branch.  The problem is that some parents will\n> > be unavailable in the view.\n> >\n> \n> I think I didn't understand this. Isn't there command line arguments\n> for narrowing loaded revision set?\n\nAs far as I understand, reflog is only used to resolve references\nspecified as branch@date.  It doesn't seem to be well integrated with\nthe rest of git.\n\n> > 7) qgit command line should be documented.  \"qgit --help\" should display\n> > help on stdout.\n> >\n> \n> All the stuff in command line is sent directly to git-rev-parse. I\n> think this is good because avoids any overlapping between qgit and git\n> options and guarantees future compatibility with _any_  git option.\n\nThis also means that features not related to git-rev-parse (including\nStGIT and possible reflog support) cannot be controlled from the command\nline.  It's not critical now, but it may become more important.\n\n-- \nRegards,\nPavel Roskin\n"}]}