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

> On Friday 18 May 2007, Michael S. Tsirkin wrote:
> > > 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.

> > 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.
> 
> > 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.