
Show HN: Gomp – a tool for comparing Git branches - philipkiely
https://github.com/MarkForged/GOMP
======
tomstuart
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).

[0] [https://git-scm.com/docs/git-range-diff](https://git-scm.com/docs/git-
range-diff)

~~~
Fiveplus
Another neat command added to the arsenal. Thanks for linking this here.

------
philipkiely
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](https://engineering.markforged.com/#/blog/post/welcome)

[1]
[https://engineering.markforged.com/#/blog/post/preparing_gom...](https://engineering.markforged.com/#/blog/post/preparing_gomp)

------
outsomnia
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.

------
ggerules
Interesting tool!

When I first saw this, the term "GOMP" made me thing of gnu gcc "GOMP" \-->
gnu open multi processing.

------
xxpor
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.

~~~
philipkiely
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.

------
HugThem
When does it happen that two branches share random commits? I never had that
happen in my use cases.

~~~
xxpor
If you do a branch per minor version, with cherry picks on top of the minor
version branch as bugs are fixed

~~~
Nullabillity
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.

~~~
HugThem
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.

