lkml.org 
[lkml]   [2016]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [GIT PULL] Ceph updates for 4.6-rc1
From
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

\
 
 \ /
  Last update: 2016-03-27 00:01    [W:0.039 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site