Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 <felipe.contreras@xxxxxxxxx> > > --- > > 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.<current branch>.remote` > > are consulted, and then they are mapped via `remote.<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
