Here it is: https://gist.github.com/cmurphycode/6a134f8d383d08b024be6c17dda23891
https://gist.github.com/cmurphycode/31a6bd4eafaa9f6e32f7fa465a27ec6d On Tuesday, August 8, 2017 at 5:50:40 PM UTC-4, Igor Djordjevic wrote: > > Hmm... For what it`s worth, another two to try out (note addition of > "--ancestry-path"): > > (*1*) git log --graph --format=%h --sparse --full-history --ancestry-path > 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchA > > (*2*) git log --graph --format=%h --sparse --full-history --ancestry-path > 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchB > > Hopefully, these two can show a bit simpler graphs of how > 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc eventually gets in both "branchA" > and "branchB". > > On Tuesday, August 8, 2017 at 10:12:21 PM UTC+2, Chris Murphy wrote: >> >> Definitely: >> >> - branches made from branchA which are merged into branchA >> - branchA has been merged into branchB at least once >> >> and probably: >> branches made from branchA which are merged into branchB >> >> Here's the result of the commands - doesn't seem like they affected the >> doubledot result: >> >> >> ± % git log --format=%H --sparse --full-history branchA..branchB | grep >> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >> >> ± % git log --format=%H --sparse --full-history branchA | grep >> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >> >> ± % git log --format=%H --sparse --full-history branchB | grep >> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >> >> ± % shasum <(git log --format=%H branchA..branchB) <(git log --format=%H >> --sparse --full-history branchA..branchB) >> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9 /dev/fd/11 >> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9 /dev/fd/12 >> >> >> I did some long-shot exploring as well. I thought it might be interesting >> to try to narrow down when this problem "happened". >> >> ± % git log branchA --oneline | head -1100 | while read id junk; do git >> log $id..branchB | grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc || echo >> $id; done | grep -v commit >> d257212899 >> 07c8974cbf >> 8c9dac3f13 >> 190772b842 >> 33ae1d39bd >> 4ff39884f6 >> 283e0c6056 >> >> Essentially, if you walk down the git log for branchA, you get all "false >> positives" until d257212899 which is "correct". (And after 283e0c6056, the >> next several hundred are correct as well) >> >> That makes 1a6035b06eebbeed6ce2ea4bf3058360f261f8fa the "last" (according >> to git log order) false positive. >> Was hoping that closer look at that commit will help, but haven't found >> anything yet. >> >> >> On Tuesday, August 8, 2017 at 3:54:16 PM UTC-4, Igor Djordjevic wrote: >>> >>> On Tuesday, August 8, 2017 at 2:38:09 PM UTC+2, Chris Murphy wrote: >>>> >>>> You're right, I didn't mean to leave the --tags=1 in. I double checked >>>> that the --tags and greps didn't remove any lines from the output. >>>> >>>> However, I did overlook the carat syntax - on zsh, those need to be >>>> escaped. I repeated this with escapes and also double-checked against bash >>>> just in case. I think this is what you wanted: >>>> >>>> https://gist.github.com/cmurphycode/5df15669ce1e5c33f3e69d997b465d6d >>>> >>> >>> This one looks interesting, as we can see both 03dd551f03 (merge base) >>> and 9ba8f06829 (your initial "surprising" commit) in there. By the looks of >>> that graph only, it seems clear that 9ba8f06829 does not belong to >>> "branchA" (its graph ending with merge base commit) -- but, that may be >>> true considering "branchA", "branchB" and the merge base commit >>> 03dd551f03 _only_. >>> >>> Do you have other branches in your repository, where some of them >>> are/were merged to/with these two branches we`re looking at? If so, that >>> might explain the situation further. >>> >>> But even if not, I`m thinking if Git`s *"history simplification"* >>> <https://git-scm.com/docs/git-log#_history_simplification>[1] could be >>> the the culprit here...? Could you try your initial commands again, but >>> adding "--sparse" and "--full-history" to them as well? I`m not sure if >>> there are any other "do not simplify history" switches. >>> >>> So if you could try running something like this (note %h changed to %H >>> as well): >>> >>> (*1*) $ git log --format=%H --sparse --full-history branchA..branchB | >>> grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >>> >>> (*2*) $ git log --format=%H --sparse --full-history branchA | grep >>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >>> >>> (*3*) $ git log --format=%H --sparse --full-history branchB | grep >>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc >>> >>> >>> https://gist.github.com/cmurphycode/114c869323d6d161fd77aa924e769bcd >>>> >>>> Here's what the branches point to as of right now, just to be sure :) >>>> >>>> ± % git show-ref branchA >>>> c7770ea9a062d189dc2e3238bdd6f5987d86e1cb refs/heads/branchA >>>> >>>> ± % git show-ref branchB >>>> 944405f8308c77200f7f4cb860a3f95a7a8ba6dd refs/heads/branchB >>>> >>>> Thanks for your patience, I appreciate the help! >>>> >>> >>> No problem, I`m not sure how much helpful I`ll prove to be in the end, >>> but I do find the case interesting, learning something new myself :) >>> >>> [1] https://git-scm.com/docs/git-log#_history_simplification >>> >>> Regards, >>> Buga >>> >> -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
