Applied, thanks.

Surprisingly, these two commands show different commit times:

	git blame README.asciidoc
	kak -e 'git blame' README.asciidoc

This is because git shows times as of the original time zone (of the
author/committer).  Our blame integration uses the current local time.

- blame-jump displays the date in the status line of a git-show buffer
  This date may be inconsistent with the buffer's "Date:" header,
  so this seems surprising. Fix that. This fixes a test in some
  time zones.
- Unlike "git blame", our ":git blame" does not display time zone
  info by default. So, the conversion to localtime might make sense.
[message trimmed]

On Wed, Jan 22, 2025 at 12:59:27PM -0700, Curtis Jewell wrote:
> I have to admit I like the idea... but I'd like to put
> the branch name as a trailer like the ones described in
> https://git-scm.com/docs/SubmittingPatches#sign-off (say, "Branch:")
> instead of in the first line of the commit message - that way I
> save my 55 characters in the commit's subject for other things.
> 
> My question is - can git-branchstack do this already,

not today.
As workaround, you could use short (one-letter) topic names,
and then simply clone/rename the branch using familiar Git tools

	git branchstack a

On Mon, Dec 09, 2024 at 05:24:49PM +0100, Johannes Altmanninger wrote:
> I don't see strong reasons not to load everything.
> I think some people do that, would be interesting to hear why.

So far I heard "to disable autoindent/autoinsert hooks" which does
not seem like a valid reason to not load filetype scripts at all.

This test uses ui_out and ui_in to coordinate events.
This is brittle[1] because ui_out behavior depends on timing.

Since this test doesn't really care about intermediate UI state,
express the sequence using BufCloseFifo instead.

This hits another issue: inside git blame-jump's BufCloseFifo, we
run git blame, which runs another "edit -fifo .. *git*".  A special
aspect of fifo buffers is that any existing *git* buffer will be
reused instead of being recreated[2].  After BufCloseFifo, the fifo
watcher destructor will reset the fifo flag, even if BufCloseFifo
has recreated the fifo buffer.  This breaks invariants and causes
the next fifo watcher destructor do fail its assertion.
[message trimmed]

FifoWatcher::read_fifo() deletes the fifo watcher in

	m_buffer.values().erase(fifo_watcher_id); // will delete this


which calls:           HashMap::unordered_remove()
                           constexpr_swap(m_items[index], m_items.back());
destructor called here --> m_items.pop_back();
                           m_index.remove(hash, index);

So hash map invariants (of buffer.values()) are broken, when calling
~FifoWatcher which fires BufCloseFifo hooks. Things blow up if those
hooks access buffer.values() such as by accessing cached highlighters
to redraw the buffer.  A shell call with a long sleep in the client
[message trimmed]

On Tue, Dec 10, 2024 at 10:04:50PM +1100, Maxime Coste wrote:
> This hangs when I run the tests here.

Same in CI; I've added a sourcehut CI job to my presubmit script now.

On Tue, Dec 10, 2024 at 06:21:22AM +0100, Nico Sonack wrote:
> On Tue, Dec 03, 2024 at 11:40:41PM UTC, Johannes Altmanninger wrote:
> 	#!/bin/sh
> 
> 	sleep .2
> 	exec /usr/local/bin/git $*

nice, I could reproduce. You should use quoted "$@" though instead of $*

FWIW one way to quickly find some places where synchronization is
missing, I inserted "sleep 1" into test/tools/git/blame-in-diff/script
until it worked.

This test first runs "git blame-jump" to show a diff buffer, then
"k:git blame<ret>" to show a Git blob view with blame annotations.

There are two issues causing timing-based failure:
1. we don't always wait for blame-jump to be rendered,
   causing the subsequent "git blame" to fail due to "missing diff
   header".
2. we wait for the blob view's fifo to be closed but don't wait for
   it to be rendered, causing assertion failures kak_selection

I could reproduce with wrapping git into a script that sleeps for
200ms.

The tricky part in this test is that we execute x after the blob view
[message trimmed]

On Tue, Dec 10, 2024 at 04:42:32PM +1100, mawww@kakoune.org wrote:
> From a quick look at that test script, I think there is a race condition as
> we do not wait for the correct refresh call, we get the one that immediately
> follows the draw_status instead of the one triggered by the keystroke.
> 
> Does this diff fix the issue ?
> 
> ```
> diff --git a/test/tools/git/blame-in-diff/script
> b/test/tools/git/blame-in-diff/script
> index 0cee0ca7..ba257e6a 100644
> --- a/test/tools/git/blame-in-diff/script
> +++ b/test/tools/git/blame-in-diff/script
> @@ -4,6 +4,7 @@ ui_out -until '{ "jsonrpc": "2.0", "method": "refresh",