Append a commit or rewrite all commits ?

[ewjoachim]

(disclamer: rewriting history of merged commits is bad, I know, just exploring the idea for the sake of it)

In the one hand, rewriting history is bad. But in the other a huge big bang commit is equally bad for being able to use git blame and understanding where a commit comes from.

So I would find it interesting to be able to retrospectively blacken all commits in git history one by one in a PR. Or if you're YOLO, for the whole repo.

For the whole repo, this can be done with git filter-branch --tree-filter "git ls-files |xargs black" -- --all. (it a similar construct for a single PR with something instead of --all, probably <target-branch>..<pr-branch> but I haven't tried). But in real life you don't want to rewrite history of your whole repo, that would be bad.

This would mean the bot would rewrite commits but as far as I can tell, git filter-tree doesn't change the committer, so it wouldn't appear as co-author (we could add a Co-Authored-By` field, though). But, quite logically, this removes GPG signature from commits and tags. And rewriting the whole repo is madness, did I mention it ? Would be cool still. 🙃

[webknjaz]

Maybe inject black fixup commits in between user-created ones? This way the user could attempt to squash related things fairly easily if they want it...

P.S. I also do not like wholesale commits like this

[ewjoachim]

I like this idea, this would allow a clear PR where you can check the diff, and then the repo owner would be resposible for the (madness of) rewriting the whole history.

But is there a way to fixup that wouldn't create rebase conflicts ? Not sure.

I was already surprised that git filter-branch would manage to blacken all commits without getting lost in applying the diffs. I don't know enough of the git internal specifics, but I guess git filter-branch is able to work on the state of the tree at each commit, whereas my experience with rebase is that it really much more works on the diff each commit introduces. But, again, I'm no git expert.

[webknjaz]

You can try injecting two commits, not one. Fixup + its revert. This would probably simplify the interactive rebase part. Then, you could squash those reverts with the following commits...

But yes, you are right. It's not exactly trivial. I'm currently helping out with packaging of pygit2 wheels so hopefully it will be possible to get those easily installable soon. It's interface should simplify plumbing level Git interactions...

[ewjoachim]

Hmm, it's interesting but the --autosquash flag on rebase only allows moving commits to right after existing ones, and the 2 only commit merge actions, fixup and squash, only merge with the previous commit.

I'll need an example:
there's A ---- B, you're blackouting the repo, so you'll get 3 commits: A-Black, A-Black-Revert and B-Black : A --- A-Black --- A-Black-Revert --- B --- B-Black

There's 2 possible todo here:

pick A
fixup A-Black
reword A-Black-Revert
fixup B
fixup B-Black

but you'd have to manually enter B's commit message at the reword step, or

pick A
fixup A-Black
pick A-Black-Revert
squash B
fixup B-Black

But, again, you'd have to enter B's commit message at the squash step.

And non of those solutions can be achieved using fixup! or squash! commits only wich kinda defeats the purpose...

Except if I'm mistaken ?