Lines Matching refs:merge
16 the kernel community is not scared by seeing merge commits in its
68 newer base or avoiding a merge with an upstream repository is not
84 A frequent cause of merge-window trouble is when Linus is presented with a
98 development cycle included 1,126 merge commits - nearly 9% of the total.
101 independently of the others. So naturally, at least one merge will be
105 current trunk so that no merge commits appear in the history. The kernel
118 on such a pull request will almost certainly generate a merge commit; that
120 the --no-ff flag to force the addition of a merge commit in the rare cases
121 where one would not normally be created so that the reasons for the merge
122 can be recorded. The changelog for the merge should, for any kind of
123 merge, say *why* the merge is being done. For a lower-level tree, "why" is
143 It is natural to want to merge the master branch into a repository; this
144 type of merge is often called a "back merge". Back merges can help to make
159 merge to a well-known stable point, rather than to some random commit.
160 Even then, you should not back merge a tree above your immediate upstream
161 tree; if a higher-level back merge is really required, the upstream tree
164 One of the most frequent causes of merge-related trouble is when a
165 maintainer merges with the upstream in order to resolve merge conflicts
169 merge conflicts than unnecessary back merges. Seeing the conflicts lets
182 Even in the absence of known conflicts, doing a test merge before sending a
189 sometimes a cross-merge with another tree is the best way to resolve them;
190 as always, in such situations, the merge commit should explain why the
191 merge has been done. Take a moment to do it right; people will read those
209 It is relatively common to merge with the mainline toward the beginning of
211 in the tree. As always, such a merge should pick a well-known release
213 emptied entirely into the mainline during the merge window, you can pull it
216 git merge --ff-only v5.2-rc1