Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1365024

Re: [GIT PULL] Ceph updates for 4.6-rc1

Show all headers | View raw

On Sat, Mar 26, 2016 at 11:00 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sat, Mar 26, 2016 at 2:46 PM, Ilya Dryomov <idryomov@gmail.com> wrote:
>>
>> FWIW, it matches -next content-wise.  SHAs don't match because of an
>> extra Signed-off-by in an unrelated commit, outside of fs/ceph.
>
> That's how git works. After you rebase, SHA's will *never* match,
> because you changed the history (dates, parenthood etc).
>
> The whole "it matches content-wise" is immaterial. You rebased and now
> I can see that it's not what was in next. It's really that simple.
>
> Just as an example of what rebasing does: it means that when I look at
> "ok, what is in next but not in my tree yet" to see what might be
> pending, the rebased commits don't cancel out, because they are
> different commits.
>
> Yes, yes, I've been lax about this. I have been ranting against people
> rebasing for years, but in the end I've usually let it slide.
>
> But dammit, when things come in at the very end of the merge window,
> which makes me grumpy to begin with, AND it is then re-based, at that
> point I'm not inclined to let things slide any more.
>
> At that point you guys are actively working to piss me off, and that
> means that I'm not in the least in the mood of pulling your work.
>
> Why *was* the pull request sent at the very end of the merge window
> anyway?  Was the code not ready?

A couple of commits were taken out and new integration snapshot was
made, based on Al's merge.  After it went through the usual test cycle,
I didn't think things through and it ended up being the pull request.

>
> So let me say again: keep your *own* tree in good shape.
>
> That's actually the only really valid reason for rebasing: if your
> *own* tree has something horribly bad going on, like majorly messed up
> commit messages, or history that is completely broken and will cause
> problems for people who want to bisect bugs, or things like that. Then
> "git rebase" is a perfectly good thing to fix bad things that are in
> _your_ tree.
>
> But no, git rebase is not a "let's react to random things that
> happened in other peoples trees". At that point you're worrying about
> entirely the wrong thing.

I get your argument.

Thanks,

                Ilya

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[GIT PULL] Ceph updates for 4.6-rc1 Sage Weil <sage@redhat.com> - 2016-03-26 02:40 +0100
  Re: [GIT PULL] Ceph updates for 4.6-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-26 19:40 +0100
    Re: [GIT PULL] Ceph updates for 4.6-rc1 Ilya Dryomov <idryomov@gmail.com> - 2016-03-26 22:20 +0100
      Re: [GIT PULL] Ceph updates for 4.6-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-26 22:40 +0100
        Re: [GIT PULL] Ceph updates for 4.6-rc1 Ilya Dryomov <idryomov@gmail.com> - 2016-03-26 22:50 +0100
          Re: [GIT PULL] Ceph updates for 4.6-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-26 23:10 +0100
            Re: [GIT PULL] Ceph updates for 4.6-rc1 Ilya Dryomov <idryomov@gmail.com> - 2016-03-26 23:40 +0100
            Re: [GIT PULL] Ceph updates for 4.6-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-27 00:00 +0100

csiph-web