git-machete: Wrong fork-point choice

Hi again! 😃

I get the following status:

artur@y510p:~/projects/rchain$ git machete status
  dev
  │ 
  └─mbm_memo (red, as expected)
  │ │ 
  │ └─post_memo_refactors
  │   │ 
  │   └─stacksafe_sorter
  │     │ 
  │     └─huge_string_concat (YELLOW!)
  │ 
  └─rho_parse
(other branches green)

Despite the huge_string_concat branch being up to date with stacksafe_sorter.

See the following history:

artur@y510p:~/projects/rchain$ git shortlog stacksafe_sorter..huge_string_concat 
Artur Gajowy (2):
      Patch a StackOverflowError
      PrettyPrinter uses Coeval internally

artur@y510p:~/projects/rchain$ git shortlog stacksafe_sorter...huge_string_concat 
Artur Gajowy (2):
      Patch a StackOverflowError
      PrettyPrinter uses Coeval internally

artur@y510p:~/projects/rchain$ git log  --graph --decorate --oneline --branches=huge_string_concat 
* 2034607 (HEAD -> huge_string_concat, origin/huge_string_concat) PrettyPrinter uses Coeval internally
* 29f3fed Patch a StackOverflowError
* 4d876d1 (origin/stacksafe_sorter, stacksafe_sorter) Add Sync effect context bound where needed by Mateusz Górski
* 83e073a Patch-up usages of Sortable.sortMatch
* e2d8d6e ReceiveBindsSortMatcher returns via F
* 76afa82 BoolSortMatcher returns via F
* 591d8f8 VarSortMatcher returns via F
* 1fb6690 SendSortMatcher returns via F
* ebd3c62 ReceiveSortMatcher returns via F
* aba5f9b ParSortMatcher returns via F
* 3b57fc6 NewSortMatcher returns via F
* 159f9ed MatchSortMatcher returns via F
* 55b61b8 GroundSortMatcher returns via F
* 237a5fb ConnectiveSortMatcher returns via F
* 435dc44 ChannelSortMatcher returns via F
* 3ebccbd BundleSortMatcher returns via F
* c5bf1dc ExprSortMatcher returns via F
* d931c9e Sortable returning via a suspendable effect
* 2034607 (HEAD -> huge_string_concat, origin/huge_string_concat) PrettyPrinter uses Coeval internally
* 29f3fed Patch a StackOverflowError
* 4d876d1 (origin/stacksafe_sorter, stacksafe_sorter) Add Sync effect context bound where needed by Mateusz Górski
* 83e073a Patch-up usages of Sortable.sortMatch
* e2d8d6e ReceiveBindsSortMatcher returns via F
* 76afa82 BoolSortMatcher returns via F
* 591d8f8 VarSortMatcher returns via F
* 1fb6690 SendSortMatcher returns via F
* ebd3c62 ReceiveSortMatcher returns via F
* aba5f9b ParSortMatcher returns via F
* 3b57fc6 NewSortMatcher returns via F
* 159f9ed MatchSortMatcher returns via F
* 55b61b8 GroundSortMatcher returns via F
* 237a5fb ConnectiveSortMatcher returns via F
* 435dc44 ChannelSortMatcher returns via F
* 3ebccbd BundleSortMatcher returns via F
* c5bf1dc ExprSortMatcher returns via F
* d931c9e Sortable returning via a suspendable effect
* e14302f ScoreTree contravariant
* 1633c5a (origin/post_memo_refactors, post_memo_refactors) Introduce OptionWithCost and StreamWithCost type aliases
* 1fd68c3 Remove 'type parameter shadows type' warnings
* cea49dc Remove 'implicit numeric widening' warnings
* cde4a07 Rename `varLevel` to `remainder` in `listMatchSingle_` and downstream
* 6e19240 Replace a nested pattern match with a single pattern
* 2f8234c Replace `possilbyFind` with a call to `collectFirst`
* b6c742c Remove unnecessary use of NonDetFreeMapWithCost
* 90a2f04 (origin/mbm_memo, mbm_memo) Memoize calls to matchFunction

This looks like a bug to me 😃 Let me know if you need more info 😃

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 16 (6 by maintainers)

Commits related to this issue

Issue #396: (Option #3) Use root user in the container, non-root locally (#422) — committed to VirtusLab/git-machete by amalota 2 years ago

Most upvoted comments

Looks like the commit 29f3fed is present on the reflog of some local branch X (where X != huge_string_concat), and thus was deemed by machete’s fork-point heurestics as not a part of unique history of huge_string_concat. I already got asked the “yellow edge” question a couple of times, I’ll provide soon a detailed logging for fork-point algorithm available under --verbose so that users can see for themselves why a given commit (and not the other) was chosen a fork point. This of course doesn’t mean that the fork-point algorithm itself can’t be changed if we decide an improvement is possible.

As for now, to make sure this is behavior isn’t anything unexpected under current fork-point algorithm, could you post the result of the same command as for #2: git for-each-ref --format='%(refname:short)' refs/heads | xargs -t -L1 git --no-pager reflog --format=%H

PawelLipski on Sep 11, 2018