{"thread":{"id":"9903","subject":"List of bugs and suggestions","startedAt":"2007-09-17T22:54:41Z","lastAt":"2007-09-17T23:26:20Z","messageCount":2,"participants":["Yann Dirson","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53361","messageId":"20070917225441.GA32647@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"9903","inReplyTo":null,"subject":"List of bugs and suggestions","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-09-17T22:54:41Z","receivedAt":"2007-09-17T22:54:41Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Here are a list of issues I wrote down while using git and friends at\nwork, but did not take time to report of fix myself before.  They are\nrelative to git 1.5.3.\n\nBUGS\n\n\tgitk:\n\n- when selecting again a \"local changes\" pseudo-patch, gitk re-reads\nthe diff, and the results can be confusing if HEAD changed since last\nfull reload (eg. git-commit or stg/guilt push/pop).  Should detect the\nHEAD change and propose a reload.\n\n- clicking in diff-contents or file-list panes does not move focus out\nof text fields (must click eg. between fields instead).  I remember\nroutinely click in diff-contents to focus out of the search field.\n\n- if a file that is modified and copied in the same commit, clicking\non the original in file-list pane jumps to the \"copy\" entry.  This can\neasily cause overlooking of changes to the original file.\n\n\n\tstash:\n\n- \"git stash show junk\" acts like \"git stash show\"\n\n- changes stashed in the index are unstashed only in workdir.  If\nthat's intended, a note in the \"stash apply\" doc would be useful; but\nthen I am left puzzled as to the usefulness of storing the index state\nin the stash branch: it could surely be applied by a variant of \"stash\napply\", but such a command does not seem to exist yet ?\n\n\n\tmisc git:\n\n- git has problems with cascaded alternates that use relative paths.\n\t\"git clone -s A B && git clone -s B C\" puts absolute paths in\n\tinfo/alternates - there is probably a good reason, but it will\n\tobviously hurt when moving the clone.  Further more,\n\tDocumentation/repository-layout.txt says scary things about\n\tusing absolute paths there.  But if one manually sets up\n\talternates in a set of repositories (easily reproduced by\n\thand-editing the alternates files in the B clone\n\tdescribed above), one ends with commits from A not being seen,\n\tand the following error message on each command run with C,\n\teven when no object lookup from A is required:\n\n| $ git fsck\n| error: .git/objects/../../../B/.git/objects: ignoring relative alternate object store ../../../A/.git/objects\n\n\n- repack -a -l (after transitionning a repo to alternates) does not\ndetect that old packs including objects now in alternate.\n\tI had 2 branches in a single repo and changed the setup to 2\n\trepos (initialize by \"cp -al\" and removing unwanted refs from\n\teach repo), A finally referencing B as remote and alternate.\n\t\"git repack -a -l\" in A seems to correctly only include only\n\tlocal objects in the pack, but all the old packs containing\n\tobjects now in B are kept.\n\n\nSUGGESTIONS\n\ngit-diff*:\n\n- could allow to declare word separators for --color-words\n\n- could print hunk number in header (a la filterdiff --annotate)\n\n\ngitk:\n\n- on-demand loading of additional revs (eg. ancestors from reflogs)\n\n- non-printable keystrokes could be made available from within text\nfields (F5, PgUp, etc)\n\n- large commits would be made easier to navigate with some additionnal\nhighlighting/coloring.  Eg:\n - coloring of add/remove (and copy/move ?) in patch file list\n - move selection in patch file list according to currently selected\n   search match when there is one, or according to the file(s) whose\n   diff currently appears\n - highlight search matches in patch file list\n - highlight search matches, and the file selected from the patch file\n   list, in/beside the patch display slider\n\n- file list could have its own focus history\n\n- for large commits, it takes time to get the full diff.  Showing the\nprogress (nfiles processed / nfiles in commit) would be nice\n\n- a \"goto prev file\" binding to reverse 'f' key (or quickly find in\nwhich file a search match occured) would be great\n\n- a \"scroll diff view to next hunk\" key binding ('h' ?)\n\n- search backwards, and case-insensitively\n\n- a list of known heads to jump to would be useful to quickly navigate\nin multiple-head display mode.\n\n- selecting a file in file list xould put filename in paste buffer,\nlike what's done for commit ids in history pane.\n\n- \"lock selected diff\" toggle, to avoid losing a particular diff by\nerror (esp. useful when getting an expensive diff relatively to\nselected commit)\n\n\nstgit:\n\n- derive a stack-log from patch logs\n\tThe ordering information provided by patchlogs and starck\n\treflog could be used to present a history of what happenned in\n\ta stack (eg. when coming back from holiday wondering what one\n\twas doing before leaving).\n\n\nstgit contrib scripts (mostly reminders to myself ;):\n\n- stg-whatchanged does not identify conflicts caused by \"stg pick --fold\"\n\n- stg-fold-files-from cannot fold binary files (filterdiff limitation)\n      =>  the following only works for filenames with no special char\n\t  (would need --zero):\n            git show --binary $(stg id occ53) -- $(stg files --bare occ53|grep '^doc/') | stg fold\n      => the following does not work either:\n            git show --binary $(stg id occ53) -- $(git-ls-tree --name-only $(stg id occ53) doc/)\n\n- stg-fold-files-from using non-git-aware filterdiff causes git-apply to\nmistake a \"add content to an empty file\" hunk for a \"create file\" hunk\n"},{"id":"53367","messageId":"Pine.LNX.4.64.0709180023060.28586@racer.site","threadId":"9903","inReplyTo":"20070917225441.GA32647@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: List of bugs and suggestions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-17T23:26:20Z","receivedAt":"2007-09-17T23:26:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Sep 2007, Yann Dirson wrote:\n\n> \tstash:\n> \n> - \"git stash show junk\" acts like \"git stash show\"\n> \n> - changes stashed in the index are unstashed only in workdir.  If that's \n> intended, a note in the \"stash apply\" doc would be useful; but then I am \n> left puzzled as to the usefulness of storing the index state in the \n> stash branch: it could surely be applied by a variant of \"stash apply\", \n> but such a command does not seem to exist yet ?\n\nIt does, but it is not documented: \"git stash apply --index\".\n\n> \tmisc git:\n> \n> - git has problems with cascaded alternates that use relative paths.\n\nKnown error, Pasky has lamented about that already.  I think we could get \naway with using make_absolute_path() cleverly.\n\nCiao,\nDscho\n"}]}