On Thu, Feb 02, 2017 at 09:08:15AM +0000, Amit Kumar wrote: > On Thu, Feb 02, 2017 at 08:10:56AM +0100, Greg KH wrote: > > On Thu, Feb 02, 2017 at 05:11:32AM +0000, Amit Kumar wrote: > > > On Wed, Feb 01, 2017 at 01:54:16PM +0000, Amit Kumar wrote: > > > > Hi, > > > > As I know quilt is used by maintainers. But kernel source code is > > > > maintained in git repo. So I want to know how git and quilt work > > > > together. > > > I have found a video in which Mr. GregKH has explained how he applies > > > patches to the stable tree. But this video is short and needs several view to > > > understand what is going on. > > > > Do you have questions about it? > I use git-send-email and msmtp combination. > I also use mutt and msmtp combination. > Could you provide me quilt mail and git-send-email configuration? You already have git-send-email working, what do you need changed there? As for quilt mail, what did you try that did not work? > > > > In mutt I have seen that a mail sent by Mr. GregKH has quilt mail as user > > > > agent and git-send-email as x-mailer. It means he is using > > > > git-send-email as a backend for quilt mail. > > > > > > > > Last but not least, I think if a developer starts using quilt to > > > > maintain his diferent versions of a patch, it will ease a maintainer > > > > job. > > > I'm in the process of making developers available upto minute code under > > > change.So duplicate patch problem can be solved. > > > > What duplicate patch problem? > Sometimes when a developer sends his patch. He receives a reply this > patch has been already submitted by another developer. > > I think the reason is that when a developer starts working on a patch, > he has not bleeding edge copy of maintainers tree. There is a long > review cycle of patch which is required for a large project as Linux. Define "long" :) Of course there will be conflicts, that's just the nature of working on a distributed project where no one can "lock" any portion of the tree. Just redo your patch and move on. Nothing complex there. > > > So I request kernel experts their words. > > > > What question do you have? > So, I have a solution. As patches are collected on patchwork.kernel.org. > While patches are under review, it can be tracked by a bot and show lines > of code,on a web page, which will be affected on the basis of currently > submitted patch. So, developers don't touch those lines of code. Nope. That would prevent others from doing work, which is never a good idea. How often have you really hit this issue? As someone who reviews more patches than anyone else in the kernel, I see it happen only very infrequently (i.e. less than 1% of the time.) > I also propose in-queue branch(patches in queue to be applied) for maintainers, > which will help a maintainer to know which patches has been selected by > other maintainer. I think there will be less conflicts. Where are the conflicts you see happening? Again, is this really a big problem that you are trying to solve here? I haven't heard any other maintainer complain about it, you do know about linux-next, right? > If you help me answering few questions as I develop this system, I will > be grateful to you. Don't work to solve a non-existant problem :) thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
