On 05/04/2011 11:11 PM, Gary V. Vaughan wrote: > Howdy Bruce, > > On 5 May 2011, at 03:22, Bruce Korb <[email protected]> wrote: >> Not being a GIT guru, I had previously done "git merge" to >> synchronize topic/libposix with master. Seemed straight >> forward and obvious to me. However, "rebase" is a better >> spelling for the proper process of resynchronization. > > I'm also very far from being a git guru - but I'm pretty sure that rebasing > a public branch is a bad idea, especially for any poor souls who have a > working copy in the existing libposix branch.
Rebasing a public branch is only acceptable if you make it equally public that you are doing the rebase. Otherwise, you are better off doing a merge rather than a rebase. For master, I don't like rebases, but for other branches, I think a rebase is okay if it is well-documented (with git.git, for example, the master branch only moves forwards, pu branch is documented as always being rebased on a daily basis, and the next branch is occasionally rebased along with a public announcement - generally each time an x.y release is cut). The question then comes on how to incorporate the branch back into master. We can temporarily relax the no-merge rule to allow a merge commit, if that is what is necessary (Jim's done it in the past; witness how the coreutils-8.9 branch was merged in - see commit 2aa56ddff). -- Eric Blake [email protected] +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
