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

Re: [PATCH 3/3] transport: allow summary-width to be computed dynamically

From
Jeff King <peff@peff.net>
Date
Oct 22, 2016, 04:10 UTC
Message-ID
<20161022041021.cpe7pooacl6tywqd@sigill.intra.peff.net>
In-Reply-To
<20161021223927.26364-4-gitster@pobox.com>
On Fri, Oct 21, 2016 at 03:39:27PM -0700, Junio C Hamano wrote:
Show 6 quoted lines
> Now we have identified three callchains that have a set of refs that
> they want to show their <old, new> object names in an aligned output,
> we can replace their reference to the constant TRANSPORT_SUMMARY_WIDTH
> with a helper function call to transport_summary_width() that takes
> the set of ref as a parameter.  This step does not yet iterate over
> the refs and compute, which is left as an exercise to the readers.
The final step could be something like this:
diff --git a/transport.c b/transport.c
index 4dac713063..c1eaa4a 100644
--- a/transport.c
+++ b/transport.c
@@ -443,7 +443,21 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count,
 
 int transport_summary_width(const struct ref *refs)
 {
-	return (2 * FALLBACK_DEFAULT_ABBREV + 3);
+	int max_abbrev;
+
+	/*
+	 * Computing the complete set of abbreviated sha1s is expensive just to
+	 * find their lengths, but we can at least find our real dynamic
+	 * minimum by picking an arbitrary sha1.
+	 */
+	if (refs)
+		max_abbrev = strlen(find_unique_abbrev(refs->old_oid.hash,
+						       DEFAULT_ABBREV));
+	else
+		max_abbrev = FALLBACK_DEFAULT_ABBREV;
+
+	/* 2 abbreviated sha1s, plus "..." in between */
+	return (2 * max_abbrev + 3);
 }
 
 void transport_print_push_status(const char *dest, struct ref *refs,


which produces reasonable results for me. But if we really wanted the
true value, I think we'd want to compute and store the abbreviated
sha1s, and then the refactoring done by your series probably isn't the
right direction.

I think we'd instead want to replace "struct strbuf *display" passed
down to update_local_ref() with something more like:

  struct ref_status_table {
	struct ref_status_item {
		char old_hash[GIT_SHA1_HEX + 1];
		char new_hash[GIT_SHA1_HEX + 1];
		char *remote_ref;
		char *local_ref;
		char *summary;
		char code;
	} *items;
	size_t alloc, nr;
  };

and then format_display() would just add to the list (including calling
find_unique_abbrev()), and then at the end we'd call a function to show
them all.

That would also get rid of prepare_format_display(), as we could easily
walk over the prepared list before printing any of them (as opposed to
what that function does now, which is to walk over the ref map; that
requires that it know which refs are going to be printed).

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 11 of 14 in “[BUG] fetch output is ugly in 'next'”
  1. Jeff KingOct 21, 2016
  2. Duy NguyenOct 21, 2016
  3. Duy NguyenOct 21, 2016
  4. Junio C HamanoOct 21, 2016
  5. Jeff KingOct 21, 2016
  6. Junio C HamanoOct 21, 2016
  7. 0/3 fetch output is ugly in 'next'Junio C Hamano, Oct 21, 2016
  8. 2/3 fetch: pass summary_width down the callchainJunio C Hamano, Oct 21, 2016
  9. 1/3 transport: pass summary_width down the callchainJunio C Hamano, Oct 21, 2016
  10. 3/3 transport: allow summary-width to be computed dynamicallyJunio C Hamano, Oct 21, 2016
  11. Jeff KingOct 22, 2016
  12. Junio C HamanoOct 22, 2016
  13. Jeff KingOct 22, 2016
  14. Junio C HamanoOct 22, 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.