On 2014-05-02 17:12, Felipe Contreras wrote: > Richard Hansen wrote: >> Should branch.autosetuprebase be replaced with a new >> branch.autosetupmode setting? > > Maybe. But if so, I think that should be done in another series. > Otherwise we'll never have a chance to change anything. Sure. >>> The possible values are 'merge', >>> + 'rebase', and 'rebase-preserve'. >> >> While the name 'merge' is mostly self-explanatory, I think it needs >> further clarification: Does 'merge' imply --no-ff? Or --ff? Or the >> value of merge.ff? > > 'pull.mode=merge' will do the same as `git merge`, I don't see where or > how it can be explained more clearly. How about: branch.<name>.pullmode:: Determines how 'git pull' integrates the fetched branch into branch <name>. Defaults to the value of `pull.mode`. Supported values: + -- `merge`::: Merge the fetched branch into <name>. See also `merge.ff`. `rebase`::: Find the point at which <name> forked from the fetched branch (see the `--fork-point` option of linkgit:git-merge-base[1]), then rebase the commits between the fork point and branch <name> onto the fetched branch. `rebase-preserve`::: Like `rebase` but passes `--preserve-merges` to 'git rebase'. -- + *NOTE*: `rebase` and `rebase-preserve` are potentially dangerous; do *not* use them unless you understand the implications (see linkgit:git-rebase[1] for details). pull.mode:: See `branch.<name>.pullmode`. Defaults to `merge`. > >> Which side will be the first parent? > > The same as things currently are: the pulled branch into the current > branch (current branch is first parent). This was a rhetorical question -- I was trying to point out that the current behavior should be documented. > > We should probably change this, but that's out of scope of this series, > and hasn't been decided yet. Agreed. If this series is merged, a future series could add a 'merge-there' pull mode. >> Also, rather than copy+paste >> the description from branch.<name>.pullmode, I'd prefer a brief >> reference. For example: >> >> pull.mode:: >> See branch.<name>.pullmode. Defaults to 'merge'. > > I'd say pull.mode is the important one. Either way works for me. How about this: branch.<name>.pullmode:: Overrides the value of `pull.mode` for branch <name>. pull.mode:: Determines how 'git pull' integrates the fetched branch into the current branch. Supported values: + -- `merge`::: (default) Merge the fetched branch into the current branch. See also `merge.ff`. `rebase`::: Find the point at which the current branch forked from the fetched branch (see the `--fork-point` option of linkgit:git-merge-base[1]), then rebase the commits between the fork point and the current branch onto the fetched branch. `rebase-preserve`::: Like `rebase` but passes `--preserve-merges` to 'git rebase'. -- + *NOTE*: `rebase` and `rebase-preserve` are potentially dangerous; do *not* use them unless you understand the implications (see linkgit:git-rebase[1] for details). -Richard -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html