On Thu, Jun 16, 2022 at 05:43:24PM +0200, Omar Polo wrote:
> Mark Jamsek <mark@jamsek.com> wrote:
> > On 22-06-17 12:59am, Mark Jamsek wrote:
> > > I habitually use {fossil,git} diff -v to see the diff I'm committing in
> > > vim when editing the commit message. It saves me all the time from
> > > missing things (see my previous commits for example).
> > > 
> > > Any objections to adding this?
> > > 
> > 
> > s/diff/commit
> > 
> > got commit -v
> 
> I didn't know about `fossil/git diff -v', but in general I'd like the
> idea.

I am a bit afraid that such a feature could lead to people accidentally
committing pf.c as their log message. The Git documentation claims that
the diff won't be part of the committed log message, but how can we filter
the diff out of the file again with 100% accuracy?
I don't think there is a reliable way. Once the user has had access to the
file and gives it back to us, we have no idea what the file contents mean
and we cannot assume that any meta-data we have about the log message is
still valid.

> what i'd really like, even more than putting the diff in the log edit
> buffer with all the consequences it has (i.e. that special line to
> differentiate between the log message and the diff), would be for `got
> diff' to work while `got commit' is waiting for the editor.
> 
> (blatantly a feature request since I haven't looked into how hard would
> be and which consequences it would have.)

The locks we use for the work tree are very simple exclusive locks.
As soon as a lock exists, everyone else is locked out. flock(2) does
not support a concurrent multi-reader single-writer model.

And there is no separate staging area like in Git. Staged changes just
add fileindex entries which point at blobs already written to the repo.

If we don't lock the work tree during commit we are effectively running
a transaction without protecting the integrity of transaction state.
Which could lead to file index corruption or unexpected changes creeping
into commits (e.g. a 'got add' command could modify the work tree while
the log message is being written).

Unlocking earlier than we do now is not an option because the work tree
needs to remain locked until we have updated its base commit ID to that
of the newly created commit. Which we obviously won't know until the
very end of the commit process.

> to be honest thought I got used to open an xterm with `got di | less' in
> it before doing a commit from the command line.

This is what I do as well. Or save the diff to a file, and load it
into a separate editor buffer to view log message and diff side-by-side.