Commits
- Commit:
50b0790ed9a28fced631f31e5b7ca76a9a610ea5
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add per-worktree got.conf(5) file in the .got directory; ok millert
- Commit:
0823ffc2f6c509dbcedfb15d0d1011a253b45ef9
- From:
- Christian Weisgerber <naddy@mips.inka.de>
- Date:
use modern POSIX timestamp fields in struct stat
ok stsp
- Commit:
766841c2970cb5bef66c9c69201b231d0eefb120
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add -s option to 'got remove' which deletes files in a particular status
This makes it easy to deal with files that were deleted from disk by external
tooling which modified the work tree. Such files are left in missing (!)
status and can now be marked for deletion in bulk via 'got rm -s\! -R .'
For consistency, modified (M) files can now be removed with 'got rm -s M'
which implies 'got rm -f'.
Prompted by feedback from krw@
- Commit:
f2b0a8b0a1881cbc7388392deaa518caf38be151
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix committing file additions from a work tree with a path prefix
New files were added under the wrong tree in the repository if the work
tree has a path prefix. Fix this problem and catch it in the existing
commit_with_path_prefix regression test.
- Commit:
69d57f3de25cfb3fd0cbfef22bd20090b36cee5e
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix spurious 'got cherrypick' error with a path prefix and an empty tree
If the work tree's path prefix does not exist in the first of the two
trees, then 'got cherrypick' failed with "no such entry found in tree".
But this is a legitimate situation, as shown in the new test added here.
The first tree could be the empty tree, for example, which should result
in 'got cherrypick' adding all files from the second tree instead of
complaining about a non-existent path-prefix directory in the first tree.
- Commit:
b66cd6f325e3fa7ddd17ff6dd41cf6e59d04ebf5
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
display more context info in "no such entry found in tree" error messages
- Commit:
b2118c49a14c29447e228bf9a2b2a38f2da4f10b
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
Add a 'got info' command which displays work tree meta-data.
Remove the alias 'got in' for 'got init'.
The 'in' alias was too close to either 'init' or 'info'.
ok tracey, millert
- Commit:
283102fc7ecc50b874240654162793c0bd07a028
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
remove the symlink conflict header feature; it causes noise for little benefit
- Commit:
f9eec9d5cdd0cbb22e0d3ed2d1cb55569afafce9
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
rename get_symlink_status() to get_symlink_modification_status() for clarity
- Commit:
f179e66de44d3541fbbcf6be9a5bcc70465f0bc9
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
use a shortcut in get_file_status() for detecting symlinks appearing on disk
- Commit:
fda8017d0d1d1314b68ea9776bb563c2ea127f3e
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
move deeply indented code from unstage_path() to a new unstage_hunks() helper
- Commit:
36bf999ca5297d07cc17f79a154b0875c1574148
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make 'got unstage -p' work with symlinks
- Commit:
dfe9fba06700a32516eb465d89fe7e0b6d96ad2f
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
remove merge_blob() fallback from merge_symlink(); let callers handle this
- Commit:
75f0a0fb346fb0ad381536024728164cd32d2a7e
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
stop reinstalling symlinks after commit; 'got update' can handle that
- Commit:
35213c7c838a48142d398147b54bb9938af8cab0
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
forbid bad symlinks; add -S option to 'got commit' and 'got stage' to allow them
- Commit:
3c1ec782ab68abf6084ad937bc2a3e4a9c8fe049
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
put checks for bad symlink target paths into a dedicated function
- Commit:
ea7786be381853efad88beae518c19a391d13791
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make 'got unstage' work with symlinks
- Commit:
b7422a2f5c775615ff397e14c04aa9c9a41504c1
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
stop using realpath(3) to resolve a symlink target in install_symlink()
We should not resolve a symlink target path recursively when installing a
symlink in the work tree. We want to handle this symlink's target, not the
end result of following a chain of symlinks in case such links already exist.
- Commit:
369fd7e5fa99b95f7d7aa812b5260584b86a3778
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add support for symlinks to 'got revert -p'
- Commit:
fa3cef63799016195e8a917f39c82815522692aa
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make 'got stage -p' work with symlinks
- Commit:
b448fd00850830156870881effc6cafd6233b8b6
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix wrong function name in an error message
- Commit:
0aeb8099a04ea427eff4a7b6cb52b1cba62a87b0
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
set a staged file type and handle it separately from the on-disk file type
- Commit:
c631b1152565e4c18cb2123e1d3d7c08d513c02f
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make staging of symlinks work
- Commit:
6131ab45b4ac2e03447e28d41d92c53ecfe632e3
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
remove pointless error checking in got_fileindex_entry_filetype_set()
- Commit:
6e1eade5c833f34c20301fd61b720268525270f8
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix 'got revert' progress output for symlinks