git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: history damage in linux.git

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 21, 2016, 19:27 UTC
Message-ID
<xmqqmvomsqwx.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CA+55aFwOtyW7zLHdJND=FGBWKBfhQV95RPVRG5gcoRUrtGCrAQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But this patch is small and simple, and has some excuses for its
> behavior. What do people think?

I like it that you call it "excuse" not "rationale", as I couldn't form a logical connection between your "4 (2) letters" and "10000 (100)" at all ;-)

Modulo the usual style issues (e.g. we frown upon patches in attachement that makes it harder to quote and comment), I think this is a strict improvement and is a good measure until somebody does a full "topologically closest" solution.

Show 49 quoted lines
>                  Linus
>
>  builtin/name-rev.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> index 092e03c3cc9b..0354c8d222e1 100644
> --- a/builtin/name-rev.c
> +++ b/builtin/name-rev.c
> @@ -16,9 +16,6 @@ typedef struct rev_name {
>  
>  static long cutoff = LONG_MAX;
>  
> -/* How many generations are maximally preferred over _one_ merge traversal? */
> -#define MERGE_TRAVERSAL_WEIGHT 65535
> -
>  static void name_rev(struct commit *commit,
>  		const char *tip_name, int generation, int distance,
>  		int deref)
> @@ -55,19 +52,26 @@ copy_data:
>  			parents;
>  			parents = parents->next, parent_number++) {
>  		if (parent_number > 1) {
> +			int weight;
>  			size_t len;
>  			char *new_name;
>  
>  			strip_suffix(tip_name, "^0", &len);
> -			if (generation > 0)
> +
> +			// The extra merge traversal "weight" depends
> +			// on how complex the resulting name is.
> +			if (generation > 0) {
> +				weight = 10000;
>  				new_name = xstrfmt("%.*s~%d^%d", (int)len, tip_name,
>  						   generation, parent_number);
> -			else
> +			} else {
> +				weight = 100;
>  				new_name = xstrfmt("%.*s^%d", (int)len, tip_name,
>  						   parent_number);
> +			}
>  
>  			name_rev(parents->item, new_name, 0,
> -				distance + MERGE_TRAVERSAL_WEIGHT, 0);
> +				distance + weight, 0);
>  		} else {
>  			name_rev(parents->item, tip_name, generation + 1,
>  				distance + 1, 0);
Previous: Jeff KingNext: Linus Torvalds
Message 23 of 24 in “history damage in linux.git”
  1. Olaf HeringApr 21, 2016
  2. Matthieu MoyApr 21, 2016
  3. Olaf HeringApr 21, 2016
  4. Matthieu MoyApr 21, 2016
  5. John KeepingApr 21, 2016
  6. Olaf HeringApr 21, 2016
  7. Matthieu MoyApr 21, 2016
  8. Andreas SchwabApr 21, 2016
  9. Linus TorvaldsApr 21, 2016
  10. Junio C HamanoApr 21, 2016
  11. Jeff KingApr 21, 2016
  12. Linus TorvaldsApr 21, 2016
  13. Stefan BellerApr 21, 2016
  14. Junio C HamanoApr 21, 2016
  15. Jeff KingApr 21, 2016
  16. Linus TorvaldsApr 21, 2016
  17. Johannes SchindelinApr 22, 2016
  18. Linus TorvaldsApr 21, 2016
  19. Junio C HamanoApr 21, 2016
  20. Linus TorvaldsApr 21, 2016
  21. Linus TorvaldsApr 21, 2016
  22. Jeff KingApr 21, 2016
  23. Junio C HamanoApr 21, 2016
  24. Linus TorvaldsApr 21, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.