Duy Nguyen wrote:
> 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 ;-)
Why is it a burden? I would argue that the tooling support is not yet
there, but git check-ignore is a step in the right direction. What
alternate design would you propose, just out of curiosity?
> 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 should've said "largely, only affects the current worktree".
> 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)
Yes, there is some common ground. But:
1. The inspiration for fixing fundamental design problems comes from
my redesign. For instance, I would've never discovered the git add
bug if I'd not attempted to git add (as opposed to the unnatural
abstraction that git submodule add presents).
2. I think it is absolutely imperative that we do the redesign now,
before we've descended too far into the madness that the current
design is. I think I'm capable of doing the redesign now, with some
help and support from the list. My attitude doesn't align with the
"I'm feeling lazy; why don't we postpone it?" argument. Let's finish
what I started now: I'm more than willing to dedicate the next few
months full-time towards finishing this and getting it merged.
--
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