From: Felipe Contreras Date: Tue, 08 Jun 2021 07:29:13 GMT Subject: Re: [PATCH] doc: merge: mention default of defaulttoupstream Message-ID: <60bf1c49e3f89_1a2cb92082b@natae.notmuch> In-Reply-To: Junio C Hamano wrote: > Felipe Contreras writes: > > > Commit a01f7f2ba0 (merge: enable defaulttoupstream by default, > > 2014-04-20) forgot to mention the new default in the configuration > > documentation. > > > > Signed-off-by: Felipe Contreras > > --- > > Documentation/config/merge.txt | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/config/merge.txt b/Documentation/config/merge.txt > > index cb2ed58907..6b66c83eab 100644 > > --- a/Documentation/config/merge.txt > > +++ b/Documentation/config/merge.txt > > @@ -14,7 +14,7 @@ merge.defaultToUpstream:: > > branches at the remote named by `branch..remote` > > are consulted, and then they are mapped via `remote..fetch` > > to their corresponding remote-tracking branches, and the tips of > > - these tracking branches are merged. > > + these tracking branches are merged. Defaults to true. > > That's definititely an improvement. > > Will queue. > > By the way, is the convoluted description around remote-tracking > branches still understandable to those who often work on a branch > forked from another local branch, or would readers be helped if we > had a two separate descriptions (one forking from remote and the > other forking locally)? I don't think there's any fundamental difference between origin/master, and master. In both cases setting upstream to that simply means "I want `git rebase` to use this by default". There is a separate question of where you should fetch from when upstream is 'master' but that's another topic. What does require explanation is the triangular workflow. Separating descriptions for a triangular worflow, and a two-way workflow might make sense. -- Felipe Contreras