Re: Patch (apply) vs. Pull

From: Darrin Thompson <darrint@progeny.com>
Date: Jun 22, 2005, 16:23 UTC
Message-ID: <1119457403.4128.18.camel@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org>

On Tue, 2005-06-21 at 15:09 -0700, Linus Torvalds wrote:

Show 5 quoted lines

> However, as you point out, it's not necessarily the best kind of merge for
> the "individual developer" standpoint. Most individual developers don't
> necessarily want to merge their work, rather they want to "bring it
> forward" to the current tip. And I think git could help with that too.
>

That's a good way to put it.

Show 8 quoted lines

> and here the "git-cherry-pick" thing is just a script that basically takes
> an old commit ID, and tries to re-apply it as a patch (with author data
> and commit messages, of course) on top of the current head. It would 
> basically be nothing more than a "git-diff-tree $1" followed by tryign to 
> figure out whether it had already been applied or whether it can be 
> applied now.
> 
> What do you think?

Here are two desirable things the might be tough to reconcile:

- The merging mechanism might benefit from knowing that your commit was
really originally my commit _if_ my history is relevant to the merge and
present.

- The rest of the world does _not_ want to have to keep my commits on
hand just to follow the mainline.

I imagine if those could be reconciled you'd hit a sweet spot.

A mechanism where those two were true might also provide better hooks for knowing other things. For instance, which of these particular commits of mine are not in the mainline tree?

Perhaps your mainline commit might refer to my humble commit as some kind of sibling. You don't need to have it to follow the mainline, but the data is there if it helps anybody.

-- Darrin