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

From: Duy Nguyen <pclouds@gmail.com>
Date: Apr 8, 2013, 10:29 UTC
Message-ID: <CACsJy8CAW1h4rAOK_2+EAFEL28CKeqf4vqROsLByjZaMU3D-ow@mail.gmail.com>
In-Reply-To: <CALkWK0nz878Xh9BFSCrtBGT=g3fys3uBy7QQs9cdWaFtoS8Rsg@mail.gmail.com>

On Mon, Apr 8, 2013 at 7:08 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 7 quoted lines

> 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 ;-)

Show 5 quoted lines

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

Show 8 quoted lines

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