2011/5/11 James Blackburn
<jamesblackburn@xxxxxxxxx>
Hi All,
We're iterating through git migration tests here, and I'm wondering about the workflow of updating from the central repository.
As we won't have access to gerrit, cdt committers are going to be pulling and pushing directly from a central CDT repo. The proposed workflow that we've got still involves bugzilla:
The CDT repo is quite big (there are 126 .projects) and very active. So I'm worried that if every committer just follows the egit UI, they'll pull, followed by push, and every pull will be a merge, so we'll end up with sphagetti history:
yeah, this kind of history is hard to understand, also tools like git bisect on a more linear graph
will be much more useful.
As I understand it they should instead fetch, follow by a rebase: git pull --rebase - which has equivalent semantics to cvs update. Is there anyway to get egit to do this by default? Looking at our proposed migrated repository, history is nice and linear, should we worry about losing this...?
Any tips / tricks & recommendations from the egiters is welcome!
Currently the pull strategy can be configured when creating a new local branch based on a remote
tracking branch in the branch creation dialog mentioned in [1]. If you select the pull strategy "Rebase"
pull will do fetch + rebase (local branch onto updated remote tracking branch).
If you want the default pull strategy to be configurable we could add support for the
git config parameter branch.autosetuprebase [2].
