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

Re: Handling renames.

From
Petr Baudis <pasky@suse.cz>
Date
Oct 22, 2005, 02:49 UTC
Message-ID
<20051022024946.GP30889@pasky.or.cz>
In-Reply-To
<7vbr1is3m4.fsf@assigned-by-dhcp.cox.net>

Dear diary, on Sat, Oct 22, 2005 at 04:10:59AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Show 8 quoted lines
> I think it is OK for the higher level layer (like your
> single-file-history follower) to use what you outlined with
> "edges", as either a hint/request from the user and/or a cache
> of what the expensive and unreliable thing figured out.
> 
> I however do not necessarily think adding the "edges"
> information as an optional second item on "parent " line in a
> commit is a good idea.

Well, it's obviously unflying idea when it doesn't become core part of GIT. ;-) That won't stop me with Cogito, though...

> Rather, treating the set of "edges" just
> like we treat the grafts feel more appropriate to me.  IOW,
> create .git/info/edges and keep your edge information there.

The thing is, you aren't supposed to have a lot of grafts, they are expected to be rare. OTOH, renames aren't really all that rare, and as the history goes, you'll accumulate a lot of them. Besides, it's not just a cache - in case the user manually recorded the rename, it's an important historical information, as important as e.g. the commit message. It should be also distributed with the rest of the history data, not be a per-repository thing. (Actually, this does not mix with the cache at all - that should be a separate thing, quite possibly in info/.)

But if GIT won't do this, I will have to do this in some Cogito-specific way. My preliminary plan is appending something like this to the commit message:

	---
	!%$rename foo\x20bar baz\nquux

!%$ being some arbitrary magic literal, and filter this out from cg-log and such. Also, all Cogito commits adding/removing files but not renaming any would have a '!%$norenames' line in the commit message, so that I know that I don't have to do the expensive heuristics because no rename/copy happened.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
Previous: Junio C HamanoNext: Linus Torvalds
Message 9 of 20 in “git-rev-list: add "--dense" flag”
  1. Linus TorvaldsOct 21, 2005
  2. Linus TorvaldsOct 21, 2005
  3. Linus TorvaldsOct 21, 2005
  4. Petr BaudisOct 22, 2005
  5. Handling renames.Petr Baudis, Oct 22, 2005
  6. Linus TorvaldsOct 22, 2005
  7. Petr BaudisOct 22, 2005
  8. Junio C HamanoOct 22, 2005
  9. Petr BaudisOct 22, 2005
  10. Linus TorvaldsOct 22, 2005
  11. Linus TorvaldsOct 22, 2005
  12. Petr BaudisOct 22, 2005
  13. Linus TorvaldsOct 22, 2005
  14. Junio C HamanoOct 22, 2005
  15. Linus TorvaldsOct 22, 2005
  16. Jonas FonsecaOct 25, 2005
  17. Linus TorvaldsOct 25, 2005
  18. Jonas FonsecaOct 25, 2005
  19. Linus TorvaldsOct 25, 2005
  20. Linus TorvaldsOct 25, 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.