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

Re: [PATCH 2/4] revision traversal: retire BOUNDARY_SHOW

From
Junio C Hamano <junkio@cox.net>
Date
Mar 6, 2007, 02:17 UTC
Message-ID
<7v4pozuncr.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.63.0703060253140.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 23 quoted lines
> On Mon, 5 Mar 2007, Junio C Hamano wrote:
>
>> This removes the flag internally used by revision traversal to
>> decide which commits are indeed boundaries and renames it to
>> CHILD_SHOWN.  builtin-bundle uses the symbol for its
>> verification, but I think the logic it uses it is wrong.  The
>> flag is still useful but it is local to the git-bundle, so it is
>> renamed to PREREQ_MARK.
>
> The idea was to bail out of revision walking when that prerequisite was 
> found, _even_ if it happened to be uninteresting.
>
> Just marking the parents uninteresting unless they are prerequisites would 
> be better, probably.
>
>>  
>>  	i = req_nr;
>>  	while (i && (commit = get_revision(&revs)))
>> -		if (commit->object.flags & BOUNDARY_SHOW)
>> +		if (commit->object.flags & PREREQ_MARK)
>>  			i--;
>
> The above-mentioned idea, then would be: instead of just i--; do

I explicitly wanted to avoid that. If the generated bundle had prereqs that are not independent of each other, doing that would hide some prereqs.

> This should help performance, as not all reachable commits are traversed 
> any more.
You prevented that with "while (i &&" part already, didn't you?
> Wasn't --skip meant for something like gitweb, where you just want to skip 
> the first <n> commits from the list, but do not want to change the list 
> otherwise?
Yes, but does the patch change that?
Show 11 quoted lines
>
>> @@ -1305,6 +1309,9 @@ struct commit *get_revision(struct rev_info *revs)
>>  	case -1:
>>  		break;
>>  	case 0:
>> +		/* Although we grabbed it, it is not shown. */
>> +		if (c)
>> +			c->object.flags &= ~SHOWN;
>>  		c = NULL;
>
> Is this really relevant in practice?
Absolutely.  But I have further updates on this series.
Previous: Johannes SchindelinNext: Junio C Hamano
Message 18 of 26 in “[BUG] git-rev-list: --topo-order --boundary and --max-count”
  1. Santi BéjarMar 5, 2007
  2. Junio C HamanoMar 5, 2007
  3. Junio C HamanoMar 5, 2007
  4. Linus TorvaldsMar 5, 2007
  5. revision walker: Fix --boundary when limitedJohannes Schindelin, Mar 5, 2007
  6. Johannes SchindelinMar 5, 2007
  7. Linus TorvaldsMar 5, 2007
  8. Linus TorvaldsMar 5, 2007
  9. Junio C HamanoMar 5, 2007
  10. Johannes SchindelinMar 6, 2007
  11. Junio C HamanoMar 6, 2007
  12. Johannes SchindelinMar 6, 2007
  13. Junio C HamanoMar 6, 2007
  14. Johannes SchindelinMar 5, 2007
  15. Junio C HamanoMar 6, 2007
  16. 2/4 revision traversal: retire BOUNDARY_SHOWJunio C Hamano, Mar 6, 2007
  17. Johannes SchindelinMar 6, 2007
  18. Junio C HamanoMar 6, 2007
  19. SHOWN means shownJunio C Hamano, Mar 6, 2007
  20. Johannes SchindelinMar 6, 2007
  21. Junio C HamanoMar 6, 2007
  22. Johannes SchindelinMar 6, 2007
  23. 3/4 git-bundle: various fixupsJunio C Hamano, Mar 6, 2007
  24. Johannes SchindelinMar 6, 2007
  25. 4/4 git-bundle: --list-prereqsJunio C Hamano, Mar 6, 2007
  26. Junio C HamanoMar 5, 2007

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.