Long time reader, first time caller, and the author of git-absorb. If the line offsets of the hunks don't overlap, then they commute and nothing will be absorbed. But if you want to absorb at the granularity of whole files instead, there's -w. It's intentional that this is not the default behavior - eg it wouldn't make sense for a long branch touching the same file repeatedly - but it might be appropriate for this use case.

Hi Chris,

Why even use a third-party tool for this? I solve this problem often. (5 steps, but worth it every time)

Step 1: Add your additional commit on top.

Step 2: Run bash$ git rebase --interactive $REBASE_COMMIT ;

Step 3: You are now in a text editor. Move the line of your new additional commit above (below?) the commit you want to "change destructively" and change its type to "fixup". Move your personal commit lines to the top.

Step 4: Exit the text editor. Everything should apply cleanly now.

Step 5: Profit. (You are done.)

Nota bene: The only git manual ever worth reading was John Wiegley's Git from the Bottom Up.

Nota bene: This kind of rebasing, together with email patches shows that going with commit hashes is actually a bit ridiculous. People (and git) should be mostly interested in tree hashes. Git already knows them. It just decides against showing them. Those are solely content based. Commit hashes change when the commit time changes. There are cases where this is useful, but they are rarer than people seem to use them in practice. Got porcelain is mostly sharp edges. Will now go bandage my hand. Again.

Thanks for the comment, tummychow; I missed the -w argument because it's omitted from the manual page in the current Fedora package (although 'git-absorb -h' includes it). I'll have to remember to check 'git-absorb -h' or the online manual page in the future.

Yeah, sorry about the manpage. A contributor has been generously burning down a bunch of old issues (including that) but I haven't cut a new release yet. Will likely do so in the next ~week.

I believe this is what "git commit --amend" does? It removes the last commit and re-commits it with the added information.

You also seldom need to find out the last commit id. That's what HEAD is. But HEAD is mostly redundant since it is often the default.

FWIW, though it is of course very convient to have a tool that automatically figures out which commits to fix up, a bit of dumber tooling makes it at least not painfully inconenient to do the rest of the job manually. For the longest time I’ve had this alias:

git config --global alias.fu '!c=`git rev-parse --short "$1"` && shift && git commit -m "fixup! $c" "$@" && :'

This exists to enable the following ~/bin/git-autorebase command, which (somewhat akin to git merge-base) answers the question “which commit do I have to rebase from in order for all of my fixups to get applied?” and thereby allows me to say git rebase --autosquash `git autorebase`:

#!/usr/bin/perl
use strict; use warnings;

my $hash = '[0-9a-f]{40}';

open my $pipe, '-|', qw( git rev-list --topo-order --oneline --no-abbrev-commit HEAD )
	or die "Couldn't open pipe to git rev-list: $!\n";

my ( $in_startup, %target ) = 1;

while ( readline $pipe ) {
	my ( $sha1, $msg ) = /^($hash) (.*)/o or die "Malformed input: $_";

	my $have_match = $msg =~ s/^(?:fixup|squash)! +(?=[^ ])//;

	unless ( $in_startup or $have_match or %target ) {
		print $sha1, "\n";
		last;
	}

	while ( my ( $k, $rx ) = each %target ) {
		delete $target{ $k } if $_ =~ $rx;
	}

	if ( $have_match ) {
		$in_startup = 0;
		my $rx = quotemeta $msg;
		$target{ $msg } = qr/^(?i:$rx)|^$hash $rx/;
	}
}

die "No autosquash/autofixup commits found\n"
	if $in_startup;

die "Invalid autosquash/autofixup commit(s): @{[ sort keys %target ]}\n"
	if %target;

(What this does is it scans the history from the HEAD commit backwards until it encounters a “fixup!” or “squash!” commit, then scans backwards further, picking up any additional fixup or squash commits along the way, until it has encountered all the commits that the fixups and squashes belong to, and then spits out the first commit beyond that.)

I haven’t gotten git absorb to work for me, but provided that it writes its fixup commits with commit hashes, git autorebase will seamlessly work together with it as well, in which case you could mix and match any of these tools.