Re: DEVEL: Help with feature implementation

On 1/18/21 7:39 PM, Derrick Stolee wrote:

On 1/18/2021 7:54 PM, Antonio Russo wrote:

quoted

On 1/18/21 1:58 PM, Derrick Stolee wrote:

quoted

On 1/18/2021 2:31 PM, Aiyee Bee wrote:

quoted

Hi Antonio and Derrick!

quoted

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

quoted

quoted

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

quoted

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