1 |
On 1 June 2012 20:16, Dirkjan Ochtman <djc@g.o> wrote: |
2 |
> Can you elaborate on why the cleaner history a no-merge policy |
3 |
> enforces is a good thing? I actually think that seeing merge commits |
4 |
> might clarify the history; it can be valuable to see that some mistake |
5 |
> was made in a merge instead, but you can only see that if there's an |
6 |
> explicit merge commit. |
7 |
> |
8 |
> I should note that I come at this from the Mercurial side, where the |
9 |
> immutability of (public) history has historically carried more value |
10 |
> than on the git side (and related to that, rebase-like tools were less |
11 |
> integrated until relatively recently). |
12 |
> |
13 |
> Cheers, |
14 |
> |
15 |
> Dirkjan |
16 |
> |
17 |
|
18 |
One of the perk of fast-forward only histories is merge problems don't happen. |
19 |
|
20 |
If a commit sequence isn't fast-fowardable, then the submitter has to |
21 |
rebase it, and a rebased history is a guaranteed clean merge. |
22 |
|
23 |
It also puts the onus on making the patch sequence mergable on the |
24 |
contributor of that patch sequence, by forcing them to resolve |
25 |
conflicts before they can submit their branch for inclusion, and this |
26 |
is good, because they understand their own changes best, and are the |
27 |
best person to decide how to deal with conflicts. |
28 |
|
29 |
The best example of this is 2 people contribute behaviourally |
30 |
identical code, with different syntax . |
31 |
|
32 |
In the case of a merge, the person performing the merge has to decide |
33 |
which one to take, and they might not be the best person to do so. ( |
34 |
And historically, it can be confusing if you look at the parents of |
35 |
the merge, and find the 2 competing implementations, of which only 1 |
36 |
is relevant ) |
37 |
|
38 |
If you request that a branch is rebased before it is integrated, then |
39 |
this problem solves itself in a way. |
40 |
|
41 |
Whoevers implementation gets in the tree first gets in, and then the |
42 |
second person rebases their branch on top of that. |
43 |
|
44 |
In the process of performing the rebase, the second person will |
45 |
discover the precise commit on their side that introduces a conflict, |
46 |
and be able to decide if they need to replace the existing code |
47 |
anyway, or if they need to destroy their own code. |
48 |
|
49 |
And when they're done, their entire commit series should be sane and |
50 |
logical as if the first persons code was there in the first place |
51 |
before the second person even started coding. |
52 |
|
53 |
a--->b--->c---->d--->e--->f |
54 |
| \|/ |
55 |
\--->x--->y---->z |
56 |
|
57 |
Essentially, in this diagram, if d and y are different, but |
58 |
equivalent, they will cause a collision when merge Z is performed. |
59 |
|
60 |
By performing a rebase of the second branch, the logical order becomes |
61 |
|
62 |
a--->b--->c---->d--->e--->f--->x--->y--->z |
63 |
|
64 |
And when the rebaser is applying "y", they will notice it is likely |
65 |
redundant, and the history will become |
66 |
|
67 |
a--->b--->c---->d--->e--->f--->x--->z |
68 |
|
69 |
And in both the merge and rebase examples, z will be the same, just |
70 |
the cognitive overhead of understanding "what the hell happened" in |
71 |
the latter case is simpler, as the biggest delta between any 2 commits |
72 |
will be 1 commit worth, whereas in the merge case, there will be a |
73 |
huge delta between the commit before the merge, and the commit after |
74 |
the merge, and looking at the merge itself diff-wise, you'll be |
75 |
comparing the aggregate result of 2 entire branches worth of commits, |
76 |
as opposed to only comparing one small and simple commit with another. |
77 |
|
78 |
|
79 |
-- |
80 |
Kent |
81 |
|
82 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
83 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
84 |
|
85 |
http://kent-fredric.fox.geek.nz |