Hi Ben,
Le 2021-07-28 à 22:01, Ben Boeckel a écrit :
Hi,
I recently discovered some of the nicer behaviors of the `--track`
option for local branches (courtesy of `vim-fugitive`'s status
rendering). However, after a few weeks of slowly working `-t
origin/master` into my workflow, I figured that Git could help me out
here.
This patch adds two new configuration variables to initialize the
`branch.<name>.*` settings for tracking remote branches.
I searched the docs (including `Documentation/gitworkflows.txt`), but
didn't see anywhere to describe the fork-based workflow common on forges
(such as GitHub and GitLab) where this felt "at home". I suppose I could
describe the workflow I'm used to, but I think I'll hammer that out as
blog posts before submitting it as documentation.
I'm in favor of a change like the one you propose, thanks for working on this!
The 'triangular' aka 'forking' workflow is, as you discovered, only explicitely
mentioned in the description of '@{push}' [1]. 'gitworkflows(5)' is mostly about
how the workflow used by the Git projet itself (from the description):
This document attempts to write down and motivate some of the workflow
elements used for git.git itself.
I suspect there are more tests that should be added.
Thanks,
--Ben
---
v1 -> v2:
- removed `branch.defaultPushRemote` (`remote.pushDefault` covers this
case already)
- improved the commit message with more background and an expanation
of the intended uses
Small nit: usually when sending a second version of a patch, you would use
the '-v2' argument to 'git format-patch' so that the patch and cover letter
is prefixed [PATCH v2].
[1] https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-emltbranchnamegtpushemegemmasterpushemempushem
