--*-outline-*--


* Known GNU Interactive Tools Problems
======================================


** 1. Missing '.' directory problem
-----------------------------------

While working on a previous version of git, I've tried to use it to
read a NFS mounted directory.  The file system was exported by a
Ultrix system and mounted on a Linux system.  When I've entered the
directory where the NFS mounted file system was supposed to be, git
received a SIGSEGV signal.  Looking at that directory with 'ls', I've
figured out that the directory was completely empty (the '.' & '..'
directories were missing too) even thought the file system was
reported as being succesfully mounted.  A few days later I've
experienced the same problem on our HP-UX workstation, trying to mount
a NFS file system exported by a SGI workstation.

Starting with that version of git, I've put two tests in the routine
that reads the directory (panel_read_directory()) that check if the
'.' and '..' directories have been found.  If any of them is missing,
git will refuse to enter the directory, in order to avoid further
problems.

Unfortunately, a few people have reported that git refuses to work on
their machines because it can't find the '.' directory.  One of them
was using Solaris 2.3 with NFS, the other one SunOS.

I recently installed NFS on a machine here and I tried to fix all the
problems git had under NFS.  There were lots of problems, all of them
were being related to the fact that NFS does lots of strange things:

1) root can enter directories where it has no permission (remember,
the root id is converted by NFS to -2 (an unprivileged user), and then
is unable to read files (thus there is no ".." directory).

2) in some other circumstances (directories with rw- permission only)
it can enter the directory, read the entries but it is unable to stat
them.

I don't know if the changes I've made will fix all the problems.  I
have tried to emulate the ".." directory and to recover whenever
possible.  Please let me know if it works for you.


** 2. cp problems
-----------------

"cp -f" doesn't work on all systems, so directories that are in fact
symbolic links will not be copied.  If your cp does understand "-f",
try modifying the panel_copy function in panel.c, replacing "cp -r"
with "cp -r -f" or "cp -rf".


** 3. SCO 3.2 V 4.2 problems
----------------------------

Han Holl <100327.1632@compuserve.com> has reported a problem running
git-4.3.5 on SCO Unix 3.2 V 4.2:

> GIT didn't work with the ordinary malloc library:
> I used './configure --with-terminfo', and added -lmalloc to the LIBS
> variable (it crashed with the ordinary malloc library). I used gcc.


** 4. SLACKWARE Linux 1.2.0 / 2.0.0 termcap/terminfo problems
-------------------------------------------------------------

a. The 'ms' flag (safe to move in standout mode) is missing from the
console termcap database.  It is available only in the console
terminfo database (its terminfo name is 'msgr').

b. The 'sgr0' capability (according to the terminfo manual this is the
terminfo name of the termcap 'me' capability) is missing from the
console terminfo database but it is available in the termcap database.
This is a problem for GIT when using terminfo because if we can't turn
the reverse video mode or the brightness off, we should not turn them
on at all.  I've solved the problem by using a hard-coded 'me' for the
Linux console if I can't find 'me' in the database, but I hate this
method.  This is one of the two reasons why I prefer using termcap
under Linux (the second one is that the executable linked with the
termcap library is a lot smaller).

c. The 'smacs' and 'rmacs' ('as' and 'ae' in termcap) are missing from
the console termcap database but are available in the console terminfo
database.

d. 'se' is \E[27m in termcap but 'rmso' (the terminfo equivalent) is
\E[0m in terminfo.  Are both ok ?


** 5. Linux color_xterm problems
--------------------------------

Sometimes, when moving the cursor, color_xterm deletes useful
informations on the screen.  This is *NOT* an git bug because when
hiding/repainting the window, the garbage disappears.  I don't know
how to handle this.  The normal xterm (b/w) works fine.  Other
xterm terminal emulators (with color support) like Linux's rxvt and
Ultrix's xterm work just fine.

To reproduce the problem, start git, press the down arrow (or ^N), and
then type a few spaces in the command line.  Those spaces will be
displayed with the wrong color, but if you hide and the re-expose the
color_xterm window, everything will be redisplayed correctly.


** 6. File systems with no support for hard links
-------------------------------------------------

We can't *really* move a file on such file systems.  We have to copy
the source file to the destination and then remove the it.  MS-DOG
programs can perform a real move by copying the directory entry in the
destination directory but I don't think we can do this under UNIX and
I don't feel like writing MS-DOG "file system" dependent code.  Sorry.
In fact, my real problem wasn't that stupid MS-DOG file system, but
the impossibility of detecting such file systems.  The 'move' command
will normally fail on file systems with no support for hard links, but
under Linux it *will* work with MS-DOG file systems because I know
MS-DOG lacks working hard links and I've put a small test in the right
place :-).


** 7. Sun's sun-cmd termcap problems
------------------------------------

If you are using the sun-cmd terminal emulator under SunOS 5.4,
Solaris or similar systems, it seems that the termcap library fails to
work as expected.  because some capabilities are reported as missing
even though they are available.  This leads to git being unable to
display the frame in reverse video.  I've compiled git with the GNU
termcap library and it works just fine, but the scrolling feature
still has to be disabled.

I recently (4.3.8) changed git to work with standout mode whenever
possible.  I don't know if this problem still exists.  Please let me
know if you can figure it out.  Thanks.


** 8. Linux 2.0.x kernels
-------------------------

If you are experiencing problems with gitview under Linux kernels >
2.0.0, try updating your termcap database to termcap 2.0.8.

It seems that the sequence returned by the `End' key is given by the
`@7' termcap capability in the latest termcap.  GIT used to inspect
`kH' for this...


** 9. UNIX System V Release 4
-----------------------------

If you're compiling with gcc, you're fine.  With the native compiler
you need to hand edit config.h _after_ running configure, comment out
HAVE_DIRENT_H and define HAVE_SYS_DIR_H instead.  While git will
compile anyway, dirent will not work for some reason I haven't had the
time to figure out.