Tor Arne Vestbø <torarnv@xxxxxxxxx> wrote: > > But, with that said, I think of EGit as a standalone Eclipse-plugin > implementation of the git porcelain -- not just a wrapper around the > command line porcelain. Yes, exactly. JGit is about keeping on-disk and on-network binary compatability with git-core. But we don't necessarily need to keep UI or behavior always the same within the porcelain that uses that library, aka EGit. > To me that means that EGit should focus just as much on integrating with > Eclipse properly as it does on keeping command line porcelain > interoperability. Yup, I agree completely. I think Robin would too. > The core.excludesfile is one such case, and I think my proposal is a > good compromise. IMHO, we should honor ignores in EGit as: per-directory .gitignore per-repostiory GIT_DIR/info/exclude per-repository core.excludesfile (yes, really, it can be per repository, which overrides ~/.gitconfig setting of same) Eclipse global team ignore patterns Skipping the core.excludesfile in favor of only the Eclipse global team ignores feels wrong to me, as we may be missing something the user has configured. FWIW, I think core.excludesfile is a lot less frequently used then .gitignore and GIT_DIR/info/exclude. If there is a core.excludesfile, the user is a pretty advanced user and they really want that behavior to be honored by Git poreclain. EGit should honor it. But likewise with the global team ignores. I think most people set up ignores in their VCS, so they are distributed to everyone on the project automatically. But if you do twiddle your own workspace settings, we should honor them. -- Shawn. -- 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
