New commits not shown when using overcommit to manage Git hooks

[scottjacobsen]

Description of the bug

When I commit a few times and then run git sl I see this:
┃ ◯ aba6ab9 3m test
┃ ┃
┃ ◯ b147149 2m test2
┃ ┃
┃ ● e37e0ee 6s test3

Then when I run git prev I see this:
┃ ◯ aba6ab9 6m test
┃ ┃
┃ ● b147149 4m test2

Here I would still expect to see e37e0ee as the next commit but it seems hidden

> git next
No more child commits to go to after traversing 0 children.

Then I do:

> git unhide e37e0ee
Unhid commit: e37e0ee test3
> git sl

And then I see:
┃ ◯ aba6ab9 8m test
┃ ┃
┃ ● b147149 6m test2
┃ ┃
┃ ◯ e37e0ee 4m test3

After than I can do git next and git prev as usual. So it seems like new commits are defaulting to the hidden state.

Expected behavior

I expect new commits not to be hidden.

Actual behavior

New commits appear to be hidden after switching to a different commit.

Version of rustc

No response

Automated bug report

No response

Version of git-branchless

git-branchless-opts 0.8.0

Version of git

git version 2.45.1

[scottjacobsen]

It appears it is a conflict with overcommit which clobbers the hooks installed by this project. Is it possible to "namespace" hooks so they don't collide, or is this a git limitation?

[arxanas]

I converted this issue to a discussion since it may benefit future users who may not look at the closed issues.

[arxanas]

@scottjacobsen The lack of support for multiple hooks of a given kind is a Git limitation, but sounds like overcommit itself is the solution for that?

git-branchless assumes that the hook is a shell script and then tries pretty hard to insert its own configuration without disturbing other configuration:

git-branchless/git-branchless-init/src/lib.rs

Lines 151 to 173 in ce1aa49

	fn update_between_lines(lines: &str, updated_lines: &str) -> String {
	let mut new_lines = String::new();
	let mut found_marker = false;
	let mut is_ignoring_lines = false;
	for line in lines.lines() {
	if line == UPDATE_MARKER_START {
	found_marker = true;
	is_ignoring_lines = true;
	append_hook(&mut new_lines, updated_lines);
	} else if line == UPDATE_MARKER_END {
	is_ignoring_lines = false;
	} else if !is_ignoring_lines {
	new_lines.push_str(line);
	new_lines.push('\n');
	}
	}
	if is_ignoring_lines {
	warn!("Unterminated branchless config comment in hook");
	} else if !found_marker {
	append_hook(&mut new_lines, updated_lines);
	}
	new_lines
	}

There is in principle support for using different hook management systems, if you wanted to try to add support for overcommit:

git-branchless/git-branchless-init/src/lib.rs

Lines 107 to 121 in ce1aa49

	/// A specification for installing a Git hook on disk.
	#[derive(Debug)]
	pub enum Hook {
	/// Regular Git hook.
	RegularHook {
	/// The path to the hook script.
	path: PathBuf,
	},
	/// For Twitter multihooks. (But does anyone even work at Twitter anymore?)
	MultiHook {
	/// The path to the hook script.
	path: PathBuf,
	},
	}

As an ad-hoc solution, it seems like you should be able to add the git-branchless hooks to overcommit: https://github.com/sds/overcommit?tab=readme-ov-file#adding-existing-git-hooks

• unfortunately, there is no formal documentation for the list of hooks that git-branchless installs, but you could find the list here:

  git-branchless/git-branchless/tests/test_init.rs

  Line 226 in ce1aa49

  Installing hooks: post-applypatch, post-checkout, post-commit, post-merge, post-rewrite, pre-auto-gc, reference-transaction

• I believe they're all invoked via git-branchless hook <name> <args>. The hook interface can be found in the Git docs, or inferred from the CLI configuration here:

  git-branchless/git-branchless-opts/src/lib.rs

  Lines 181 to 236 in ce1aa49

  	/// Internal use.
  	#[derive(Debug, Parser)]
  	pub enum HookSubcommand {
  	/// Internal use.
  	DetectEmptyCommit {
  	/// The OID of the commit currently being applied, to be checked for emptiness.
  	#[clap(value_parser)]
  	old_commit_oid: String,
  	},
  	/// Internal use.
  	PreAutoGc,
  	/// Internal use.
  	PostApplypatch,
  	/// Internal use.
  	PostCheckout {
  	/// The previous commit OID.
  	#[clap(value_parser)]
  	previous_commit: String,
  	/// The current commit OID.
  	#[clap(value_parser)]
  	current_commit: String,
  	/// Whether or not this was a branch checkout (versus a file checkout).
  	#[clap(value_parser)]
  	is_branch_checkout: isize,
  	},
  	/// Internal use.
  	PostCommit,
  	/// Internal use.
  	PostMerge {
  	/// Whether or not this is a squash merge. See githooks(5).
  	#[clap(value_parser)]
  	is_squash_merge: isize,
  	},
  	/// Internal use.
  	PostRewrite {
  	/// One of `amend` or `rebase`.
  	#[clap(value_parser)]
  	rewrite_type: String,
  	},
  	/// Internal use.
  	ReferenceTransaction {
  	/// One of `prepared`, `committed`, or `aborted`. See githooks(5).
  	#[clap(value_parser)]
  	transaction_state: String,
  	},
  	/// Internal use.
  	RegisterExtraPostRewriteHook,
  	/// Internal use.
  	SkipUpstreamAppliedCommit {
  	/// The OID of the commit that was skipped.
  	#[clap(value_parser)]
  	commit_oid: String,
  	},
  	}

  • note that some of those are not Git hooks, but instead describe re-entrant calls of git-branchless to itself in certain circumstances

[scottjacobsen]

Thanks for all the info. Ovecommit is polite enough to move the hooks it replaces to a hooks/old-hooks directory. It replaces these hooks: post-checkout post-commit post-merge post-rewrite

I installed branchless first, and then overcommit, so I'm not sure if branchless would have been able to insert itself into the overcommit hooks. Overcommit's files are ruby files, and not shell scripts, so I would guess not unless you made it super duper smart :).

As a temporary hack I added

puts "#{File.basename(__FILE__)} calling branchless"
`#{File.join(__dir__, "old-hooks", File.basename(__FILE__))} #{ARGV.join(" ")}}`
puts 'called branchless'

to the top of all the relevant overcommit hooks.

Thanks for finding the overcommit documentation though - I'll give that method a try - it seems cleaner!