[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] [egit-dev] Pull vs. Rebase
|
Thanks for the prompt reply Matthias!
I completely missed that bit of the manual. So I guess when configuring pull for master, users should select 'rebase'. The manul states:
- Rebase: When pulling, new changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be rebased onto the updated remote tracking branch
- Merge: When pulling, the changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be merged with the new changes. This is the default if the new branch is based on a remote tracking branch (but this default may be overriden by specific repository configuration)
Merge is the default, presumably this is only important if the user has shared their repo with others who are relying on their SHA's not chaning. In a centralised setup like
eclipse.org is for us, presumably rebase should always be preferred when pulling from a tracking branch?
Cheers,
James
On 11 May 2011 21:55, Matthias Sohn
<matthias.sohn@xxxxxxxxxxxxxx> wrote:
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].
Matthias
