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

Re: sane, stable renames; when a commit should commit twice

From
David Symonds <dsymonds@gmail.com>
Date
Dec 23, 2007, 02:26 UTC
Message-ID
<ee77f5c20712221826r5945a6d0x8a84eae98c85b25b@mail.gmail.com>
In-Reply-To
<20071223020310.GA22450@freedbms.net>
On Dec 23, 2007 1:03 PM, Zenaan Harkness <zen@freedbms.net> wrote:
Show 13 quoted lines
> When should a commit, commit twice?
>
> When one or more git mv file renames/ moves are involved.
>
> In such a case the commit ought to be split into two. Perhaps move the
> files in the first commit, then make the changes needed to support the
> move in the build chain (including changes in the moved files) in the
> second commit.
>
> This keeps a clean record of the move, making the move, and the
> associated changes (as two commits) a clean cherry.
>
> Does this make sense?

Not particularly. Git commits are not (conceptually) changes or deltas; they are snapshots of a tree of files at a particular time. How does the tree state at your above first commit make any sense? It is broken. Git's rename/move detection is smart enough to notice that a rename + small-changes is close enough to a rename, so just trust that to get it right.

Dave.
Previous: Zenaan HarknessNext: Jakub Narebski
Message 2 of 4 in “sane, stable renames; when a commit should commit twice”
  1. Zenaan HarknessDec 23, 2007
  2. David SymondsDec 23, 2007
  3. Jakub NarebskiDec 23, 2007
  4. Junio C HamanoDec 23, 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.