On Mon, Apr 8, 2013 at 7:08 PM, Ramkumar Ramachandra <artagnon@xxxxxxxxx> wrote:
> Jonathan Nieder wrote:
>> What do you think of .gitignore and .gitattributes? Should they be
>> somewhere other than the filesystem as well?
>
> I would argue that .gitignore and .gitattributes are done right. They
> are integrated into a very mature part of git-core very well, and
> their nature is fundamentally different from that of .gitmodules.
Probably off-topic, but I'm starting to find ".gitignore can be found
in every directory" a burden to day-to-day git operations. So imo it's
not done right entirely ;-)
> .gitignore and .gitattributes specify extended globs (see: wildmatch)
> rules to apply on the worktree, and can be in multiple places in the
> worktree. They apply strictly on the current worktree; they have
> nothing to do with the index, and have no interaction with other
> objects in the repository.
Index operations sometimes read these .git{ignore,attributes}. I
believe git-archive reads worktree's .gitattributes, so it's not
really just about worktree.
>> I don't think Jens had any obligation to work on submodules and
>> nothing else for the last five years. ;-)
>
> I know. What I'm saying is that his current approach is just filled
> with tons of unnecessary complexity, inelegance, and pain. This is
> evidenced by the fact that the current submodule system is pathetic
> after five years of work (and I don't think the developers working on
> it were particularly incompetent or lazy).
I don't follow this thread closely, but I think there's a common
ground where improvements can benefit both approaches. There are a lot
of problems for deep integration and erasing submodule's boundaries
from UI perspective. I think maybe you can work on that first, gain
experience along the way, and maintain the link-object changes
separately. Maybe someday you will manage to switch .gitmodules with
it. Or maybe I'm wrong (partly because I did not read the whole
thread)
--
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