[GIT PULL] please pull file locking changes for 3.15

[GIT PULL] please pull file locking changes for 3.15

[Jeff Layton]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

The following changes since commit 29723adee11804b548903ddb1db666cf4a60f60e:

  locks: make locks_mandatory_area check for file-private locks (2014-03-31 08:24:43 -0400)

are available in the git repository at:

  git://git.samba.org/jlayton/linux.git locks-3.15

for you to fetch changes up to 29723adee11804b548903ddb1db666cf4a60f60e:

  locks: make locks_mandatory_area check for file-private locks (2014-03-31 08:24:43 -0400)

----------------------------------------------------------------
(from the branch description for locks-3.15 local branch)

file locking patches for 3.15

----------------------------------------------------------------
Highlights:

- maintainership change for fs/locks.c. Willy's not interested in
  maintaining it these days, and is OK with Bruce and I taking it.
- fix for open vs. setlease race that Al ID'ed
- cleanup and consolidation of file locking code
- eliminate unneeded BUG() call
- merge of file-private lock implementation

-- 
Jeff Layton <jlayton@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] please pull file locking changes for 3.15

[Linus Torvalds]

On Mon, Mar 31, 2014 at 6:31 AM, Jeff Layton <jlayton@redhat.com> wrote:
> The following changes since commit 29723adee11804b548903ddb1db666cf4a60f60e:
>
>   locks: make locks_mandatory_area check for file-private locks (2014-03-31 08:24:43 -0400)
>
> are available in the git repository at:
>
>   git://git.samba.org/jlayton/linux.git locks-3.15

Please please please use the proper scripts (or improve on whatever
local script you use) that show the diffstat ("git diff -M --stat
--summary") and shortlog for the pull request too.

I want to know roughly what I'm pulling *before* I pull it, and while
I can do a two-stage thing where I first fetch-and-inspect it, that's
annoying. Your human-readable "Highlights" thing is good, and I want
that too (I put commentary like that into the merge commit itself),
but I do want that diffstat/shortlog in addition to the human-readable
summary.

Because having the diffstat in the pull request email not only gets me
a heasd-up abotu what to expect, it also confirms that I'm on the same
page as you are. It acts as a sanity-check for me when I can compare
the diffstat you *claim* I should get with the diffstat I actually get
after merging. So I really want to get that diffstat and shortlog as a
sanity check.

I also would prefer signed tags. It's not a must since it's not like
git.samba.org is some random public site (I do _require_ them for pull
requests from github etc), but it's definitely a "good thing" to have.

Anyway, I'm going through my pile of filesystem pull requests, and
I've pulled this into my tree. I'm just going through allmodconfig
builds etc before pushing my merge out, so assuming that all works
fine you don't need to resend this one.  But for future pull requests,
please do try to fix the above up.

             Linus

Re: [GIT PULL] please pull file locking changes for 3.15

[Jeff Layton]

On Fri, 4 Apr 2014 14:28:16 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Mar 31, 2014 at 6:31 AM, Jeff Layton <jlayton@redhat.com> wrote:
> > The following changes since commit 29723adee11804b548903ddb1db666cf4a60f60e:
> >
> >   locks: make locks_mandatory_area check for file-private locks (2014-03-31 08:24:43 -0400)
> >
> > are available in the git repository at:
> >
> >   git://git.samba.org/jlayton/linux.git locks-3.15
> 
> Please please please use the proper scripts (or improve on whatever
> local script you use) that show the diffstat ("git diff -M --stat
> --summary") and shortlog for the pull request too.
> 
> I want to know roughly what I'm pulling *before* I pull it, and while
> I can do a two-stage thing where I first fetch-and-inspect it, that's
> annoying. Your human-readable "Highlights" thing is good, and I want
> that too (I put commentary like that into the merge commit itself),
> but I do want that diffstat/shortlog in addition to the human-readable
> summary.
> 
> Because having the diffstat in the pull request email not only gets me
> a heasd-up abotu what to expect, it also confirms that I'm on the same
> page as you are. It acts as a sanity-check for me when I can compare
> the diffstat you *claim* I should get with the diffstat I actually get
> after merging. So I really want to get that diffstat and shortlog as a
> sanity check.
> 
> I also would prefer signed tags. It's not a must since it's not like
> git.samba.org is some random public site (I do _require_ them for pull
> requests from github etc), but it's definitely a "good thing" to have.
> 
> Anyway, I'm going through my pile of filesystem pull requests, and
> I've pulled this into my tree. I'm just going through allmodconfig
> builds etc before pushing my merge out, so assuming that all works
> fine you don't need to resend this one.  But for future pull requests,
> please do try to fix the above up.
> 
>              Linus

Thanks for the feedback and for pulling this in anyway. I'll make sure
to do all of that on subsequent pull requests.

Cheers!
-- 
Jeff Layton <jlayton@redhat.com>

Re: [GIT PULL] please pull file locking changes for 3.15

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Hi Jeff,

On Fri, 4 Apr 2014 20:56:24 -0400 Jeff Layton <jlayton@redhat.com> wrote:
>
> Thanks for the feedback and for pulling this in anyway. I'll make sure
> to do all of that on subsequent pull requests.

Also, please don't rebase what you have in linux-next before sending it to
Linus (without good reason).  Especially if you then leave the linux-next
included branch as it was - since that may cause conflicts in my tree
(and so I notice the rebase).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] please pull file locking changes for 3.15

[Jeff Layton]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Mon, 7 Apr 2014 11:37:06 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jeff,
> 
> On Fri, 4 Apr 2014 20:56:24 -0400 Jeff Layton <jlayton@redhat.com> wrote:
> >
> > Thanks for the feedback and for pulling this in anyway. I'll make sure
> > to do all of that on subsequent pull requests.
> 
> Also, please don't rebase what you have in linux-next before sending it to
> Linus (without good reason).  Especially if you then leave the linux-next
> included branch as it was - since that may cause conflicts in my tree
> (and so I notice the rebase).
> 

I don't think I did that though, did I? Both the branches I had in this
case were based on 3.13-rc1.

Now that Linus has pulled in the changes, am I OK to rebase the
branches (or do a pull)?

-- 
Jeff Layton <jlayton@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] please pull file locking changes for 3.15

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

Hi Jeff,

On Mon, 7 Apr 2014 07:11:30 -0400 Jeff Layton <jlayton@redhat.com> wrote:
>
> On Mon, 7 Apr 2014 11:37:06 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > On Fri, 4 Apr 2014 20:56:24 -0400 Jeff Layton <jlayton@redhat.com> wrote:
> > >
> > > Thanks for the feedback and for pulling this in anyway. I'll make sure
> > > to do all of that on subsequent pull requests.
> > 
> > Also, please don't rebase what you have in linux-next before sending it to
> > Linus (without good reason).  Especially if you then leave the linux-next
> > included branch as it was - since that may cause conflicts in my tree
> > (and so I notice the rebase).
> 
> I don't think I did that though, did I? Both the branches I had in this
> case were based on 3.13-rc1.

OK, so the base stayed the same, but you recommitted all the same patches
(I didn't check to see if the commit messages changed) which due to some
other change caused conflicts in linux-next today :-( Not really a
biggie, but generally, you really shouldn't rewrite your commits just
before sending them to Linus.

> Now that Linus has pulled in the changes, am I OK to rebase the
> branches (or do a pull)?

At this point, you should just reset your next included branch to be in
Linus' tree beyond where Linus merged your tree, then it will be
effectively empty (unless you then add some more patches on top - but at
this point those should only be fixes).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] please pull file locking changes for 3.15

[Jeff Layton]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

On Mon, 7 Apr 2014 22:27:02 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jeff,
> 
> On Mon, 7 Apr 2014 07:11:30 -0400 Jeff Layton <jlayton@redhat.com> wrote:
> >
> > On Mon, 7 Apr 2014 11:37:06 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > On Fri, 4 Apr 2014 20:56:24 -0400 Jeff Layton <jlayton@redhat.com> wrote:
> > > >
> > > > Thanks for the feedback and for pulling this in anyway. I'll make sure
> > > > to do all of that on subsequent pull requests.
> > > 
> > > Also, please don't rebase what you have in linux-next before sending it to
> > > Linus (without good reason).  Especially if you then leave the linux-next
> > > included branch as it was - since that may cause conflicts in my tree
> > > (and so I notice the rebase).
> > 
> > I don't think I did that though, did I? Both the branches I had in this
> > case were based on 3.13-rc1.
> 
> OK, so the base stayed the same, but you recommitted all the same patches
> (I didn't check to see if the commit messages changed) which due to some
> other change caused conflicts in linux-next today :-( Not really a
> biggie, but generally, you really shouldn't rewrite your commits just
> before sending them to Linus.
> 
> > Now that Linus has pulled in the changes, am I OK to rebase the
> > branches (or do a pull)?
> 
> At this point, you should just reset your next included branch to be in
> Linus' tree beyond where Linus merged your tree, then it will be
> effectively empty (unless you then add some more patches on top - but at
> this point those should only be fixes).
> 

Ahh ok, I guess I *did* alter a commit message in my locks-3.15 branch
and didn't propagate that to my linux-next branch. That probably threw
off the commit IDs. The patches themselves should have been identical
though. Sorry about that!

In any case, I've gone ahead and reset my branch as you recommend and
linux-next branch and will be more careful about that in the future.

-- 
Jeff Layton <jlayton@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]