Re: CIFS fixes

From: Steve French <smfrench@gmail.com>
Date: May 11, 2008, 17:48 UTC
Message-ID: <524f69650805111048v6033c2eajb7cc22b9c4fa6bc0@mail.gmail.com>
In-Reply-To: <alpine.LFD.1.10.0805110957530.3330@woody.linux-foundation.org>

The rebase did fix up the obsolete commits ... but I still get the "warn: No branch of ..." message. I think that will go away when there is another newer commit in your tree. It doesn't seem to be a problem - the list of commits is right. See below:

[sfrench@hera cifs-2.6]$ git fetch
remote: Counting objects: 1627, done.
remote: Compressing objects: 100% (178/178), done.
remote: Total 1097 (delta 927), reused 1087 (delta 919)
Receiving objects: 100% (1097/1097), 167.04 KiB, done.
Resolving deltas: 100% (927/927), completed with 285 local objects.
From /pub/scm/linux/kernel/git/torvalds/linux-2.6
   28a4acb..5bb7ff7  master     -> origin/master
[sfrench@hera cifs-2.6]$ git rebase origin
First, rewinding head to replay your work on top of it...
HEAD is now at 5bb7ff7 Merge master.kernel.org:/home/rmk/linux-2.6-arm
Applying [CIFS] cifs_find_tcp_session cleanup
Applying [CIFS]  add local struct inode pointer to cifs_setattr
Applying [CIFS] when not using unix extensions, check for and set
ATTR_READONLY on create and mkdir
Applying [CIFS] don't allow demultiplex thread to exit until
kthread_stop is called
[sfrench@hera cifs-2.6]$ git-request-pull origin
git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git
warn: No branch of
git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git is
at:
warn:   e691b9d: [CIFS] don't allow demultiplex thread to exit until
kthread_stop is called
warn: Are you sure you pushed HEAD there?

The following changes since commit 5bb7ff795fffc9418e3039cac77b42adcaae1a57:
  Linus Torvalds (1):
        Merge master.kernel.org:/home/rmk/linux-2.6-arm

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git
..BRANCH.NOT.VERIFIED..

Cyrill Gorcunov (1):
      [CIFS] cifs_find_tcp_session cleanup

Jeff Layton (2):
      [CIFS]  add local struct inode pointer to cifs_setattr
      [CIFS] when not using unix extensions, check for and set
ATTR_READONLY on create and mkdir

Steve French (1):
      [CIFS] don't allow demultiplex thread to exit until kthread_stop is called

 fs/cifs/cifspdu.h |    1 +
 fs/cifs/cifssmb.c |   16 ++++-------
 fs/cifs/connect.c |   79 +++++++++++++++++++++++++++--------------------------
 fs/cifs/dir.c     |   16 +++++++++--
 fs/cifs/inode.c   |   35 ++++++++++++++---------
 5 files changed, 81 insertions(+), 66 deletions(-)

On Sun, May 11, 2008 at 12:04 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 45 quoted lines

>
>
>  On Sun, 11 May 2008, Steve French wrote:
>  >
>
> > That is not what I meant.   I meant that since May 6th I only did one
>  > - and those messages still showed up.  So I just ran a git-rebase
>  > origin which removed them
>
>  You're doing something wrong then, and your rebased result is suspect.
>
>  Have you done a "git fetch" to fetch what is in my current tree? Because
>  if you haven't, then you're generating the "this is the new state" without
>  actually taking into account that the old state was already pulled!
>
>  And that *old* state contains those four merges that I got from your
>  previous pull request!
>
>  So now you likely rebased the commits that I already merged (again,
>  because you *think* they are just local to your branch, because you
>  haven't updated your origin reference point), and they are now duplicates
>  of something I already have (but with different commit ID's, since your
>  rebase has moved them around in the history).
>
>  So now, if I were to pull again, I'd just get the same commits all over
>  again, just as duplicates (plus any new ones, of course). Git would
>  probably merge it all fine - unless your new ones were to the same area as
>  the old ons, in which case it might be unhappy about the fact that both
>  branches changed things in the same area - but the history would be crud.
>
>  In other words: you *must*not* rebase stuff that you have already
>  publicized. That just creates problems.
>
>  The good news is that you can most likely fix it all up by just doing
>
>         git fetch
>         git rebase origin
>
>  because now the *new* rebase will try to rebase it all over again, but now
>  it will see that I already merged the old ones, so the rebase will just
>  skip those commits, and you should have only the *real* new ones pending
>  again.
>
>                 Linus
>

-- 
Thanks,

Steve