Commits


portable: release 0.102


zap redundant free This pointer is owned by the caller and is freed in error paths via close_diff_view() ok stsp@


bump version number


CHANGES for 0.102


got_worktree_prepare_path_info -> got_worktree_path_info_prepare


got patch: lock the worktree 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@


rename got_fileindex_version() to got_fileindex_get_version()


rename got_worktree_fileindex_version() to got_worktree_get_fileindex_version()


make info commands show the work tree format version, too ok op@


got/cvg info: print work tree version 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@


cmd_info: use got_error_path instead of _fmt No functional change intended.


style/fmt


rename idlen to digest_{,string_}len 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@


skip over lonely packidx when searching for objects 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@


fix signedness issue in got_pack_index() after sha256 work 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


include minimum length when trimming object IDs in regress


got_packidx_open: got_error_fmt -> got_error_path Results in the very same error but takes less characters to build. No functional change intended.


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


regress/tog: enable and run it in sha256 mode too with a fix from naddy, ok jamsek stsp@


tog: regress test for new log view 'm'ark commit keymap ok stsp@


use local temporary convenience pointer missed in 28c5a8280b ok stsp@


Mark Jamsek belongs on got author list, too; oversight on my part


run authors list through sort(1)


mention gotd in authors section


sync got.1 authors list with people appearing in commit log and copyright lines