Commit Briefs
add 'got commit -F' option to commit with a log message stored in a file
To avoid accidents commit -F opens the prepared log message in an editor so it can be reviewed before the commit is created. For non-interactive use the -N option is required in addition to -F. ok millert@
tog: fix behaviour when 'n' is pressed before a search was started with '/'
reported by + ok naddy
implicitly mark all files in work tree as up-to-date after 'got integrate'
Avoids having to run 'got update' for no good reason after 'got integrate'. The same change was made recently for both rebase and histedit in commit a615e0e7796ea1103a6e0d4b5dbb6134597886660 and we forgot about histedit.
close file handles before freeing other things in got_worktree_close()
The work tree's path needs to be valid while constructing error messages.
fix a use after free()
ok jrick stsp
fix bug where 'got up -c commit path' deleted unrelated files from work tree
Problem reported by Timo Myyrä
add a 'reference' directive to remote repositories in got.conf(5)
Make use of this in 'got clone' to persist -R option arguments given on the command line in the cloned repository's got.conf(5) file.
add a 'fetch-all-branches' configuration setting to got.conf(5)
Set fetch-all-branches in the got.conf(5) file created by 'got clone -a' in order to make a future 'got fetch' act like 'got fetch -a' by default.
work around spurious ACK responses from git servers in got-fetch-pack
The Git server can apparently send duplicate ACK responses even though we do not enable the multi_ack capability. According to the Git protocol docs the server should only send ACKs after receiving 'done' from the client if multi_ack has been enabled. However, a duplicate ACK response can be triggered by running 'got fetch -a' in our fetch_update_tag test. This resulted in the following error: got-fetch-pack: unknown side-band received from server got: bad packet received