If you're curious how the Mercurial absorb command works, here's the code: https://www.mercurial-scm.org/repo/hg/file/tip/hgext/absorb.py It's GPL 2: https://www.mercurial-scm.org/repo/hg/file/tip/COPYING On Tue, Oct 2, 2018 at 2:11 AM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > On Tue, Oct 02 2018, Taylor Blau wrote: > >> Hi Stefan, >> >> On Sat, Sep 29, 2018 at 04:00:04PM -0700, Stefan Xenos wrote: >>> Hello, List! >>> >>> I'm interested in porting something like Mercurial's evolve command to >>> Git. >> >> Welcome to Git :-). I think that the discussion in this thread is good, >> but it's not why I'm replying. I have also wanted a Mercurial feature in >> Git, but a different one than yours. >> >> Specifically, I've wanted the 'hg absorb' command. My understanding of >> the commands functionality is that it builds a sort of flamegraph-esque >> view of the blame, and then cascades downwards parts of a change. I am >> sure that I'm not doing the command justice, so I'll defer to [1] where >> it is explained in more detail. >> >> The benefit of this command is that it gives you a way to--without >> ambiguity--absorb changes into earlier commits, and in fact, the >> earliest commit that they make sense to belong to. >> >> This would simplify my workflow greatly when re-rolling patches, as I >> often want to rewrite a part of an earlier commit. This is certainly >> possible by a number of different `git rebase` invocations (e.g., (1) >> create fixup commits, and then re-order them, or (2) mark points in your >> history as 'edit', and rewrite them in a detached state, and I'm sure >> many more). >> >> I'm curious if you or anyone else has thought about how this might work >> in Git. > > I've wanted a "git absorb" for a while, but have done no actual work on > it, I just found out about it. > > I think a combination of these two heuristics would probably do the > trick: > > 1. If a change in your "git diff" output has a hunk whose lines overlap > with an earlier commit in the @{u}.. range, we do the equivalent of > "git add -p", select that hunk, and "git commit --fixup <that > commit>". We fixup the most recent commit that matches (otherwise > commit>we'd conflict). > > 2. Have some mode where we fall back from #1 and consider changes to > entire files, if that's unambiguous. > > The neat thing about this would be that you could tweak how promiscuous > #1 would be via the -U option to git-diff, and #2 would just be a > special case of -U9999999999999 (we should really add a -Uinf...). > > Then once you ran this you could run "git rebase -i --autosquash" to see > how the TODO list would look, and optionally have some "git absorb > --now" or whatever to do the "git add -p", "git commit --fixup" and "git > rebase --autosquash" all in one go. > >> [1]: http://files.lihdd.net/hgabsorb-note.pdf
