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

Re: [PATCH 02/11] Introduce a performance test for git-rebase

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 12, 2012, 19:45 UTC
Message-ID
<7v399dsiw2.fsf@alter.siamese.dyndns.org>
In-Reply-To
<87ipi9yaws.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> writes:
> However, it's pretty obvious that 'rebase -f' is slow compared to
> 'rebase -m'.  So slow in fact that the user would be better off running
> an *interactive* rebase.

The mention of "-f" got me off track, but does "-m" avoid creating new commits when it does not have to? A side effect "-f" has is to replay _all_ the commits, if I recall correctly.

> This comes from the i18n support added in adc3b2b27..a9f578685, and from
> 43c2325 (am: use get_author_ident_from_commit instead of mailinfo when
> rebasing, 2010-06-16).
Show 5 quoted lines
> Now I'm not really keen on hacking on git-am until it gets back its
> performance, as for most uses it's probably still fast enough.  But I
> think one important question is: can we get rid of the
> git-format-patch|git-am mode of git-rebase, which has historically been
> a source of pain (see, e.g., the aforementioned 43c2325)?

In the longer term, the right way forward is to try doing less in the patch mode in rebase. For example, the command could make the list of commits to be replayed exactly the same way as it does for flattening cherry-pick rebase, and instead of running "am", run "format-patch --stdout | apply --3way --whitespace=fix --index" and commit the result using "commit -C". That way it can depend on "commit -C" and does not have to worry about stupid things like 43c2325.

Previous: Thomas RastNext: Thomas Rast
Message 5 of 20 in “perf improvements past v1.7.10”
  1. 00/11 perf improvements past v1.7.10Thomas Rast, Mar 12, 2012
  2. 01/11 perf/aggregate: load Git.pm from the build treeThomas Rast, Mar 12, 2012
  3. 02/11 Introduce a performance test for git-rebaseThomas Rast, Mar 12, 2012
  4. Thomas RastMar 12, 2012
  5. Junio C HamanoMar 12, 2012
  6. Thomas RastMar 12, 2012
  7. Junio C HamanoMar 12, 2012
  8. 03/11 Introduce a performance test for git-blameThomas Rast, Mar 12, 2012
  9. 04/11 perf: display average instead of minimum timeThomas Rast, Mar 12, 2012
  10. 05/11 perf: suppress aggregation also in 'run'Thomas Rast, Mar 12, 2012
  11. 06/11 perf: dereference to a commit when buildingThomas Rast, Mar 12, 2012
  12. 07/11 perf: convert realtime to seconds when collecting runsThomas Rast, Mar 12, 2012
  13. 08/11 perf/aggregate: optionally include a t-test scoreThomas Rast, Mar 12, 2012
  14. 09/11 perf/run: allow skipping some revisionsThomas Rast, Mar 12, 2012
  15. Nguyen Thai Ngoc DuyMar 12, 2012
  16. Thomas RastMar 12, 2012
  17. Jakub NarebskiMar 12, 2012
  18. Thomas RastMar 12, 2012
  19. 10/11 perf: implement a test-selection featureThomas Rast, Mar 12, 2012
  20. 11/11 perf: add a bisection toolThomas Rast, Mar 12, 2012

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.