This looks similar in spirit to `git range-diff` [0], which may interest anyone who wants more visibility of what’s changed between branches (e.g. before and after a rebase).
I've been working at Markforged for about a month, and I've been thrilled to be involved with launching a pilot open-source project and our engineering blog [0]. This is the first time we've released an internal tool to the public [1] and I think it is an important step for the team.
AMA about how to get an internal tool open-sourced!
If you use rebase flow on your development branch, then fork to history flow for stable release branches, this can give insight into what was or wasn't backported subsequently, as long as you try to keep atomic patches.
I wanted to like this tool, but it seems a bit unpolished still. Apparently it doesn't support 3.6 at all, I just got a backtrace about an extra parameter to some subprocess call. Figuring it was a version issue I switched to 3.8, which got past that, but then when I tried to compare 2 branches that I hadn't checked out locally yet I got a different traceback, ending in:
File "/home/lol/.pyenv/versions/3.8.3/lib/python3.8/site-packages/gomp/gomp.py", line 132, in find_first_common_hash
if source_commit[i][0] == _hash:
IndexError: list index out of range
Then, after checking out those 2 branches, I got the table but the commit msgs were cut off from the front, here's an example:
874464e s bug
There's obviously something before that s.
This isn't a support forum obviously, but just something to be aware of.
I was interested in this because we have the issue of trying to figure out the new commits between releases. We have a branch with cherry-picks per release, and so enumerating new commits between these 2 branches isn't straightforward or even necessarily well defined.
I will look into all of that. One thing I have learned today is that while an internal tool might be extremely battle-tested against a narrow slice of use cases and environments, public scrutiny will uncover numerous issues.
The cherry pick will refer to a different history, so it will have a different commit hash (and thus be considered a separate and independent commit by any sane tooling, including Git itself).
This seems to work around that by matching on the commits' summary lines instead, which only (sort of) works because their workflow disambiguates this (1 commit per issue, each commit is prefixed with the issue ID).
Then again, most of their desire for this tool seems to come from their broken rebase-oriented workflow stomping all over commit hashes in the first place (on top of ensuring that what was tested and reviewed no longer matches what was merged, while destroying the history that could help someone trying to diagnose the issue).
Play stupid games, win stupid prizes, I guess. Your history isn't, has never been, and will never be linear. Whether or not you rewrite your logs to make it seem that way.
I think making the commit summary the "id" of this workflow is actually interesting. It is a step towards doing project management in git itself rather then an external tool.
[0] https://git-scm.com/docs/git-range-diff