List of bugs and suggestions

Here are a list of issues I wrote down while using git and friends at work, but did not take time to report of fix myself before. They are relative to git 1.5.3.

BUGS

	gitk:

- when selecting again a "local changes" pseudo-patch, gitk re-reads
the diff, and the results can be confusing if HEAD changed since last
full reload (eg. git-commit or stg/guilt push/pop).  Should detect the
HEAD change and propose a reload.

- clicking in diff-contents or file-list panes does not move focus out
of text fields (must click eg. between fields instead).  I remember
routinely click in diff-contents to focus out of the search field.

- if a file that is modified and copied in the same commit, clicking
on the original in file-list pane jumps to the "copy" entry.  This can
easily cause overlooking of changes to the original file.

	stash:

- "git stash show junk" acts like "git stash show"

- changes stashed in the index are unstashed only in workdir.  If
that's intended, a note in the "stash apply" doc would be useful; but
then I am left puzzled as to the usefulness of storing the index state
in the stash branch: it could surely be applied by a variant of "stash
apply", but such a command does not seem to exist yet ?

	misc git:

- git has problems with cascaded alternates that use relative paths.
	"git clone -s A B && git clone -s B C" puts absolute paths in
	info/alternates - there is probably a good reason, but it will
	obviously hurt when moving the clone.  Further more,
	Documentation/repository-layout.txt says scary things about
	using absolute paths there.  But if one manually sets up
	alternates in a set of repositories (easily reproduced by
	hand-editing the alternates files in the B clone
	described above), one ends with commits from A not being seen,
	and the following error message on each command run with C,
	even when no object lookup from A is required:

| $ git fsck
| error: .git/objects/../../../B/.git/objects: ignoring relative alternate object store ../../../A/.git/objects

- repack -a -l (after transitionning a repo to alternates) does not
detect that old packs including objects now in alternate.
	I had 2 branches in a single repo and changed the setup to 2
	repos (initialize by "cp -al" and removing unwanted refs from
	each repo), A finally referencing B as remote and alternate.
	"git repack -a -l" in A seems to correctly only include only
	local objects in the pack, but all the old packs containing
	objects now in B are kept.

SUGGESTIONS

git-diff*:

- could allow to declare word separators for --color-words

- could print hunk number in header (a la filterdiff --annotate)

gitk:

- on-demand loading of additional revs (eg. ancestors from reflogs)

- non-printable keystrokes could be made available from within text
fields (F5, PgUp, etc)

- large commits would be made easier to navigate with some additionnal
highlighting/coloring.  Eg:
 - coloring of add/remove (and copy/move ?) in patch file list
 - move selection in patch file list according to currently selected
   search match when there is one, or according to the file(s) whose
   diff currently appears
 - highlight search matches in patch file list
 - highlight search matches, and the file selected from the patch file
   list, in/beside the patch display slider

- file list could have its own focus history

- for large commits, it takes time to get the full diff.  Showing the
progress (nfiles processed / nfiles in commit) would be nice

- a "goto prev file" binding to reverse 'f' key (or quickly find in
which file a search match occured) would be great

- a "scroll diff view to next hunk" key binding ('h' ?)

- search backwards, and case-insensitively

- a list of known heads to jump to would be useful to quickly navigate
in multiple-head display mode.

- selecting a file in file list xould put filename in paste buffer,
like what's done for commit ids in history pane.

- "lock selected diff" toggle, to avoid losing a particular diff by
error (esp. useful when getting an expensive diff relatively to
selected commit)

stgit:

- derive a stack-log from patch logs
	The ordering information provided by patchlogs and starck
	reflog could be used to present a history of what happenned in
	a stack (eg. when coming back from holiday wondering what one
	was doing before leaving).

stgit contrib scripts (mostly reminders to myself ;):

- stg-whatchanged does not identify conflicts caused by "stg pick --fold"

- stg-fold-files-from cannot fold binary files (filterdiff limitation)
      =>  the following only works for filenames with no special char
	  (would need --zero):
            git show --binary $(stg id occ53) -- $(stg files --bare occ53|grep '^doc/') | stg fold
      => the following does not work either:
            git show --binary $(stg id occ53) -- $(git-ls-tree --name-only $(stg id occ53) doc/)

- stg-fold-files-from using non-git-aware filterdiff causes git-apply to
mistake a "add content to an empty file" hunk for a "create file" hunk