Lines Matching +full:use +full:- +full:push +full:- +full:pull

1 .. SPDX-License-Identifier: GPL-2.0
8 Git source-code management system.  Git is a powerful tool with a lot of
10 ways to use those features.  This document looks in particular at the use
11 of rebasing and merging.  Maintainers often get in trouble when they use
30  - Changing the parent (starting) commit upon which a series of patches is
36  - Changing the history of a set of patches by fixing (or deleting) broken
48  - History that has been exposed to the world beyond your private system
54    That said, there are always exceptions.  Some trees (linux-next being
61  - Do not rebase a branch that contains history created by others.  If you
67  - Do not reparent a tree without a good reason to do so.  Just being on a
71  - If you must reparent a repository, do not pick some random kernel commit
76    the -rc releases) to move to.
78  - Realize that reparenting a patch series (or making significant history
84 A frequent cause of merge-window trouble is when Linus is presented with a
86 shortly before the pull request was sent.  The chances of such a series
87 having been adequately tested are relatively low - as are the chances of
88 the pull request being acted upon.
91 well-known starting point, and they are well tested, the potential for
98 development cycle included 1,126 merge commits - nearly 9% of the total.
104 Many projects require that branches in pull requests be based on the
110 from lower-level subsystem trees and from others, either sibling trees or
113 Merging from lower-level trees
114 ------------------------------
117 lower-level maintainers sending pull requests to the higher levels.  Acting
118 on such a pull request will almost certainly generate a merge commit; that
119 is as it should be.  In fact, subsystem maintainers may want to use
120 the --no-ff flag to force the addition of a merge commit in the rare cases
123 merge, say *why* the merge is being done.  For a lower-level tree, "why" is
124 usually a summary of the changes that will come with that pull.
126 Maintainers at all levels should be using signed tags on their pull
136 --------------------------------------
139 trees tend to be a red flag when it comes time to push a branch upstream.
141 there's a good chance that a subsequent pull request will be rejected.
146 gives a warm, fuzzy feeling of being up-to-date.  But this temptation
155 a well-managed branch.
159 merge to a well-known stable point, rather than to some random commit.
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
166 before sending a pull request.  Again, this temptation is easy enough to
168 for the final pull request: Linus is adamant that he would much rather see
172 resolution - often better than the developers involved.
176 Linus in the pull request that the conflict will happen; if nothing else,
178 especially difficult conflicts, create and push a *separate* branch to show
179 how you would resolve things.  Mention that branch in your pull request,
180 but the pull request itself should be for the unmerged branch.
183 pull request is a good idea.  It may alert you to problems that you somehow
184 didn't see from linux-next and helps to understand exactly what you are
189 sometimes a cross-merge with another tree is the best way to resolve them;
211 in the tree.  As always, such a merge should pick a well-known release
212 point rather than some random spot.  If your upstream-bound branch has
213 emptied entirely into the mainline during the merge window, you can pull it
216   git merge --ff-only v5.2-rc1