On 1/18/21 7:39 PM, Derrick Stolee wrote:
> On 1/18/2021 7:54 PM, Antonio Russo wrote:
>> On 1/18/21 1:58 PM, Derrick Stolee wrote:
>>> On 1/18/2021 2:31 PM, Aiyee Bee wrote:
>>>> Hi Antonio and Derrick!
>>>>
>>>>> I think what you really want is --full-history --simplify-merges [1]. This
>>>>> will show the merges that "fork" the history into parallel tracks where
>>>>> at least two of them contain interesting commits.
>>>>
>>>> It doesn't look like the implementation of --simplify-merges helps much
>>>> here. That makes its decision on basis of the parents of the commit, which is
>>>> simple to do as it's information attached freely to each commit. I think the
>>>> problem here would be figuring out, given any commit, how many of its children
>>>> are "relevant" commits.
>>>
>>> You should definitely give this a try instead of assuming things about the
>>> implementation. The algorithm uses a lot of "simplifying" that makes it look
>>> like the decision is a local one. However, I assure you that is not the case.
>>
>> As a side note, would this list be willing to look at patches that remove
>> the need to use revs->limited? Adding new features would be much easier if
>> we could restrict git to use streaming algorithms for these simplifications.
>
> I would _love_ to see patches that remove that bit (without modifying
> the behavior).
>
> Fair warning: I definitely spent a few weeks attempting to do any amount
> of reducing the depth one needs to walk in order to compute the
> --simplify-merges history, but a sufficiently-complicated branch history
> makes it nearly impossible to gain a benefit.
The goal I had in mind was just to remove the alternate code path, making
new features easier to write (i.e., you don't have to do them twice).
>>> Please assemble a test case that demonstrates the behavior you want and how
>>> that is different from what is present in --simplify-merges.
>>
>> I can't figure out how to get the behavior from --simplify-merges, which is
>> described as
>>
>> Additional option to --full-history to remove some needless
>> merges from the resulting history, as there are no selected
>> commits contributing to this merge.
>>
>> It seems that the desired behavior is to include commits which are parents to
>> multiple branches. Here is an example:
>
> Thank you for these examples. They clearly show that I misread your
> ask, because you're not looking for "merge commits" but instead you
> are looking to show the "merge bases" as history is walking.
>
> Sorry for misinterpreting your request, then doubling down on it.
No problem! (Just to be clear, the is a request of shane.880088.supw,
not me.)
>
>> test_commit() {
>> echo >> file
>> git add file
>> git commit "$@"
>> }
>>
>> git init
>> test_commit -m a
>> test_commit -m b
>> test_commit -m c
>> git checkout -b fork
>> test_commit -m y
>> test_commit -m z
>> git switch master
>> test_commit -m d
>> test_commit -m e
>> test_commit -m f
>>
>> git log --graph --oneline master fork
>>
>> * 08029fd f
>> * 55b09fe e
>> * 83b7801 d
>> | * efc204e z
>> | * 316219e y
>> |/
>> * 3594039 c
>> * 4321987 b
>> * bd44220 a
>>
>> git log --graph --oneline --full-history --simplify-merges master fork
>>
>> * 08029fd f
>> * 55b09fe e
>> * 83b7801 d
>> | * efc204e z
>> | * 316219e y
>> |/
>> * 3594039 c
>> * 4321987 b
>> * bd44220 a
>>
>> git log --graph --oneline --simplify-by-decoration --full-history --simplify-merges master fork
>>
>> * 08029fd f
>> | * efc204e z
>> |/
>> * bd44220 a
>>
>> git log --graph --oneline --full-history --simplify-merges master fork
>>
>> * 08029fd f
>> * 55b09fe e
>> * 83b7801 d
>> | * efc204e z
>> | * 316219e y
>> |/
>> * 3594039 c
>> * 4321987 b
>> * bd44220 a
>>
>> git --version
>> git version 2.30.0
>>
>> I can't seem to get commit c, the crucial fork, to show up with simplifications with this mechanism.
>> Am I missing something here?
>
> In your example, you are not specifying a path. In this case, you are
> really looking for "git merge-base master fork". You could also use
> "git log --boundary master...fork" to show everything up to and
> including 'c'.
>
> Now, if you specify a pathspec, then 'git merge-base' isn't going to
> help. That becomes a technically interesting problem.
>
> The biggest reason that "git log" doesn't show this commit 'c' easily
> is because...it's not really that important. When that commit was
> created, it didn't "know" that it would be a common base of two
> diverging branches. By surfacing the commit, we are very unlikely to
> present the user with information that is helpful.
I think shane.880088.supw's point was that it's importance is, exactly as
you point out, not locally computable, only arising because it is a merge
base.
[snip (but an interesting read)]
>
> Thanks,
> -Stolee
>
Antonio
