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

Re: What's cooking in git.git (topics)

From
Junio C Hamano <junkio@cox.net>
Date
Mar 13, 2007, 19:43 UTC
Message-ID
<7vhcsphqtk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<7vps7dle8j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Here are the topics that have been cooking.
Show 12 quoted lines
> * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits
>  + git-fetch.sh:append_fetch_head() no longer has a remote_nick
>    argument
>  + git-fetch: Split fetch and merge logic
>
> I have a soft spot to anything that claims to be a clean-up, but
> I suspect that the shell loop this series introduces may defeat
> the git-fetch--tool optimization.  Also I think having to base
> the patch on this made Paolo's "dot is special token to mean
> 'git pull' merges from a local branch" needlessly complex (but I
> haven't tried rewriting it myself without these two).  Although
> I merged these to 'next', I am considering to revert them.

I tried the "NULL fetch between 1000-refs repositories" test, which prompted the git-fetch--tool work that was done on jc/fetch topic in 'next', with the following versions:

 (1) 1.5.0 (without any git-fetch--tool optimization)
 (2) master (ditto)
 (3) master with jc/fetch (but not sb/fetch topic)
 (4) next ((3) plus sb/fetch and others)

The test scripts are at the end of this message. Both (1) and (2) take 3 minutes 7 seconds wallclock time. (3) improves it down to 15 seconds. (4) makes the operation spend 24 seconds (the times are all on my primary machine x86-64 with 1GB, hot cache and average of three runs each).

So the "Split fetch and merge" series hurts the performance quite a bit. If it had enough "code clean-up" merit to warrant this, I would say it probably is a cost we should bear, but I personally do not see it.

Paolo recently worked on top of next to base the fake '.' remote patch. This wants to allow:

	[branch "foo"]
        	remote = .
                merge = refs/heads/master

with an implicit (meaning, you do not have to have this in your configuration):

	[remote "."]
        	url = .
                fetch = refs/*
so that you can say:
	$ git checkout foo
        $ git pull
to merge from the local 'master' branch.

I haven't reimplemented Paolo's patch on top of (3) above for comparison, but I have a feeling that it would not have been helped by the alleged clean-up value of "Split fetch and merge" patch (iow, I do not think it would be the case that the code got clearer to understand thanks to the clean-up).

What Paolo's patch needs to do is to bypass the actual fetch and generate the following line in .git/FETCH_HEAD:

	sha1-of-our-master <TAB> <TAB> branch 'master' of .

I even suspect that "Split fetch and merge", by introducing FETCH_FETCHED and making FETCH_HEAD generated from it, made Paolo's patch more difficult to do and the end result less efficient.

So unless there is a convincing counterexample otherwise, I'd like to revert the "Split fetch and merge" series.

-- >8 -- setting up test repositories -- >8 -- #!/bin/sh

rm -fr origin clone
mkdir origin
cd origin
git init
: >hello
git add hello
git commit -a -m 'initial'
i=0
while test $i -lt 500
do
	git tag t$i
	git branch b$i
	i=$(($i+1))
done
: >bye
git add bye
git commit -a -m 'second'
while test $i -lt 1000
do
	git tag t$i
	git branch b$i
	i=$(($i+1))
done

cd .. -- >8 -- NULL fetch test -- >8 -- #!/bin/sh

cd clone echo '* fetching' time git fetch origin

Previous: Julian PhillipsNext: Santi Béjar
Message 18 of 28 in “What's cooking in git.git (topics)”
  1. Junio C HamanoFeb 20, 2007
  2. Eric WongFeb 20, 2007
  3. Junio C HamanoFeb 20, 2007
  4. Alexander LitvinovFeb 20, 2007
  5. Junio C HamanoFeb 23, 2007
  6. Johannes SchindelinFeb 23, 2007
  7. Junio C HamanoFeb 23, 2007
  8. Junio C HamanoMar 4, 2007
  9. Johannes SchindelinMar 4, 2007
  10. Linus TorvaldsMar 4, 2007
  11. Junio C HamanoMar 4, 2007
  12. Marco CostalbaMar 4, 2007
  13. Junio C HamanoMar 13, 2007
  14. Matthias LederhoferMar 13, 2007
  15. Junio C HamanoMar 13, 2007
  16. Matthias LederhoferMar 13, 2007
  17. Julian PhillipsMar 13, 2007
  18. Junio C HamanoMar 13, 2007
  19. Santi BéjarMar 13, 2007
  20. Junio C HamanoMar 14, 2007
  21. Santi BéjarMar 14, 2007
  22. Junio C HamanoMar 25, 2007
  23. Johannes SchindelinMar 25, 2007
  24. Junio C HamanoMar 25, 2007
  25. Johannes SchindelinMar 25, 2007
  26. Florian WeimerMar 26, 2007
  27. Junio C HamanoMar 26, 2007
  28. Document git-log --first-parentJunio C Hamano, Mar 27, 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.