Re: history damage in linux.git

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2016, 22:16 UTC
Message-ID: <xmqq37qesj3m.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kY9cpT7FN673P1u78XUwmqd0S4trAe5mauC1bdjrEsq9Q@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 23 quoted lines

> Combining Junios and Linus idea:
>
> * We want to have the minimal history, i.e. that tag with the fewest
> cummulative parent commits. (i.e. v3.13-rc7 is better than v3.13
> because `git log --oneline v3.13-rc7 |wc -l` (414317) is smaller tha
> `git log --oneline v3.13 |wc -l` (414530).
> The difference is 213.
>
> tags/v3.13-rc7~9^2~14^2~42 has 9 + 14 + 42 additional steps (65)
>
> tags/v3.13~5^2~4^2~2^2~1^2~42 has 5 + 4 + 2 + 1 +42 steps (54)
>
> tags/v3.13~5^2~4^2~2^2~1^2~42 has 9 less steps, but its base tag
> has a higher weight by 213.
>
> v4.6-rc1 has even more weight (588477).
>
> So I guess what I propose is to take the weight of a tag into account
> via `git log --oneline <tag> |wc -l` as that gives the tag which encloses
> least history?
>
> We also do not want to have "a lot of side traversals", so we could
> punish each additional addendum by a heuristic.

These are essentially shooting for what Linus meant "something optimal", contrasting his "improved heuristics" version, and it is good that you are thinking about these issues.

It may be a bit tricky to think the "optimum description" in terms of "how many commits are behind these tags", though. One thing that commonly happens is:

 (1) A fix X is developed on an ancient codebase, e.g. on top of
     v1.0.0 release.

 (2) X is first merged to the current 'master' and becomes part of
     the next release v2.0.0.

 (3) X is later merged to the maintenance track and included in
     v1.0.1.

There are a few questions you would want to ask "describe --contains X" and depending on the reason why you are asking the question, the desired answer may be different:

 - In which release did the fix X first appear?  (answer: v2.0.0)
 - What is the oldest release with the fix X?    (answer: v1.0.1)

I happen to be a maintainer who prefers to have a tidy containment relationships among his releases, and after the above three steps, there will be this:

 (4) Later v1.0.1 is merged back to 'master' branch and a tag v2.0.1
     on the maintenance track for v2.0.x series would contain it.

But not all projects are run that way. Often older maintenance tracks will never merge back to the current development track (i.e. fixes are only ported-back).

If the v1.0.x codebase had an unrelated problem in the code that no longer exists in v2.0.x codebase, the maintenance track may have quite a many commits that exist only there and not in 'master', and when (3) happens, the "weight", i.e. the commits behind the tag, of v1.0.1 may be greater than the weight of v2.0.0 in such a project.

In other words, an algorithm that uses "how many commits are behind the tag" as one of the deciding factor to name X would choose between v1.0.1 and v2.0.0 depending on what other things that have nothing to do with X happend on these parallel development tracks, which may not be desirable.