From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC] to rebase or not to rebase on linux-next
Date: Tue, 27 Oct 2009 19:07:56 UTC
Message-ID: <fa.80vr9v+YcqUFLnCxQqsJ7OZwUr4@ifi.uio.no>

On Sat, 24 Oct 2009, Stefan Richter wrote:

> Per linux-next submission rules, all /essential/ credits are already
> present.  But I agree that it is worth rewinding a for-next branch in
> order to add (non-essential) credits later.

I'd actually personally prefer that people do _not_ generally add
"credits" later.

Quite frankly, if something was committed without having been ack'ed by
some person, then later - when that person sees it on a commit list, for
example - it's worthless adding somebodys late ack.

Same largely goes for 'tested-by' lines.

And 'signed-off-by' are actively _wrong_ to add later. If it didn't come
with a sign-off in the first place, it shouldn't have been committed.

One reason I say this is that I really think it's wrong to even give
credit to some late-comer that pipes in after the patch has already made
it into somebody's tree. If they didn't comment on it while it was passed
around as a patch on mailing lists, what's the point? By the time it's in
somebody elses published tree, any "ack" is worthless, and that person
should simply _not_ get credit for being late to the party.

So I think that there are many good reasons to rebase patches in your own
tree, but I do _not_ think that "adding late acks" is one such reason. If
you've published your tree to others, then it's done. Don't lie about
getting an ack that you didn't get before you made that patch public.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [RFC] to rebase or not to rebase on linux-next
Date: Tue, 27 Oct 2009 19:44:09 UTC
Message-ID: <fa.1XI5rpuAatT7QnST3Wdg+xD+QF0@ifi.uio.no>

On Tue, 27 Oct 2009, Steven Rostedt wrote:
>
> On Tue, 2009-10-27 at 12:06 -0700, Linus Torvalds wrote:
> >  Don't lie about
> > getting an ack that you didn't get before you made that patch public.
>
> But how do you get your ack without making it public?

There's a difference between exposing your git tree to the public, and
showing your patches to others.

A public git tree is _not_ the place to ask for comments for patches. If
you haven't gotten Ack's, you have two choices:

 - that commit should not show up in a tree that is marked for -next,
   because it's still waiting for feedback and people to test it. It may
   be in a _private_ git tree of course, but it's not "ready" yet.

 - you are going to commit it regardless of acks or not, and you don't
   care, and you shouldn't lie about it later.

Those are the two obvious choices. Adding ack's later, after it has
already been exported and tested in -next is kind of pointless, isn't it?
It's basically lying about how the patch came to be.

If you want Ack's from people, then send that patch around by email.

NOTE! If you know the people you want acks from are git users, then the
email can certainly be something like "look at so-and-so branch of my git
tree <here>". You can certainly use private git branches as a way to talk
to other developers about code you're not fully happy with yet, with the
clear understanding that you want acks and comments on it.

Put another way: there's a big conceptual difference between "public git
tree" and "private git branch that may well be available to others and
is meant for development". In git itself, Junio has the 'pu' branch that
is clearly marked as being rebased etc.

				Linus