Re: Renaming files with git not all that bad?

[tomas]

On Thu, Dec 09, 2021 at 02:18:21PM -0800, Stefan Kangas wrote:
> <tomas@tuxteam.de> writes:
> 
> > On Thu, Dec 09, 2021 at 03:55:34PM +0100, Stefan Kangas wrote:
> >> Yuri Khan <yuri.v.khan@gmail.com> writes:
> >>
> >> > There is also a trick to split a file into multiple parts where each
> >> > part retains its history.
> >>
> >> Thanks, I didn't know about this but will see if I can make it work
> >> for the splitting up of image-dired.el.
> >
> > Based on [1], I once did:

[crude git-split code]

> Cool!
> 
> I'm not sure about this method, as it seems safer to use a named branch
> instead of referring to some SHA1 directly.  Maybe that won't make any
> difference to git though?

It would at least leave some evidence behind, should things go boom :)
OTOH you'd want to garbage collect those spurious branches
> 
> It's been over a decade since I last looked into how git stores data in
> any detail, but IIRC a branch name is just a pointer to some SHA1 hash
> recorded in a text file.

More or less. The "active" branches (typically the HEAD, but also the
remote branches) are represented by files whithin
.git/refs/heads/<branch name> (where subdirs are made when the branch
name contains slashes, that's why you can't create a branch "foo"
whenever you already have a branch "foo/bar" and vice-versa, just think
UNIXy ;-) This file just contains the Merkle-tree-ish hash of the source
tree, and is updated on commits (thus it "grows"). Tags just stay "in
place". In real life, the inactive refs tend to live in "packed-refs", I
believe.

Cheers
-- 
t

signature.asc
Description: PGP signature