cherry-pick to master
jeremyhu at freedesktop.org
Tue Oct 13 13:34:52 PDT 2009
On Oct 13, 2009, at 13:16, Keith Packard wrote:
> Excerpts from Jeremy Huddleston's message of Tue Oct 13 12:59:19
> -0700 2009:
>> Hi Keith,
>> Can you please pull these two commits into master:
>> I'm still waiting on Peter's "best git practices" documentation
>> making my apple feature tree.
> In general, I think the idea was that patches be merged to master,
> tested there, and then pulled back to the version branches. Is there
> some reason you're doing this kind of development and testing on the
> 1.7 branch instead of from master? Are you finding master too unstable
> to be used for this kind of development?
No, I actually tested these on master and am living on master...
but since I can't commit to master by policy (merge to master from
feature branches), and I don't have an apple feature branch tracking
master (since I'm waiting for Peter's documentation on the best
practices for that), the only place I could put them in git for you
was on my 1.7 branch... but I assure you I'm actually using them on
> As we work on refining our source management policies, it would be
> useful to get feedback on how things are working for developers and
> maintainers. Ideally, I'd like to see you maintaining a branch or
> repository off of the master X server branch and be I'd merging rather
> than cherry-picking patches to master.
Yeah, that's what I want as well, but I'm waiting for Peter's "best
practices" wiki page to figure out the best way to do that since our
1.6 feature branch is not that clean.
With my feature branch off of 1.6 (xorg-server-1.6-apple), we ran into
a bit of a headache as server-1.6-branch diverged a bit... it is non-
trivial to provide incremental patches from 1.6.5 to 1.6.5-apple1 at
this point because we've been doing "svn merge origin/server-1.6-
branch" into xorg-server-1.6-apple along the way. Rebasing rather
than merging would make it easier to generate incremental patches, but
that is "bad" for people tracking your branch since they can't fast-
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3333 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091013/36e05dae/attachment.bin
More information about the xorg-devel