Commits
- Commit:
3969253a0514c1e4c685eb413d74cd89f40ecaf0
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
remove implicit entry update from got_fileindex_entry_alloc(); just alloc
- Commit:
ef6337de1aa046d1d1aac4bea349644ba9a0f649
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
bump version number
- Commit:
cff5d32f5a46800c1429011dad94c5b20b28501c
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
change for 0.29
- Commit:
15341bfd54bbabbe30297c358faf41ee05e247da
- From:
- Tracey Emery <tracey@traceyemery.net>
- Date:
trim directories in got remove -R
This is a racy solution that needs to be properly implemented in the future.
ok stsp
- Commit:
5b87815ed2f346f81374261ce2d633feae711886
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
prevent commits from being listed more than once in a histedit script
While merging a commit multiple times during a histedit operation could
potentially make sense in some corner case, a commit appearing more than
once in the script is more likely to happen accidentally.
If desired, the same effect can still be achieved by running multiple
histedit operations, or by using 'got cherrypick' while the histedit
operation is paused for arbitrary editing.
- Commit:
de05890fef951240ac68a3ea9a577a6f82be6194
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix histedit 'rebase commit ID mismatch' error when splitting a commit
Commit IDs on histedit's temporary branch can change arbitrarily because
the user may create new commits on this branch while editing past commits.
So there is no point in trying to verify these IDs like we do during rebase.
Add a test case which demonstrates the problem.
- Commit:
4cb8f8f3e6cc4a795c92823235070dd921c2b42e
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix wrong use of words in a histedit error message
- Commit:
37486c756a36ae590b41cae752b0c129f5fb7ff7
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make our README file point at our website
- Commit:
4b6c9460c99283f193f32bd5177bb09047abacf3
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
be helpful when users try to check out work trees without a known branch
Provide a useful error message in such cases and explicitly document
intentional restrictions in the got(1) man page.
Prompted by a question from Adam Steen via bsd.network
https://bsd.network/@adams/103768951483318235
- Commit:
ee85c5e898e10f72841c918d9f453a6526ef7e2e
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
map 'tog path' to 'tog log path' if possible; requested by mpi@
- Commit:
b8b3f2090ed097020d494dbf50d92a34c669707d
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make got_path_is_root_dir() deal with an arbitrary amount of leading slashes
- Commit:
61a7d79fef51b4bf48411fcd4542401f10acc626
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
remove GOT_ERR_NOT_ABSPATH and fix existing users to deal with absolute paths
- Commit:
63f810e6fee43e699585195a24eebdb53a99a4f4
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
when "bad path" errors occur, always show the path in question
- Commit:
a2f4a3591f215ab55f58ef4ee630b960af87a4d5
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
properly free cmd_argv in tog's main() function
- Commit:
dfd6c25013ffa89ef7879d8f6a2548f989c4f3ea
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix typo in comment; found by mpi@