Re: [3/4] What's not in 1.5.2 (new topics)

On Fri, May 18, 2007 at 05:51:14PM CEST, Josef Weidendorfer wrote:

On Friday 18 May 2007, Michael S. Tsirkin wrote:

quoted

quoted

Subproject identifiers appear in versioned .gitmodule files, so
they are fixed with the history of the project. You can not change
the names without rewriting history.

Actually, I think this means that moving the
directory where the subproject resides will involve
editing .gitmodule. I sthat true?

Yes.
This was a design decision by Linus. The alternative way
would have been a separate gitlink object, which includes the
commit SHA1 of the subproject _and_ a subproject identifier,
thus increasing the number of objects.

The current way is far simpler, but you have to edit the .gitmodule
file when moving subprojects around. The argument by Linus was
that this inconvenience should be acceptable as moving subprojects
around should only happen very few times in the lifetime of a
project, and involves heavy rearranging either way, such that editing
.gitmodules info is the smaller issue.

Furthermore, git mv can trivially take care of this anyway...

quoted

This would be annoying. 

Can't a project name be a git attribute for the gitlink object?

Of course. The name can be put into the .gitattributes file instead of
a separate .gitmodules file.

quoted

This way I can move the object and it keeps the project name.

No.
Git attributes do not magically move around when you move files or
directories. You always have to change the .gitattribute file too, if
you want to move attributes with files. Of course, this is not needed
if you use glob patterns in .gitattributes which also fits for moved
files. 

Actually, git-mv might take care of this too? ;-) (Would it be
considered a Bad Thing, or should I whip up a patch?)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett