Show HN: Gomp – a tool for comparing Git branches(github.com)
github.com
Show HN: Gomp – a tool for comparing Git branches
https://github.com/MarkForged/GOMP
13 comments
Hey HN,
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!
[0] https://engineering.markforged.com/#/blog/post/welcome
[1] https://engineering.markforged.com/#/blog/post/preparing_gom...
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!
[0] https://engineering.markforged.com/#/blog/post/welcome
[1] https://engineering.markforged.com/#/blog/post/preparing_gom...
This can be genuinely useful.
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.
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.
Interesting tool!
When I first saw this, the term "GOMP" made me thing of gnu gcc "GOMP" --> gnu open multi processing.
When I first saw this, the term "GOMP" made me thing of gnu gcc "GOMP" --> gnu open multi processing.
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.
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.
Version 1.1 is now live, which should help the stability for a much wider variety of python versions, OSes, and Git Histories
it looks like some pull request/issues have been filed already so hopefully these get smoothed out soon.
When does it happen that two branches share random commits? I never had that happen in my use cases.
If you do a branch per minor version, with cherry picks on top of the minor version branch as bugs are fixed
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.
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