Re: [RFC/PATCH 0/7] Rework git core for native submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]