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.

.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.  Now, you might argue that they should be
part of the tree object, but I will disagree because they don't
operate on concrete entries in the tree but rather extended globs that
match worktree paths.  .gitmodules, on the other hand, specifies
fundamental repository composition: it should be a special object in
the tree precisely because it changes the fundamental meaning of one
concrete tree entry.  It has nothing to do with path treatment in the
worktree, and hence has nothing to do with .gitattributes

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

> If you end up convincing others that your tools are worth working
> on and those tools pleasantly take care of the same workflows that
> submodules do, then I imagine people will be happy to migrate.

Yes, I'm planning a strict superset of the current submodule system
features.  After some thought, I've decided not to have any feature
regressions in my first version for merge (although that means a lot
of work for me).

> Speaking only for myself, I actually prefer the submodule UI, despite
> not being thrilled with the
> single-.gitmodules-file-at-the-root-of-the-worktree feature.  So I
> will not be working on your proposed redesign, unless it evolves
> enough to be as pleasant a UI as (the long proposed UI of) submodules.

I'm very interested in building a pleasant UI.  I've always been a
person who cares deeply about UI: this is evidenced by my recent
remote.pushdefault patch, and my pull.autostash WIP.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to