Since we may update the fileindex, the worktree must be preemptively locked exclusively. It's an old thing, been there since the start. ok stsp@

ok op@

This exends got_worktree_path_info() to resemble the "transaction"-like interface we have for rebase, patch etc. There's a prepare() routine that returns the fileindex, and locks the worktree, and a complete() function to free the fileinedx and release the lock. This way, we can open only once the fileindex in cmd_info() and have the chance to ask for its version. ok stsp@

No functional change intended.

In my early sha256 work I've used `idlen' to parametrize the digest length, but that's ambiguous since it could refer either to the digest length (in binary form) or the digest _string_ length (hexadecimal). So, change the few offenders to either digest_len or digest_string_len, which is a "naming scheme" I've already used in the rest of the tree. ok stsp@

This changes the search_packidx, match_packed_object and get_packfile_info routines to skip over lonely packidx. These seems to be generated occasionally by 'git fetch' over HTTP/S. Instead of dealing with this situation in gotwebd, which is fragile, attempt to do it at the lib/ level. `gotadmin cleanup' will still complain about these lonely packidx and `gotadmin cleanup -p' is still required. discussed with and ok stsp@

Later we try to see to -digest_len from the end of the file, and this on 32bit arches has some issues: size_t is 32bit and being unsigned becomes a huge number that then is casted to a off_t (signed, and larger) and makes us seek very, very far from the end of file. Then, read(2) returns zero because we're at end of file and trying to send packs to gotd fails with "I/O error". This was introduced when SHA1_DIGEST_LENGTH was converted to digest_len. ok jamsek, stsp

Results in the very same error but takes less characters to build. No functional change intended.

This reverts parts of be12ea2c34 and 4239df3cca. The fileindex and worktree code has been fixed and this workaround is no longer needed. ok stsp@

with a fix from naddy, ok jamsek stsp@

ok stsp@

ok stsp@

Enable "marking" an arbitrary commit in the log view to open a diff view showing the changes between it and the next commit selected with 'return'. Entering 'm' on an already marked commit unmarks it. input from and ok stsp@

This was broken in commit 4b3827cd43394b89d2af822dcd1d9a9179c1ee10 "make gitwrapper ignore 'permission denied' for repository paths"

ok op@