@@ -195,6 +195,92 @@ reason::
195
195
refs, no explanation is needed. For a failed ref, the reason for
196
196
failure is described.
197
197
198
+ Note about fast-forwards
199
+ ------------------------
200
+
201
+ When an update changes a branch (or more in general, a ref) that used to
202
+ point at commit A to point at another commit B, it is called a
203
+ fast-forward update if and only if B is a descendant of A.
204
+
205
+ In a fast-forward update from A to B, the set of commits that the original
206
+ commit A built on top of is a subset of the commits the new commit B
207
+ builds on top of. Hence, it does not lose any history.
208
+
209
+ In contrast, a non-fast-forward update will lose history. For example,
210
+ suppose you and somebody else started at the same commit X, and you built
211
+ a history leading to commit B while the other person built a history
212
+ leading to commit A. The history looks like this:
213
+
214
+ ----------------
215
+
216
+ B
217
+ /
218
+ ---X---A
219
+
220
+ ----------------
221
+
222
+ Further suppose that the other person already pushed changes leading to A
223
+ back to the original repository you two obtained the original commit X.
224
+
225
+ The push done by the other person updated the branch that used to point at
226
+ commit X to point at commit A. It is a fast-forward.
227
+
228
+ But if you try to push, you will attempt to update the branch (that
229
+ now points at A) with commit B. This does _not_ fast-forward. If you did
230
+ so, the changes introduced by commit A will be lost, because everybody
231
+ will now start building on top of B.
232
+
233
+ The command by default does not allow an update that is not a fast-forward
234
+ to prevent such loss of history.
235
+
236
+ If you do not want to lose your work (history from X to B) nor the work by
237
+ the other person (history from X to A), you would need to first fetch the
238
+ history from the repository, create a history that contains changes done
239
+ by both parties, and push the result back.
240
+
241
+ You can perform "git pull", resolve potential conflicts, and "git push"
242
+ the result. A "git pull" will create a merge commit C between commits A
243
+ and B.
244
+
245
+ ----------------
246
+
247
+ B---C
248
+ / /
249
+ ---X---A
250
+
251
+ ----------------
252
+
253
+ Updating A with the resulting merge commit will fast-forward and your
254
+ push will be accepted.
255
+
256
+ Alternatively, you can rebase your change between X and B on top of A,
257
+ with "git pull --rebase", and push the result back. The rebase will
258
+ create a new commit D that builds the change between X and B on top of
259
+ A.
260
+
261
+ ----------------
262
+
263
+ B D
264
+ / /
265
+ ---X---A
266
+
267
+ ----------------
268
+
269
+ Again, updating A with this commit will fast-forward and your push will be
270
+ accepted.
271
+
272
+ There is another common situation where you may encounter non-fast-forward
273
+ rejection when you try to push, and it is possible even when you are
274
+ pushing into a repository nobody else pushes into. After you push commit
275
+ A yourself (in the first picture in this section), replace it with "git
276
+ commit --amend" to produce commit B, and you try to push it out, because
277
+ forgot that you have pushed A out already. In such a case, and only if
278
+ you are certain that nobody in the meantime fetched your earlier commit A
279
+ (and started building on top of it), you can run "git push --force" to
280
+ overwrite it. In other words, "git push --force" is a method reserved for
281
+ a case where you do mean to lose history.
282
+
283
+
198
284
Examples
199
285
--------
200
286
0 commit comments