Until `perist()` is truly atomic also on Windows, and modelled
[after Git](https://github.com/git/git/blob/master/compat/mingw.c#L2159-L2209),
sans the retries, it seems to work to just perform ordinary writes.
Before going there though, we try to call `sync_all()` on Windows to truly
finish the operation. On Unix, a rename is already supposed to be atomic.
GB writes files atomically and in the end it boils down to allocating bytes
and writing them all at once.
Now this capability lives in the `fs` module.
Instead, respect the existing bit if set in Git, but do not try
to derive it from the filesystem which is something Git doesn't
seem to be doing on Windows either.
This also makes me think that `gitoxide` should make it easy
to build a tree from a file and deal with this.
This will prevent half-written content on disk in case the write is interrupted.
Lock files are *not* used as the assumption is that a lock is held centrally.
We still need to fix the off-by-one bug affecting hunk end lines. When we add start_line + line_count we end up with an extra line. For example, with start_line 1, and line_count 1, the range is 1:1, not 1:2.
- replaces commit walking with a git blame
- limited to specific hunk lines
- earliest_commit set to default target
- lock if any blame other than boundary commit
- intersection uses context lines
Sometimes, symbolic refs are used as tracking branches, like
`refs/remotes/origin/HEAD`, and after some changes are dangling,
pointing to a ref which doesn't exist anymore (maybe it was renamed
from `master` to `main`).
Now, this isn't fatal anymore, but will be logged instead.
In the previous commit it was stated that the 'unfolding' of errors might
have been intentional to surface root causes of error messages.
However, this might have been wrong, and this commit brings back root-causes explicitly,
while erroring on the side of caution. That is, "Something went wrong" probably won't
be shown anymore, instead, possibly too much will be displayed and we'd rather tune
that down once it becomes clear which messages are needed, or should be improved.
Overall, I think it's best to show more, and then tune errors with custom context
where needed.
