Re: Patch (apply) vs. Pull

On Thu, 23 Jun 2005, Linus Torvalds wrote:

> Right, that would mean that we don't control the hash generation at both 
> points, and would make it fundamentally harder. But since the whole point 
> is that we should be able to generate the ID _without_ it actually being 
> stored away anywhere, this hash approach should work fine.

("We" in this case being the developer checking whether the patch went in,
not the maintainer)

We'll need to see if the performance is okay this way, both in terms of
time spent searching for the patch you're checking on and in terms of
recognizing the patch as being the same. No point in designing anything
more complex until we determine if we can't just recognize it already.

> > I think that the whole-chain case is sufficiently common to make special
> > and extra smooth; developers will be making their history forwards every
> > day, and only cherry-picking on occasion.
> 
> I'm not convinced. I think a _lot_ of people would want to do re-ordering 
> of patches, combining them, and cherry-picking them if they just had a 
> good way to do that.

Oh, I think they'd want to do that. I just don't think they'd want to do
it as often as they want to update their tree for changes in mainline,
just because no one developer will do more work than the rest of the
developers combined. And it's worthwhile, because you need to use
diff/patch for the complex cases, and can use diff3 for the simple case,
and you need diff3 if you want the system to treat "everything in patch 5
is already in the new base" as success rather than conflict.

(This is, incidentally, the case that drives me crazy about arch: if I
make a change in one working directory, copy that change into another
working directory, commit it from one of those directories, and update in
the other, I get a reject, and I then have to figure out if the changes 
were actually the same or if one of them has further modifications.)

	-Daniel
*This .sig left intentionally blank*

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html