Lines Matching +full:pulled +full:- +full:up

1 .. SPDX-License-Identifier: GPL-2.0
8 Git source-code management system.  Git is a powerful tool with a lot of
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
49    should usually not be changed.  Others may have pulled a copy of your
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
62    have pulled changes from another developer's repository, you are now a
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
87 having been adequately tested are relatively low - as are the chances of
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.
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
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
136 --------------------------------------
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
172 resolution - often better than the developers involved.
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;
197 tree fails to be pulled upstream, whatever problems it had will block the
210 the development cycle in order to pick up changes and fixes done elsewhere
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
216   git merge --ff-only v5.2-rc1