{"thread":{"id":"909","subject":"reducing line crossings in gitk","startedAt":"2005-06-11T11:47:03Z","lastAt":"2005-06-16T15:05:29Z","messageCount":7,"participants":["Paul Mackerras","Junio C Hamano","Matthias Urlichs","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4871","messageId":"17066.53047.660907.453399@cargo.ozlabs.ibm.com","threadId":"909","inReplyTo":null,"subject":"reducing line crossings in gitk","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-06-11T11:47:03Z","receivedAt":"2005-06-11T11:47:03Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"At the moment, the commit graph that gitk draws always displays the\nparents of a merge in left-to-right order as they are listed in the\ncommit (provided that none of the parents already has a line, i.e., is\nthe parent of an previously drawn commit). That means that for the\ntypical merge, the branch coming out to the right is the stuff that\nwas pulled in by the merge.\n\nThat can lead to a later line crossing if an ancestor of the stuff\nbeing pulled in already has a line that is to the left of the merge.\nFor an example of what I mean, look at the kernel repository with gitk\nat around commit 5ea6f2c33f0c8b126136dbf1776ffbc444772cd7 (Automatic\nmerge of /spare/repo/netdev-2.6 branch natsemi).\n\nI could add a heuristic to look for this case and reverse the order of\nthe parents, which would reduce the line crossings and make the graph\nlook neater. Would this be worth the slight loss of information (in\nthat the stuff pulled in would no longer always be to the right)?\n\nPaul.\n"},{"id":"4878","messageId":"7v8y1gvjfz.fsf@assigned-by-dhcp.cox.net","threadId":"909","inReplyTo":"17066.53047.660907.453399@cargo.ozlabs.ibm.com","subject":"Re: reducing line crossings in gitk","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-11T18:26:24Z","receivedAt":"2005-06-11T18:26:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"PM\" == Paul Mackerras writes:\n\nPM> I could add a heuristic to look for this case and reverse the order of\nPM> the parents, which would reduce the line crossings and make the graph\nPM> look neater. Would this be worth the slight loss of information (in\nPM> that the stuff pulled in would no longer always be to the right)?\n\nPersonally I find the current \"crossing lines\" display makes\nwhat happened more visually obvious than \"reverse order of the\nparents\", so I'd be happier if you keep things as they are.\n\nThanks for a wonderful tool. May I ask for more? Some are\nminor UI enhancements, some are feature ideas.\n\n - The first time I tried it from somewhere random without\n having GIT_DIR environment, it just gave error and exited.\n Which is correct but could have been nicer.\n\n Adding a \"Browse Repo\" in the \"File\" menu to let the user\n switch which repository to browse (and when chosen start\n afresh, of course) would be nicer, while keeping the default\n of showing the current ${GIT_DIR:=.git} upon start-up.\n\n - What support from the core GIT side would you need if you\n wanted to let users browse a remote repo? A way to inspect\n what is under \".git/refs/\" hierarchy on the remote side?\n Anything else?\n\n - Pasting into the SHA1 field to \"Go To\" was a nuisance when\n the field already had a string in it. Clearing the SHA1\n field when focus gets in would be one way to solve it, but\n then you would lose the way to pasting out of that field, so\n I do not know what to suggest offhand.\n\n - How do I \"Find\" backwards? Not being able to find a way to\n do this was the most annoying thing for me.\n\n - After typing something in \"Find\" and hitting , if the\n focus stays in it and lets me hit again to go to the\n next one would be nicer. Somehow hitting again would\n not do this for me right now.\n\n - Indicaing \"Find\" wrapping around without annoying the user\n too much (i.e. I do _not_ want you to add \"Find reached the\n beginning of time, wrapping around and continuing from the\n top\" pop-up window) would be nicer. Currently I can tell by\n looking at the scrollbar on the history pane jumping back, so\n this is not a big issue, though.\n\n - Can I have a way to \"Find\" next commit that touches a given\n pathname?\n\n $ git-rev-list | git-diff-tree -s -r --stdin ''\n\n which would give you a sequence of lines that look like:\n \"commit-SHA1 (from parent-commit-SHA1)\"\n\n you would pick the commit-SHA1 from the output and jump to it.\n\n - In addition to \"Find\" which looks at the commit message, can I\n have one that uses pickaxe to find changes?\n\n Add a new choice \"In Patch\" to the list of choices (\"All\n fields\", etc); sorry, but currently pickaxe can only do exact\n matches. When you are operating in that mode, run\n\n $ git-rev-list | git-diff-tree -s -r --stdin -S''\n\n which would give you a sequence of lines that look like:\n \"commit-SHA1 (from parent-commit-SHA1)\"\n\n you would pick the commit-SHA1 from the output and jump to it.\n\n - Can I have an option to use diffcore options to tweak the\n diff that is shown in the lower-left pane?\n\n Add \"Diff\" menu next to \"File\" menu, and have the following\n options: \"Find Renames\", \"Find Copies\", \"Find Rewrites\".\n\n The first two are mutually exclusive so you can have (1) both\n off, (2) Renames, or (3) Copies. \"Rewrites\" is independent,\n so you end up with 6 combinations. Give \"-M\", \"-C\", and \"-B\"\n option to git-diff-tree you run on the commit when these\n \"Find foo\" options are in effect, respectively.\n\n A good test case in GIT repository itself to try these are:\n\n 418aaf847a8b3ffffb4f777a2dd5262ca5ce0ef7 (for -M)\n\tThis renames rpull.c to ssh-pull.c etc. Four renames in\n\ttotal.\n\n 7ef76925d9c19ef74874e1735e2436e56d0c4897 (for -C)\n\tThis creates git-fetch-script out of git-pull-script\n by copying.\n\n 6af1f0192ff8740fe77db7cf02c739ccfbdf119c (for -B)\n\tThis rewrites ls-tree.c\n\nThis list is based on gitk-1.1 (I downloaded this morning) so you\nmay already have unpublished solutions.\n\n"},{"id":"4897","messageId":"pan.2005.06.12.14.30.49.114182@smurf.noris.de","threadId":"909","inReplyTo":"17066.53047.660907.453399@cargo.ozlabs.ibm.com","subject":"Re: reducing line crossings in gitk","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-06-12T14:30:49Z","receivedAt":"2005-06-12T14:30:49Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Paul Mackerras wrote:\n\n> I could add a heuristic to look for this case and reverse the order of\n> the parents, which would reduce the line crossings and make the graph\n> look neater. Would this be worth the slight loss of information (in\n> that the stuff pulled in would no longer always be to the right)?\n\nYes.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nAll interesting actions are overdetermined. -- Arthur D. Hlavaty\n\n\n"},{"id":"4971","messageId":"17072.3723.242985.824999@cargo.ozlabs.ibm.com","threadId":"909","inReplyTo":"7v8y1gvjfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: reducing line crossings in gitk","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-06-15T11:18:35Z","receivedAt":"2005-06-15T11:18:35Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio C Hamano writes:\n\n> - What support from the core GIT side would you need if you\n> wanted to let users browse a remote repo? A way to inspect\n> what is under \".git/refs/\" hierarchy on the remote side?\n> Anything else?\n\nI would need git-rev-list, git-cat-file, and git-diff-tree to be able\nto operate on the remote repository.\n\n> - Pasting into the SHA1 field to \"Go To\" was a nuisance when\n> the field already had a string in it. Clearing the SHA1\n> field when focus gets in would be one way to solve it, but\n> then you would lose the way to pasting out of that field, so\n> I do not know what to suggest offhand.\n\nI could rebind the middle mouse button to replace the contents of the\nsha1 field with the selection instead of inserting it.\n\n> - How do I \"Find\" backwards? Not being able to find a way to\n> do this was the most annoying thing for me.\n\nThe \"?\" key is bound to find backwards (i.e. select previous match)\nand the \"/\" key is bound to find forwards (select next match). I\ndon't have a button for find backwards (and I'd rather not clutter it\nup by adding one, but maybe I could add a menu item for it).\n\n> - After typing something in \"Find\" and hitting , if the\n> focus stays in it and lets me hit again to go to the\n> next one would be nicer. Somehow hitting again would\n> not do this for me right now.\n\nHmmm, if the focus stays in the find field then you can't use \"?\", up,\ndown, etc. I could make do find-next if you like.\n\n> - Indicaing \"Find\" wrapping around without annoying the user\n> too much (i.e. I do _not_ want you to add \"Find reached the\n> beginning of time, wrapping around and continuing from the\n> top\" pop-up window) would be nicer. Currently I can tell by\n> looking at the scrollbar on the history pane jumping back, so\n> this is not a big issue, though.\n\nI could make it beep - how about that?\n\n> - Can I have a way to \"Find\" next commit that touches a given\n> pathname?\n> \n> $ git-rev-list | git-diff-tree -s -r --stdin ''\n> \n> which would give you a sequence of lines that look like:\n> \"commit-SHA1 (from parent-commit-SHA1)\"\n> \n> you would pick the commit-SHA1 from the output and jump to it.\n\nInteresting idea... I could add a \"Path\" entry to the find type menu.\n\n> - In addition to \"Find\" which looks at the commit message, can I\n> have one that uses pickaxe to find changes?\n> \n> - Can I have an option to use diffcore options to tweak the\n> diff that is shown in the lower-left pane?\n\nAlso interesting ideas, I'll see what I can do.\n\nRegards,\nPaul.\n"},{"id":"4972","messageId":"2cfc40320506150534380bb5f8@mail.gmail.com","threadId":"909","inReplyTo":"17072.3723.242985.824999@cargo.ozlabs.ibm.com","subject":"Re: reducing line crossings in gitk","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-15T12:34:34Z","receivedAt":"2005-06-15T12:34:34Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"Paul,\n\nAnother feature that would be handy is the ability to be able to\ncreate tags by pointing to an item and selecting a \"create-tag\"\naction. The effect would be to write the SHA1 id into\nGIT_DIR/refs/tags in the expected way.\n\nRegards, \n\njon.\n"},{"id":"4991","messageId":"17073.28667.819809.89026@cargo.ozlabs.ibm.com","threadId":"909","inReplyTo":"2cfc40320506150534380bb5f8@mail.gmail.com","subject":"Re: reducing line crossings in gitk","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-06-16T12:26:35Z","receivedAt":"2005-06-16T12:26:35Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Jon Seymour writes:\n\n> Another feature that would be handy is the ability to be able to\n> create tags by pointing to an item and selecting a \"create-tag\"\n> action. The effect would be to write the SHA1 id into\n> GIT_DIR/refs/tags in the expected way.\n\nHmmm, that would create a \"direct\" tag, not a normal tag, which is\nan object of type \"tag\" that contains a reference to a commit along\nwith some other stuff.\n\nIn general I'd like to keep gitk as purely a viewer. Ultimately I'll\nprobably do a graphical tool for checking stuff in and other\noperations that modify the repository as well, but I think that should\nbe a separate tool.\n\nRegards,\nPaul.\n"},{"id":"4993","messageId":"2cfc403205061608053664cc1e@mail.gmail.com","threadId":"909","inReplyTo":"17073.28667.819809.89026@cargo.ozlabs.ibm.com","subject":"Re: reducing line crossings in gitk","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-16T15:05:29Z","receivedAt":"2005-06-16T15:05:29Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 6/16/05, Paul Mackerras wrote:\n> Jon Seymour writes:\n> \n> > Another feature that would be handy is the ability to be able to\n> > create tags by pointing to an item and selecting a \"create-tag\"\n> > action. The effect would be to write the SHA1 id into\n> > GIT_DIR/refs/tags in the expected way.\n> \n> Hmmm, that would create a \"direct\" tag, not a normal tag, which is\n> an object of type \"tag\" that contains a reference to a commit along\n> with some other stuff.\n> \n> In general I'd like to keep gitk as purely a viewer. Ultimately I'll\n> probably do a graphical tool for checking stuff in and other\n> operations that modify the repository as well, but I think that should\n> be a separate tool.\n> \n> Regards,\n> Paul.\n> \n\nFair enough... the reason I suggested it is that I use gitk to help me\ndecide how to merge stuff with the mainline. Currently I have to cut\nand paste the ids of the \"interesting\" commits into the command line.\nIt would be nice to be able to point directly to an interesting commit\nand tag it so that I can later get to it from a command line using a\nname I can remember.\n\nStill, I can quite accept that I have an idiosyncratic way of\ninteracting with git and gitk.\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"}]}