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-armare 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 cleanupJeff 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 mkdirSteve 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
Steve French