| Re: [jgit-dev] Change 59345 in jgit/jgit[master]: bug 342372 - Patch adding end-of-line-conversion using .gita... |
Thanks for the comments. Let me just justify one topic you mentioned: >>> I am not sure whether we really need .git* file listeners. Up to know we had no performance problems checking config/gitattribute files once in the beginning of at git command. When doing a checkout of a branch, the .gitattributes are not yet in the working tree (but in dir cache). So the file detection would be used there in order to incrementally and correctly checkout text files / binaries. Question 1: Does Arthurs patch collect the .gitattributes from the dir-cache BEFORE the files are actually checked out? If yes, then you're right, I will not need a file detection in the tree since then the .gitattributes are already collected. Question 2: I strongly assume that Arthurs patch will be the base. Ok? So I can base the next proposal on it. Yours Ivan -----Ursprüngliche Nachricht----- Von: Christian Halstrick [mailto:christian.halstrick@xxxxxxxxx] Gesendet: Dienstag, 10. November 2015 13:18 An: Ivan Motsch Cc: jgit-dev@xxxxxxxxxxx Betreff: Re: [jgit-dev] Change 59345 in jgit/jgit[master]: bug 342372 - Patch adding end-of-line-conversion using .gita... On Tue, Nov 10, 2015 at 11:24 AM, Ivan Motsch <Ivan.Motsch@xxxxxxxxxxxxxxxx> wrote: > Thanks for the comments. > At the end of the day everyone shares the same goal. We want to have the end-of-line issue fixed in a way that people can use it as "commonly" expected. > Maybe not all of the 100% of the features but the basic ones. I completely agree. EOL handling needs to be fixed and I am glad you spent so much time fixing. I would love to get this functionality in. > Please also give me a statement about any help is (still) needed. Yes, of course. We definitely need your help and expertise. > I am not eager to submit code when others in your team can do the same thing themselves (maybe even better). That would be bad of course. But I don't think that's the case here. There is much good work here which should be integrated and which nobody works on. Nobody else is currently working on fixing EOL handling. It's only the generic way how we collect attributes inside a Treewalk which is something where we have open changes. I am personally also involved because I need a fixed attributes calculation for LFS support (https://git.eclipse.org/r/#/c/59319/). In this area I still think we should for performance reasons scan the working tree only once and collect and compute attributes during that single walk. I am not sure whether we really need .git* file listeners. Up to know we had no performance problems checking config/gitattribute files once in the beginning of at git command. > I only got active since the end-of-line issue is a major issue that keeps people away from jgit/egit and some also from eclipse at all. > Our 200+ developers also need a change in time, so that is the reason why I propably was too fast submitting a complete change. Great to hear. If somebody has 200 developers behind him who want a certain feature then I think you'll be motivated enough and don't give up if the jgit community want strange things like splitting up huge commits etc. :-) > Then smaller iterations could be: > 0) accept Arthurs change > The I sumbit on top of that > 1) a proposal for the AttributesHierarchy on top of that in the > TreeIterator, including macro handling and junit tests > 2) a proposal for the StreamConversionFactory, not yet cross-wired, > just the factory and the junit tests for it > 3) a proposal for .gitattributes, .gitignore file change listener in > the repo including the life-update in the AttributesHierarchy Until here it is just added supporting functionality, no change in behavior yet. > 4) (finally) a proposal for wiring the StreamConversionFactory into the checkout process, this will add the eol-fix to jgit. > > A realistic plan. Maybe another order makes sense, please advise. Sounds great. I would say: don't open too many topic's in advance. If for example 3) is not needed to get the feature you want then I would skip it or open it later when the rest is in.I'll work on step 0)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature