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

[PATCH] unneeded processing in forward_patches() ??

From
CLChuck Lever <cel@citi.umich.edu>
Date
Dec 2, 2005, 00:11 UTC
Message-ID
<20051202001141.9140.23252.stgit@dexter.citi.umich.edu>

i was wondering why "stg push" takes so long to decide not to use fast-forward.

it turns out that when forward_patches() has not been able to fast- forward any patches, it still does a git.switch() and rewrites the unapplied file even though nothing has changed. on a big working directory, this 'no-op' can take a while.

following is a simple patch that addresses the problem. does this appear to be a reasonable optimization (in terms of correctness)?

        -- Chuck Lever
--
corporate:    <cel at netapp dot com>
personal:     <chucklever at bigfoot dot com>
Next: Chuck Lever
Message 1 of 2 in “unneeded processing in forward_patches() ??”
  1. unneeded processing in forward_patches() ??Chuck Lever, Dec 2, 2005
  2. Fast-forwarding does a git.switch() even when it forwarded no patchesChuck Lever, Dec 2, 2005

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.