git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: "Contributors never merge" and preserving history

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Feb 26, 2008, 16:41 UTC
Message-ID
<alpine.LFD.1.00.0802260831220.14934@woody.linux-foundation.org>
In-Reply-To
<slrnfs8749.prc.jgoerzen@katherina.lan.complete.org>
On Tue, 26 Feb 2008, John Goerzen wrote:
Show 5 quoted lines
> 
> I do have a question about the point you make above though.  I'm not
> quite understanding what you're saying here.  Technically speaking,
> the end result of a merge where you pulled from me would be identical
> to a merge where I pulled from you.
Yes. Except for where the end result is!

That's kind of the point. If you're developing a driver, your tree is the "driver tree". But if you keep pulling from me, now it's no longer a driver tree, it's a "driver and Linus' code tree".

> Moreover, say I'm pretty far down on the seniority list, kernel-wise.  
> Do you expect subsystem maintainers to honor a request from me to pull 
> from my tree, even if they've never heard of me before, or would you 
> think they'd only want git format-patch output?

It probably depends on the submaintainer. But you're absolutely right that at least early on, most of them will want just emailed patches. And for that, the "fetch + rebase" model is the better one.

HOWEVER.
What happens with me is that I personally prefer patches from people if
 - they are "single" patches at a time (not necessarily just one, but at 
   most a couple at a time)
 - I've really never worked with you before

but if you have a real patch-series with more than (say) 4-5 patches, and I've seen patches from you before, _and_ you have a clean git tree, at that point I'd more likely actually already prefer a git pull if you can just describe your patches well enough in the email.

[ Of course, when it comes to me personally, another big requirement is 
  that I don't feel like you're going past some subsystem maintainer.
  It's not that I am a strict hierarchical person, it's that when it comes 
  to most subsystems I often don't feel competent enough to make the 
  decision, so I want things to go through submaintainers simply because 
  it's an extra layer of "filters".
  So the things I'd take through git are things that are either really 
  obvious or things I'd take anyway for other reasons. Those things are 
  seldom "patch series", but it happens.. ]

So at least judging by my own preferences, I don't think the barrier to doing a git merge is actually all that high. The *biggest* barrier may indeed be that I can happily do a "git pull", but if it doesn't look like a clean topic branch, I'd probably undo it.

			Linus
Previous: John Goerzen
Message 6 of 6 in “"Contributors never merge" and preserving history”
  1. John GoerzenFeb 25, 2008
  2. Linus TorvaldsFeb 25, 2008
  3. Asheesh LaroiaFeb 25, 2008
  4. Linus TorvaldsFeb 25, 2008
  5. John GoerzenFeb 26, 2008
  6. Linus TorvaldsFeb 26, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.