[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

Thanks - can you check my post above "I did some long-shot exploring as 
well" -- is that what you mean? I'm not sure


On Wednesday, August 9, 2017 at 6:44:55 PM UTC-4, Igor Djordjevic wrote:
>
> Unfortunately, the graphs are too long and complicated for some more 
> serious eyeballing, but important point should be _there are_ graphs, 
> meaning both "branchA" and "branchB" contain commit 
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc... but that we already knew, I`m 
> afraid.
>
> So, it does seem like both these commands` output is unexpected:
>
> (*1*) $ git log --format=%H --sparse --full-history branchA..branchB | 
> grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
> (*2*) $ git log --left-right branchA...branchB | grep 
> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>
> ... where they both find the commit in question, case (2) showing it as 
> belonging to "branchB". At least these two seem to be in some agreement 
> between themselves :P
>
> I`m getting out of ideas :/ You could try adding "-m" parameter to the mix 
> (if that makes any sense), or removing "--sparse", and seeing if anything 
> different comes up. Ideally, it would be good to get a (much) shorter 
> history with the same behavior which could be examined more easily, but 
> yeah...
>
> I`m talking from the top of my head, but maybe a script which will walk 
> "branchA" history and do "two dot" range specification with each commit in 
> "branchB" history, searching for cases which yield commits which still 
> appear in both "branchA" and "branchB" history (so something fishy is 
> happening with "log" function, like with sample commit 9ba8f06829 above), 
> and finally checking the distance of these "false positive" commits  from 
> "branchA" and "branchB" commits used inside "two dot" range specification.
>
> The shorter the distance, the better the commit candidates are for 
> examination.
>
> Or/and, you could try bringing this question up on the main *Git mailing 
> list* [1], might be it`s something obvious for people much 
> more involved with Git internals :)
>
> [1] g...@vger.kernel.org 
>
> Regards,
> Buga
>
> On Wednesday, August 9, 2017 at 12:48:28 AM UTC+2, Chris Murphy wrote:
>>
>> 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 

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Unfortunately, the graphs are too long and complicated for some more 
serious eyeballing, but important point should be _there are_ graphs, 
meaning both "branchA" and "branchB" contain commit 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc... but that we already knew, I`m 
afraid.

So, it does seem like both these commands` output is unexpected:

(*1*) $ git log --format=%H --sparse --full-history branchA..branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
(*2*) $ git log --left-right branchA...branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc

... where they both find the commit in question, case (2) showing it as 
belonging to "branchB". At least these two seem to be in some agreement 
between themselves :P

I`m getting out of ideas :/ You could try adding "-m" parameter to the mix 
(if that makes any sense), or removing "--sparse", and seeing if anything 
different comes up. Ideally, it would be good to get a (much) shorter 
history with the same behavior which could be examined more easily, but 
yeah...

I`m talking from the top of my head, but maybe a script which will walk 
"branchA" history and do "two dot" range specification with each commit in 
"branchB" history, searching for cases which yield commits which still 
appear in both "branchA" and "branchB" history (so something fishy is 
happening with "log" function, like with sample commit 9ba8f06829 above), 
and finally checking the distance of these "false positive" commits  from 
"branchA" and "branchB" commits used inside "two dot" range specification.

The shorter the distance, the better the commit candidates are for 
examination.

Or/and, you could try bringing this question up on the main *Git mailing 
list* [1], might be it`s something obvious for people 
much more involved with Git internals :)

[1] g...@vger.kernel.org

Regards,
Buga

On Wednesday, August 9, 2017 at 12:48:28 AM UTC+2, Chris Murphy wrote:
>
> 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 

[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

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"* 
>>> [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-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

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"* 
>> [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] 

[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

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"* 
> [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.

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

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"* 
[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.

[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

One more thing that may be of interest; this is not the only commit that is 
behaving badly.

git log branchA..branchB --oneline | while read id junk; do git log branchA 
| grep $id; done

Merge: 95aadbe485 dae6c2c57b
commit dae6c2c57b49c934c5c5af248a2f8a6cfcf3006d
commit e4b165feb93c0157fb738124961527ef6af5716d
Merge: e4b165feb9 610742e226
commit f8e568e192e6bde2711fc0ad2f5fdf56198faf02
Merge: f18e5a91ad b9cbe3dc68
commit f18e5a91ad48263633ca767188c1f8028ec707e2
Merge: f18e5a91ad b9cbe3dc68
commit b9cbe3dc68a9b0b987fa5be50d46b77115a68dde
commit 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc

On Tuesday, August 8, 2017 at 8:38:09 AM UTC-4, 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
>
> 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!
>
>
>
> On Tuesday, August 8, 2017 at 2:45:07 AM UTC-4, Igor Djordjevic wrote:
>>
>> Hi Chris,
>>
>> On Tuesday, August 8, 2017 at 4:02:43 AM UTC+2, Chris Murphy wrote:
>>>
>>> Oh man, sorry, I totally screwed up when editing the output to exclude 
>>> tags, making the graph totally wrong since some lines were missing. Sorry 
>>> about that.
>>>
>>> I've fixed that issue (Sorry, I still have to edit out tags. I'm 
>>> using grep -o ".*[0-9a-f]\{10\}\|.* $", and open to any better suggestions)
>>>
>>>
>>> Here's command 1
>>> git log --tags=1 --format=%h\%d --graph --sparse --full-history branchA 
>>> branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^ | grep -o 
>>> ".*[0-9a-f]\{10\}\|.* $"
>>> https://gist.github.com/cmurphycode/84d7efae872a4f23dfb01efdad4836e7
>>>
>>> command 2
>>> git log --format=%h\%d --graph --sparse --full-history branchA branchB 
>>> ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^ | grep -o ".*[0-9a-f]\{10\}\|.* 
>>> $"
>>> https://gist.github.com/cmurphycode/0498a5530e68382d32f1833dfd669311
>>>
>>
>> That looks much better, but I`m not sure if it can/should still be 
>> trusted, either, as "--tags=1" parameter you added can cause (pretty much?) 
>> all history to still be included, missing the point of last ^{commit}^ 
>> restriction, and might be grepping could still omit some lines...?
>>
>> If you would prefer not showing tags, maybe the easiest approach would be 
>> omitting "decorations" placeholder "%d" inside "--format" parameter 
>> altogether:
>>
>> (*1*) $ git log --format=%h --graph --sparse --full-history branchA 
>> branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^
>>
>> ... and:
>>
>> (*2*) $ git log --format=%h --graph --sparse --full-history branchA 
>> branchB ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^
>>
>> This should produce desired graph history with only commit sha1`s shown, 
>> no need to grep anything out.
>>
>> We already know the commits branches A and B point to from your previous 
>> examples, so missing these should not be a problem -- unless your history 
>> changed further, in which case you could write these to the right of 
>> corresponding commits by hand (paying attention not to break the graph 
>> layout - in case you`re not sure, better just leave it as it is).
>>
>> 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.

[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

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

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!



On Tuesday, August 8, 2017 at 2:45:07 AM UTC-4, Igor Djordjevic wrote:
>
> Hi Chris,
>
> On Tuesday, August 8, 2017 at 4:02:43 AM UTC+2, Chris Murphy wrote:
>>
>> Oh man, sorry, I totally screwed up when editing the output to exclude 
>> tags, making the graph totally wrong since some lines were missing. Sorry 
>> about that.
>>
>> I've fixed that issue (Sorry, I still have to edit out tags. I'm 
>> using grep -o ".*[0-9a-f]\{10\}\|.* $", and open to any better suggestions)
>>
>>
>> Here's command 1
>> git log --tags=1 --format=%h\%d --graph --sparse --full-history branchA 
>> branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^ | grep -o 
>> ".*[0-9a-f]\{10\}\|.* $"
>> https://gist.github.com/cmurphycode/84d7efae872a4f23dfb01efdad4836e7
>>
>> command 2
>> git log --format=%h\%d --graph --sparse --full-history branchA branchB 
>> ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^ | grep -o ".*[0-9a-f]\{10\}\|.* 
>> $"
>> https://gist.github.com/cmurphycode/0498a5530e68382d32f1833dfd669311
>>
>
> That looks much better, but I`m not sure if it can/should still be 
> trusted, either, as "--tags=1" parameter you added can cause (pretty much?) 
> all history to still be included, missing the point of last ^{commit}^ 
> restriction, and might be grepping could still omit some lines...?
>
> If you would prefer not showing tags, maybe the easiest approach would be 
> omitting "decorations" placeholder "%d" inside "--format" parameter 
> altogether:
>
> (*1*) $ git log --format=%h --graph --sparse --full-history branchA 
> branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^
>
> ... and:
>
> (*2*) $ git log --format=%h --graph --sparse --full-history branchA 
> branchB ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^
>
> This should produce desired graph history with only commit sha1`s shown, 
> no need to grep anything out.
>
> We already know the commits branches A and B point to from your previous 
> examples, so missing these should not be a problem -- unless your history 
> changed further, in which case you could write these to the right of 
> corresponding commits by hand (paying attention not to break the graph 
> layout - in case you`re not sure, better just leave it as it is).
>
> 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.

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Hi Chris,

On Tuesday, August 8, 2017 at 4:02:43 AM UTC+2, Chris Murphy wrote:
>
> Oh man, sorry, I totally screwed up when editing the output to exclude 
> tags, making the graph totally wrong since some lines were missing. Sorry 
> about that.
>
> I've fixed that issue (Sorry, I still have to edit out tags. I'm 
> using grep -o ".*[0-9a-f]\{10\}\|.* $", and open to any better suggestions)
>
>
> Here's command 1
> git log --tags=1 --format=%h\%d --graph --sparse --full-history branchA 
> branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^ | grep -o 
> ".*[0-9a-f]\{10\}\|.* $"
> https://gist.github.com/cmurphycode/84d7efae872a4f23dfb01efdad4836e7
>
> command 2
> git log --format=%h\%d --graph --sparse --full-history branchA branchB 
> ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^ | grep -o ".*[0-9a-f]\{10\}\|.* 
> $"
> https://gist.github.com/cmurphycode/0498a5530e68382d32f1833dfd669311
>

That looks much better, but I`m not sure if it can/should still be trusted, 
either, as "--tags=1" parameter you added can cause (pretty much?) all 
history to still be included, missing the point of last ^{commit}^ 
restriction, and might be grepping could still omit some lines...?

If you would prefer not showing tags, maybe the easiest approach would be 
omitting "decorations" placeholder "%d" inside "--format" parameter 
altogether:

(*1*) $ git log --format=%h --graph --sparse --full-history branchA branchB 
^03dd551f031f48e8702f9154b23f53af8cc4799b^

... and:

(*2*) $ git log --format=%h --graph --sparse --full-history branchA branchB 
^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^

This should produce desired graph history with only commit sha1`s shown, no 
need to grep anything out.

We already know the commits branches A and B point to from your previous 
examples, so missing these should not be a problem -- unless your history 
changed further, in which case you could write these to the right of 
corresponding commits by hand (paying attention not to break the graph 
layout - in case you`re not sure, better just leave it as it is).

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.

[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

Oh man, sorry, I totally screwed up when editing the output to exclude 
tags, making the graph totally wrong since some lines were missing. Sorry 
about that.

I've fixed that issue (Sorry, I still have to edit out tags. I'm using grep 
-o ".*[0-9a-f]\{10\}\|.* $", and open to any better suggestions)


Here's command 1
git log --tags=1 --format=%h\%d --graph --sparse --full-history branchA 
branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^ | grep -o 
".*[0-9a-f]\{10\}\|.* $"
https://gist.github.com/cmurphycode/84d7efae872a4f23dfb01efdad4836e7

command 2
git log --format=%h\%d --graph --sparse --full-history branchA branchB 
^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^ | grep -o ".*[0-9a-f]\{10\}\|.* 
$"
https://gist.github.com/cmurphycode/0498a5530e68382d32f1833dfd669311



Thanks very much!






On Monday, August 7, 2017 at 7:51:28 PM UTC-4, Igor Djordjevic wrote:
>
> Hi Chris,
>
> On Monday, August 7, 2017 at 9:48:26 PM UTC+2, Chris Murphy wrote:
>>
>> The gist I uploaded was created via
>> git log --format=%h\ %d --graph branchA branchB
>>
>
> Is this the _exact_ command you used, or you had some additional grepping 
> in there as well (as with your other gists)? Only grepping would seem to 
> explain the crippled graph(s), unless I`m missing something else.
>
> Could you try with these commands instead (without any grepping of the 
> result):
>
> (*1*) $ git log --format=%h\%d --graph --sparse --full-history branchA 
> branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^
>
> ... and:
>
> (*2*) $ git log --format=%h\%d --graph --sparse --full-history branchA 
> branchB ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^
>
>
> That should hopefully provide some more info on the state of your 
> repository history, both starting from your branch tips and ending (1) at 
> the parent commit of the merge-base you discovered, or (2) at the parent of 
> the commit you were originally interested in.
>
> 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.

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Hi Chris,

On Monday, August 7, 2017 at 9:48:26 PM UTC+2, Chris Murphy wrote:
>
> The gist I uploaded was created via
> git log --format=%h\ %d --graph branchA branchB
>

Is this the _exact_ command you used, or you had some additional grepping 
in there as well (as with your other gists)? Only grepping would seem to 
explain the crippled graph(s), unless I`m missing something else.

Could you try with these commands instead (without any grepping of the 
result):

(*1*) $ git log --format=%h\%d --graph --sparse --full-history branchA 
branchB ^03dd551f031f48e8702f9154b23f53af8cc4799b^

... and:

(*2*) $ git log --format=%h\%d --graph --sparse --full-history branchA 
branchB ^9ba8f06829b2d2170f23254ed3fe8f3727fe56dc^


That should hopefully provide some more info on the state of your 
repository history, both starting from your branch tips and ending (1) at 
the parent commit of the merge-base you discovered, or (2) at the parent of 
the commit you were originally interested in.

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.

[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

I think some of the things you found strange in that first gist are 
explainable by the command i ran --- maybe this will be better:

git log --format=%h\ %d --graph branchB | grep -o ".*[0-9a-f]\{10\} "

https://gist.github.com/cmurphycode/c1233902e529e7a8e5a5e0586dd29bac

especially in combination with the second gist I posted a minute ago:
git log branchA...branchB --graph  | grep "commit \|Date: \|Merge: "

https://gist.github.com/cmurphycode/c1e581c04a89b7f5a679ad6e1ae1d7d6

Thanks,
Chris



On Monday, August 7, 2017 at 3:48:26 PM UTC-4, Chris Murphy wrote:
>
> I agree :)
>
> Our workflow is such that:
> -  branch B should've been created from a point in time of branch A. I 
> can't guarantee that that's what happened (as I understand it, it's hard to 
> determine whether this is the case, as git doesn't care about this). 
> -  branch A should've been occasionally merged into branch B (to keep 
> branch B refreshed). This did happen a few times.
>
> The gist I uploaded was created via
> git log --format=%h\ %d --graph branchA branchB
>
> which I had run yesterday on the suggestion of the git IRC channel.
>
> I would need to do some more reading about the graph line format to 
> understand what you are saying. But, in the meantime, maybe the output of 
> this command will help: git log branchA...branchB --graph  | grep "commit 
> \|Date: \|Merge: "
>
> https://gist.github.com/cmurphycode/c1e581c04a89b7f5a679ad6e1ae1d7d6
>
>
>
>
>
> On Monday, August 7, 2017 at 3:32:14 PM UTC-4, Igor Djordjevic wrote:
>>
>> Hi Chris,
>>
>> On Monday, August 7, 2017 at 5:28:15 PM UTC+2, Chris Murphy wrote:
>>>
>>> The history of the repo is quite tangled with many merges, but I 
>>> uploaded it here (with sensitive info removed, sorry, it's a repo for my 
>>> work) in case it helps:
>>> https://gist.github.com/cmurphycode/a75d7c4616a93be2bb4fd1096d162714
>>>
>>
>> I find the history graph you`ve posted having a bit unusual layout, being 
>> kind of hard to follow where did it branch, and where merges happened. How 
>> did you produce it?
>>
>> For example, for a branching point here:
>>
>> * | 0abcc19bd9
>> * | e783d2f321
>> * 5daf5fedee
>> * c8cc2f3523
>>
>>
>> I would expect something like this instead:
>>
>> * | 0abcc19bd9
>> * | e783d2f321
>>
>> |/
>> * 5daf5fedee
>> * c8cc2f3523
>>
>>
>>
>> And here, I guess there are some merges... or not?
>>
>> | | * ecdbbfcc3c
>> | | *   951eb3147d
>> | | * \   f2afcaf2c3
>> | | * \ \   0d94457c16
>> | * | | | | 955537dbef
>> | * | | | |   e59453329b
>> * | | | | | 03dd551f03
>>
>>
>>
>> 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.

[git-users] Re: git log "double dot" showing a false positive?

[Chris Murphy]

I agree :)

Our workflow is such that:
-  branch B should've been created from a point in time of branch A. I 
can't guarantee that that's what happened (as I understand it, it's hard to 
determine whether this is the case, as git doesn't care about this). 
-  branch A should've been occasionally merged into branch B (to keep 
branch B refreshed). This did happen a few times.

The gist I uploaded was created via
git log --format=%h\ %d --graph branchA branchB

which I had run yesterday on the suggestion of the git IRC channel.

I would need to do some more reading about the graph line format to 
understand what you are saying. But, in the meantime, maybe the output of 
this command will help: git log branchA...branchB --graph  | grep "commit 
\|Date: \|Merge: "

https://gist.github.com/cmurphycode/c1e581c04a89b7f5a679ad6e1ae1d7d6





On Monday, August 7, 2017 at 3:32:14 PM UTC-4, Igor Djordjevic wrote:
>
> Hi Chris,
>
> On Monday, August 7, 2017 at 5:28:15 PM UTC+2, Chris Murphy wrote:
>>
>> The history of the repo is quite tangled with many merges, but I uploaded 
>> it here (with sensitive info removed, sorry, it's a repo for my work) in 
>> case it helps:
>> https://gist.github.com/cmurphycode/a75d7c4616a93be2bb4fd1096d162714
>>
>
> I find the history graph you`ve posted having a bit unusual layout, being 
> kind of hard to follow where did it branch, and where merges happened. How 
> did you produce it?
>
> For example, for a branching point here:
>
> * | 0abcc19bd9
> * | e783d2f321
> * 5daf5fedee
> * c8cc2f3523
>
>
> I would expect something like this instead:
>
> * | 0abcc19bd9
> * | e783d2f321
>
> |/
> * 5daf5fedee
> * c8cc2f3523
>
>
>
> And here, I guess there are some merges... or not?
>
> | | * ecdbbfcc3c
> | | *   951eb3147d
> | | * \   f2afcaf2c3
> | | * \ \   0d94457c16
> | * | | | | 955537dbef
> | * | | | |   e59453329b
> * | | | | | 03dd551f03
>
>
>
> 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.

[git-users] Re: git log "double dot" showing a false positive?

[Igor Djordjevic]

Hi Chris,

On Monday, August 7, 2017 at 5:28:15 PM UTC+2, Chris Murphy wrote:
>
> The history of the repo is quite tangled with many merges, but I uploaded 
> it here (with sensitive info removed, sorry, it's a repo for my work) in 
> case it helps:
> https://gist.github.com/cmurphycode/a75d7c4616a93be2bb4fd1096d162714
>

I find the history graph you`ve posted having a bit unusual layout, being 
kind of hard to follow where did it branch, and where merges happened. How 
did you produce it?

For example, for a branching point here:

* | 0abcc19bd9
* | e783d2f321
* 5daf5fedee
* c8cc2f3523


I would expect something like this instead:

* | 0abcc19bd9
* | e783d2f321

|/
* 5daf5fedee
* c8cc2f3523



And here, I guess there are some merges... or not?

| | * ecdbbfcc3c
| | *   951eb3147d
| | * \   f2afcaf2c3
| | * \ \   0d94457c16
| * | | | | 955537dbef
| * | | | |   e59453329b
* | | | | | 03dd551f03



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.