Fossil

Check-in [9b32c180]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Minor editorial changes to rebaseharm.md, in an attempt to improve clarity and readability.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 9b32c180eba0f4628c91cdff8da2f33e3b6b3055c9f3b62fbf30d775f80bbc1e
User & Date: drh 2019-09-06 20:38:58
Context
2019-09-07
15:03
Adjust test case for TH1 permissions tests. WrUnver (y) is not enabled by default and must be intentionally set. check-in: 582d3357 user: andybradford tags: trunk
2019-09-06
20:38
Minor editorial changes to rebaseharm.md, in an attempt to improve clarity and readability. check-in: 9b32c180 user: drh tags: trunk
14:39
Fix a typo in the rebaseharm.md document. check-in: 82f75864 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/rebaseharm.md.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
..
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
...
112
113
114
115
116
117
118
119
120

121
122
123
124
125
126
127
...
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
# Rebase Considered Harmful

Fossil deliberately does not implement "rebase", because the original
designer of Fossil (and author of this article) considers rebase to be 
an anti-pattern to be avoided. This article attempts to
explain that point of view.

## 1.0 Rebasing is dangerous

Everyone, even the most vocal advocates of rebase, agrees that rebase can
cause problems when misused.  All rebase documentation talks about the
[golden rule of rebase][golden], that it should never be used on a public
branch.  Horror stories of misused rebase abound, and the rebase 
documentation devotes considerable space to hints on how to recover from
rebase errors and/or misuse.

Sometimes sharp and dangerous tools are justified,
because they accomplish things that cannot be
(easily) done otherwise.  But rebase does not fall into that category.
It provides no new capabilities, as we shall see in the next section:

## 2.0 A rebase is just a merge with historical references omitted

A rebase is really nothing more than a merge (or a series of merges)
that deliberately forgets one of the parents of each merge step.
To help illustrate this fact,
consider the first rebase example from the 
................................................................................
justifies it by saying "rebas[e] makes for a cleaner history".  I read
that sentence as a tacit admission that the Git history display 
capabilities are weak and need active assistance from the user to 
keep things manageable.
Surely a better approach is to record
the complete ancestry of every check-in but then fix the tool to show
a "clean" history in those instances where a simplified display is
desirable and edifying, but retaining the option to show the real,
complete, messy history for cases where detail and accuracy are more
important.

So, another way of thinking about rebase is that it is a kind of
merge that intentionally forgets some details in order to
not overwhelm the weak history display mechanisms available in Git.

................................................................................
you are keeping private branches.  Or, to put it another way, you are
doing siloed development.  You are not sharing your intermediate work
with collaborators.  This is not good for product quality.

[Nagappan, et. al][nagappan] studied bugs in Windows Vista and found
that best predictor of bugs is the distance on the org-chart between
the stake-holders.  Or, bugs are reduced when the engineers talk to
one another.  Similar finds arise in other disciplines.  Keeping
private branches is a key symptom of siloing.


[Weinberg][weinberg] argues programming should be "egoless".  That
is to say, programmers should avoid linking their code with their sense of
self, as that makes it more difficult for them to find and respond
to bugs, and hence makes them less productive.  Many developers are
drawn to private branches out of sense of ego.  "I want to get the
code right before I publish it".  I sympathize with this sentiment,
................................................................................

  2.  Cherry-picks provide an opportunity to test each new check-in
      before it is committed to the blockchain

  3.  Cherry-pick merges are "safe" in the sense that they do not
      cause problems for collaborators if you do them on public branches.

  4.  Cherry-picks preserve both the original and the revised check-ins,
      so both timestamps are preserved.

## 8.0 Summary and conclusion

Rebasing is an anti-pattern.  It is dishonest.  It deliberately
omits historical information.  It causes problems for collaboration.
And it has no offsetting benefits.


|






|
|
|

|
|



|
|







 







|







 







|
|
>







 







|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
..
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
...
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
...
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
# Rebase Considered Harmful

Fossil deliberately omits a "rebase" command, because the original
designer of Fossil (and author of this article) considers rebase to be 
an anti-pattern to be avoided. This article attempts to
explain that point of view.

## 1.0 Rebasing is dangerous

Most people, even strident advocates rebase, agree that rebase can
cause problems when misused.  Rebase documentation talks about the
[golden rule of rebase][golden]: that it should never be used on a public
branch.  Horror stories of misused rebase abound, and the rebase 
documentation devotes considerable space toward explaining how to
recover from rebase errors and/or misuse.

Sometimes sharp and dangerous tools are justified,
because they accomplish things that cannot be
(easily) done otherwise.  But rebase does not fall into that category,
because rebase provides no new capabilities.  To wit:

## 2.0 A rebase is just a merge with historical references omitted

A rebase is really nothing more than a merge (or a series of merges)
that deliberately forgets one of the parents of each merge step.
To help illustrate this fact,
consider the first rebase example from the 
................................................................................
justifies it by saying "rebas[e] makes for a cleaner history".  I read
that sentence as a tacit admission that the Git history display 
capabilities are weak and need active assistance from the user to 
keep things manageable.
Surely a better approach is to record
the complete ancestry of every check-in but then fix the tool to show
a "clean" history in those instances where a simplified display is
desirable and edifying, but retain the option to show the real,
complete, messy history for cases where detail and accuracy are more
important.

So, another way of thinking about rebase is that it is a kind of
merge that intentionally forgets some details in order to
not overwhelm the weak history display mechanisms available in Git.

................................................................................
you are keeping private branches.  Or, to put it another way, you are
doing siloed development.  You are not sharing your intermediate work
with collaborators.  This is not good for product quality.

[Nagappan, et. al][nagappan] studied bugs in Windows Vista and found
that best predictor of bugs is the distance on the org-chart between
the stake-holders.  Or, bugs are reduced when the engineers talk to
one another.  Similar findings arise in other disciplines.  Keeping
private branches does not prove that developers are communicating
insufficiently, but it is a key symptom that problem.

[Weinberg][weinberg] argues programming should be "egoless".  That
is to say, programmers should avoid linking their code with their sense of
self, as that makes it more difficult for them to find and respond
to bugs, and hence makes them less productive.  Many developers are
drawn to private branches out of sense of ego.  "I want to get the
code right before I publish it".  I sympathize with this sentiment,
................................................................................

  2.  Cherry-picks provide an opportunity to test each new check-in
      before it is committed to the blockchain

  3.  Cherry-pick merges are "safe" in the sense that they do not
      cause problems for collaborators if you do them on public branches.

  4.  Cherry-picks keep both the original and the revised check-ins,
      so both timestamps are preserved.

## 8.0 Summary and conclusion

Rebasing is an anti-pattern.  It is dishonest.  It deliberately
omits historical information.  It causes problems for collaboration.
And it has no offsetting benefits.