Interaction with git-imerge

[pokey]

When there is a merge conflict, I prefer to use git-imerge to resolve it:

git switch <branch>
git-imerge rebase main

However, this workflow leaves a bunch of garbage commits from the imerge process in my smartlog. What's the best way to hide them all at once?

Thanks!

[claytonrcarter]

You can look into using git hide -r <first garbage commit on old branch>.

Short of that, I've been tinkering w/ some other flags locally to make it easier to bulk hide commits, but I haven't stabilized them yet.

[pokey]

Yeah I looked into hide -r, but I don't think that solves the problem here, because I don't believe there's a common commit that will be a parent of all the garbage commits but not the ones that I want

[pokey]

See for example:

Note how there are garbage commits hanging off of every commit on the main branch

[claytonrcarter]

Oh, that's juicy. So imerge is generating both the imerge and Merge commit commits, none of which you want? And are you working w/ branches for most of this, or building commits w/o a branch pointer?

If you're working w/ branches, one of the flags I've been playing w/ is --prune, which is intended to hide all commits that aren't "on a branch", like git hide --prune @ to hide any dangling/non-branch commits on my current branch.

As is, though, your best bet is to either do the log grep trick that you mentioned, or use git hide -r but then manually copy/paste each of the root commits for the garbage trees. From this example, git hide -r 60af92e 3a191e3 5d3c326 would (I believe) end up hiding all of the imerge/Merge commit commits.

[pokey]

Ah prune is an interesting idea. Seems slightly counter to the "branchless" name tho 😅. But I'm one to talk: I work on something called Cursorless, which just so happens to be at its most powerful when used with multiple cursors 😄

But yeah prune could be useful for my other complaint, which is that when I merge a branch via GitHub squash, I have to both delete local branch and then hide the commits. Which obviously wouldn't be a thing if I were properly branchless, but 🤷

[pokey]

I wonder if there's some way to temporarily disable tracking? Could maybe use that while doing the imerge?

[claytonrcarter]

Do you know if imerge calls git hooks (like post-rewrite, etc)? Hooks like that are how branchless is able to keep track of which commits are rewritten, discarded, etc. If a 3rd party tool isn't calling hooks, then it's difficult (impossible?) for branchless to know that something has happened. I believe that git revise has a similar issue: mystor/git-revise#35

[pokey]

I would assume that it does. I see lots of git branchless spam during the imerge process

[arxanas]

@pokey Unfortunately, there's currently no way to skip commit detection in git-branchless, but it should be fairly simple to implement, if you're interested. It should just be a matter of checking to see if some environment variable BRANCHLESS_XXX is set at the beginning of this function and then bailing early if it is:

git-branchless/git-branchless/src/commands/hooks.rs

Line 69 in c4fb1a4

fn hook_post_commit_common(effects: &Effects, hook_name: &str) -> eyre::Result<()> {

[pokey]

This isn't pretty, but seems to do the trick if the imerge was in the past 30 minutes and you are rebasing (so there are no merge commits in your desired output history):

git hide $(git log --all --since="30 minutes ago" '--grep=^Merge' '--grep=^imerge' --format=format:%H)

[pokey]

Just an update in case someone lands here: as mentioned in #496, this command should work:

$ git hide 'descendants(draft() & message("regex:^Merge commit|^imerge") - ancestors(branches()))'

[arxanas]

Neat!