{"thread":{"id":"6669","subject":"Navigating remote branches in qgit","startedAt":"2007-02-04T07:41:29Z","lastAt":"2007-02-07T08:31:44Z","messageCount":6,"participants":["Pavel Roskin","Marco Costalba"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33545","messageId":"1170574889.21644.38.camel@dv","threadId":"6669","inReplyTo":null,"subject":"Navigating remote branches in qgit","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-02-04T07:41:29Z","receivedAt":"2007-02-04T07:41:29Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Marco!\n\nThe forthcoming git 1.5 uses a different layout for the remote branches.\ngit-pull loads updates for all remote branches by default.  However,\nmost remote branches don't have a local branch corresponding to them.\nThe refs for remote branches are kept under refs/remotes.\n\nIt's easy to select qgit tags and local branches using the popup menu.\nHowever, remote branches cannot be selected like this.\n\nIt's a pity, because it makes it hard for users to explore development\non remote branches, even though that information is available locally\nand is shown by qgit.\n\nIt would be great if qgit added remote branches to the popup menu.  I\nthink the menu needs some grouping, which would be beneficial for new\nusers who don't know what is what.  Branches should be under \"branches\",\nremote branches should be under \"remotes\", grouped by remotes, and tags\nshould be under \"tags\".\n\nWhile at that, we should think how to show refs in a more compact manner\nin the revision list.  I think \"refs/\" can be dropped in any case, since\nqgit only scans under refs.  Any rectangle implies \"refs/\" already.\nThat's what gitk does.\n\nWe probably don't what to show StGIT bases at all, since they are rarely\nuseful for the users, and they are apparent as the first non-StGIT\ncommit.\n\nRemote refs should recognized and be shown in a new color.  gitk uses\norange (#ffddaa) on the left and green on the right.  I think qgit\nshould use orange for the whole rectangle and drop \"remotes/\" in\naddition to \"refs/\", since the color will imply it.\n\nWe may want to consider fancy shapes for the identifiers, like\ngitk-style triangular tags for tags, some indicator of remoteness for\nremotes and some indicator of \"weirdness\" for the refs we cannot\ninterpret specifically.  My concern is users with non-standard color\nvision.  If we rely on an increasing number of colors, we should provide\na backup in case the colors cannot be distinguished.\n\nIt would be nice to have a refs browser that would show both loaded and\nnon-loaded refs, but I realize that it's not a quick fix type of change.\n\nPlease feel free to ask for help with testing and design of the\nweirdness indicator :)\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"33550","messageId":"e5bfff550702040128o6283b4f3m91debc45ec6b151@mail.gmail.com","threadId":"6669","inReplyTo":"1170574889.21644.38.camel@dv","subject":"Re: Navigating remote branches in qgit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-04T09:28:19Z","receivedAt":"2007-02-04T09:28:19Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Hello Pavel,\n\n>\n> Remote refs should recognized and be shown in a new color.  gitk uses\n> orange (#ffddaa) on the left and green on the right.  I think qgit\n> should use orange for the whole rectangle and drop \"remotes/\" in\n> addition to \"refs/\", since the color will imply it.\n>\n\nI will post a quick patch, just to get the idea.\n\n>\n> It would be nice to have a refs browser that would show both loaded and\n> non-loaded refs, but I realize that it's not a quick fix type of change.\n>\n\nWell, perhaps is not so hard, we already have\n\nGit::getAllRefNames(uint mask, bool onlyLoaded)\n\nthat seems to fit. First parameter 'mask' could have following or-ed flags:\n\n\tenum RefType {\n\t\tTAG        = 1,\n\t\tBRANCH     = 2,\n\t\tRMT_BRANCH = 4,\n\t\tCUR_BRANCH = 8,\n\t\tREF        = 16,\n\t\tAPPLIED    = 32,\n\t\tUN_APPLIED = 64,\n\t\tANY_REF    = 127\n\t};\n\n\n> Please feel free to ask for help with testing and design of the\n> weirdness indicator :)\n>\n\nIt should be great :-)\n\nMarco\n\nP.S: Grouped menu items patch will follow :-)\n"},{"id":"33567","messageId":"e5bfff550702040300x60bb1dfdxd312dc214bc49014@mail.gmail.com","threadId":"6669","inReplyTo":"1170574889.21644.38.camel@dv","subject":"Re: Navigating remote branches in qgit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-04T11:00:11Z","receivedAt":"2007-02-04T11:00:11Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/4/07, Pavel Roskin <proski@gnu.org> wrote:\n> Hello, Marco!\n>\n> While at that, we should think how to show refs in a more compact manner\n> in the revision list.  I think \"refs/\" can be dropped in any case, since\n> qgit only scans under refs.  Any rectangle implies \"refs/\" already.\n> That's what gitk does.\n>\n\nAfter the posted two patches \"refs/\" is shown only in StGIT bases. Currently\nqgit uses 'git show-ref -d' to retrieve ref list and \"ref/\" prefix is\nalready in git-show-ref output,\nso as a general rule I would try to avoid 'massaging' git output as\nmuch as is possible to have more chances thing do not break after a\ngit behaviour change.\n\nIt is difficult now to say it's (and will be) true that refs are only\nunder \"refs/\". Perhaps in the future someone came up with an idea to\nuse \"refs_of_some_kind/\" directory and this would break stuff.\n\nSo last line is: if git-show-ref prints this info, perhaps it's better to keep.\n\n  Marco\n"},{"id":"33604","messageId":"1170645235.4191.26.camel@dv.roinet.com","threadId":"6669","inReplyTo":"e5bfff550702040300x60bb1dfdxd312dc214bc49014@mail.gmail.com","subject":"Re: Navigating remote branches in qgit","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-02-05T03:13:55Z","receivedAt":"2007-02-05T03:13:55Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Marco!\n\nMany many thanks for being such a great magician and granting my wishes\nso quickly :)\n\nOn Sun, 2007-02-04 at 12:00 +0100, Marco Costalba wrote:\n> After the posted two patches \"refs/\" is shown only in StGIT bases. Currently\n> qgit uses 'git show-ref -d' to retrieve ref list and \"ref/\" prefix is\n> already in git-show-ref output,\n> so as a general rule I would try to avoid 'massaging' git output as\n> much as is possible to have more chances thing do not break after a\n> git behaviour change.\n\nOK, I understand.  I feel quite ambivalent on this if we stop showing\nStGIT bases.  They seem internal details of StGIT to me.\n\nGenerally, if qgit shows unrecognized refs, it's a sign that it needs to\nbe taught about them.  So indeed, massaging things we don't fully\nunderstand would be bad.\n\nThanks for making the remote branches appear in a unique way, but I\nthink you used a darker color than gitk, so they seem even more\nnoticeable than the local branches.\n\nI've made a patch that makes qgit use the same color as gitk.  It looks\nmuch better to my eyes.\n\nI think the popup menu for remote branches should have one more level of\nhierarchy.  The branches should be grouped by remotes:\n\nRemote branches -> wireless-2.6 -> master\n                                   upstream\n                   wireless-dev -> master\n                                   for-linus\n\nIt may not be as quick to access, but jumping the branches is not going\nto happen often.  It's more important to provide a good visualization.\n\nAlso, qgit seems to be confused on one of my repositories.  It doesn't\nshow any tags in the main menu and shows tags with branches under\n\"More\".  I guess there are too many remote branches.  The tarball is in\nhttp://www.red-bean.com/proski/qgit/\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"33642","messageId":"e5bfff550702050945l528b764apacc69b79c60dfb7a@mail.gmail.com","threadId":"6669","inReplyTo":"1170645235.4191.26.camel@dv.roinet.com","subject":"Re: Navigating remote branches in qgit","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-05T17:45:28Z","receivedAt":"2007-02-05T17:45:28Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Hello Pavel,\n\n> OK, I understand.  I feel quite ambivalent on this if we stop showing\n> StGIT bases.  They seem internal details of StGIT to me.\n>\n\nProbably you are right. Patch pushed.\n >\n> I've made a patch that makes qgit use the same color as gitk.  It looks\n> much better to my eyes.\n>\n\nThanks, applied.\n\n> I think the popup menu for remote branches should have one more level of\n> hierarchy.  The branches should be grouped by remotes:\n>\n> Remote branches -> wireless-2.6 -> master\n>                                    upstream\n>                    wireless-dev -> master\n>                                    for-linus\n>\n> It may not be as quick to access, but jumping the branches is not going\n> to happen often.  It's more important to provide a good visualization.\n>\n\nIn your interesting test case at http://www.red-bean.com/proski/qgit/\nall the remotes are on \"origin\", so in that case I don't see how\nthings could go better. Or perhaps I don't have understand the\ngrouping logic. In this case please give me some example based on your\nrepo, so I can understand the algorithm to use.\n\n> Also, qgit seems to be confused on one of my repositories.  It doesn't\n> show any tags in the main menu and shows tags with branches under\n> \"More\".  I guess there are too many remote branches.  The tarball is in\n> http://www.red-bean.com/proski/qgit/\n>\n\nThanks. Fixed and patch pushed.\n\n\n  Marco\n"},{"id":"33775","messageId":"1170837104.11150.128.camel@dv","threadId":"6669","inReplyTo":"e5bfff550702050945l528b764apacc69b79c60dfb7a@mail.gmail.com","subject":"Re: Navigating remote branches in qgit","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-02-07T08:31:44Z","receivedAt":"2007-02-07T08:31:44Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Marco!\n\nThank you for all your fixes!  You have greatly improved usability of\nqgit for me.\n\nOn Mon, 2007-02-05 at 18:45 +0100, Marco Costalba wrote:\n\n> In your interesting test case at http://www.red-bean.com/proski/qgit/\n> all the remotes are on \"origin\", so in that case I don't see how\n> things could go better. Or perhaps I don't have understand the\n> grouping logic. In this case please give me some example based on your\n> repo, so I can understand the algorithm to use.\n\nWell, the only example with multiple remotes is my Linux repository, and\nI'm afraid it would be too large.  So I'm attaching compressed output of\ngit-show-refs.\n\nActually, I'm not sure if multiple remotes is such a common case to add\na level in menu hierarchy just to support them.\n\nMy feeling is that the popup menu is already heavily overloaded, and\nsome things just need to be accessed from specialized dialogs.\n\nI think some design decisions should come from git.  What are we going\nto do if there are thousands of tags and branches?  How are we going to\nsort them in git?\n\n-- \nRegards,\nPavel Roskin\n"}]}