On Wed, Apr 17, 2013 at 9:06 PM, Ramkumar Ramachandra <artagnon@xxxxxxxxx> wrote: > Duy Nguyen wrote: >> Somewhat related to the topic. Why can't .gitattributes be used for >> storing what's currently in .gitmodules? > > It can. It's just a small syntax change from "key = value" attributes > inside a toplevel [submodule <name>] section separated by newlines, to > a path marked with multiple "key=value" attributes separated by > whitespace. However, we don't want to make this change because these > submodule attributes are somewhat "different" from .gitattributes > attributes. > > Roughly speaking, the current .gitmodules design treats submodule > directories as "directories with special attributes", with two > differences: these directories have a special mode in the index, and a > commit object is created in the database to represent the "partial > state" of this submodule. That was my thinking. .gitmodules would break if a user moves the submodule manually (or even if .gitattributes is used) > If you think about it, the information > stored in the commit object is no less/ no more important than the > path-attribute mapping in .gitmodules. I was arguing for using a > special OBJ_LINK to represent the full state of the submodule, and > doing away with the attributes altogether, but not everyone agrees. Include me to those everyone. url feels like a local thing that should not stay in object database (another way of looking at it is like an email address: the primary one fixed in stone in commits with .mailmap for future substitution). Other attributes like .update, .fetchRecursiveSubmodules... definitely should not be stored in object database. I think if they are stored in the submodule's config file, then the manual move problem above will go away. And if you're dead set on storing some submodule state in object database, why not reuse tag object with some nea header lines? -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html