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:

quoted

On Thu, Feb 02, 2017 at 05:11:32AM +0000, Amit Kumar wrote:

quoted

On Wed, Feb 01, 2017 at 01:54:16PM +0000, Amit Kumar wrote:

quoted

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?

quoted

quoted

quoted

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.

quoted

quoted

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