1 |
On 5 July 2015 at 17:03, C Bergström <cbergstrom@×××××××××.com> wrote: |
2 |
> |
3 |
> Again I don't see it as "lying" - (you're still working on stuff until |
4 |
> you push.. development isn't done) The ability to do micro or |
5 |
> incremental commits instead of the svn's forced wait approach is the |
6 |
> benefit here. |
7 |
|
8 |
|
9 |
Generally its better to structure the tree in the order it *should* |
10 |
happen, not the order it *did* happen. |
11 |
|
12 |
[intentional sillyness: ] If we were to order the tree in the way it |
13 |
*did* happen, we'd have to work out when which person thought about |
14 |
which idea first and what they were looking at when they thought of |
15 |
that, and re-arrange commits to suit that order. {/instentional |
16 |
sillyness] |
17 |
|
18 |
Obviously that would be silly. |
19 |
|
20 |
Generally however that does suggest, that where it is possible to, and |
21 |
where it is logical to do so, commit squashing and commit re-ordering |
22 |
is valueable. |
23 |
|
24 |
For instance, if you commit something locally, and then you realise |
25 |
you made a trivial mistake 3 commits later, it is better to create the |
26 |
fix, and move that fix back to when the commit it pertained to. Nobody |
27 |
wants to wade through dedicated commits where you fix up your mistakes |
28 |
in minor syntax errors if you can actually avoid that in the first |
29 |
place. |
30 |
|
31 |
|
32 |
This also lends its hand to commit oriented testing, as it allows the |
33 |
pushed trees to always be pristine, and have clean lines of history |
34 |
that each commit on a given line can be expected to be used |
35 |
independently, and be expected to be sane, instead of the commit |
36 |
walker having to isolate the good commits and the bad commits that get |
37 |
fixed 3 commits later. |
38 |
|
39 |
|
40 |
The trick is not to be dogmatic about it, and identify the cases where |
41 |
different things work out to be best, and use your judgement to work |
42 |
out which one works best. |
43 |
|
44 |
Rebases and merges were designed to be used in the same repository for |
45 |
the most part, the only caveat being that any place you perform a |
46 |
merge, performing a subsequent rebase of that merge gets tricky. |
47 |
|
48 |
Merges are also convenient for merge reversals if they prove to be |
49 |
neccessary, because you can just create HEAD with HEAD~3's tree and |
50 |
you've reverted the whole merge, instead of having to work our where |
51 |
the massive rebase line started and ended before it was applied |
52 |
nuclearly and needing reversion ( somehow ). Granted this use case is |
53 |
expected to be incredibly rare, but its just a demonstration of how |
54 |
merge can be a help more than a hinderance in specific cases. |
55 |
|
56 |
Oh, and as for merge commits and not needing patches ... that's |
57 |
viable. Git is not really patch oriented. Patches are more a "view" |
58 |
of the data than the state of the data. |
59 |
|
60 |
A "clean" merge just creates a new tree object by duplicating the tree |
61 |
of HEAD^ where a child leaf is replaced with child leaves from HEAD^^ |
62 |
in a recursive fashion, and any "patch" as such would be garbage |
63 |
simply showing a list of SHA1's with +/- on the front of them which |
64 |
you couldn't directly use. |
65 |
|
66 |
You could attempt to format that as a patch, but it would be basically |
67 |
`git diff HEAD^ HEAD^^` with some special rules ( It really doesn't |
68 |
map directly to diff, there's 3-way-diff format as well, but ... yeah |
69 |
). |
70 |
|
71 |
And non-clean merges are a bit of a dogs breakfast and can be a right |
72 |
pain in the arse if somebody hits them in a rebase. I've just tried to |
73 |
avoid those because they're too hard, and prefer to find a way to |
74 |
resolve them in either HEAD^ or HEAD^^ first before merging to make |
75 |
sure the merge is clean. |
76 |
|
77 |
|
78 |
-- |
79 |
Kent |
80 |
|
81 |
KENTNL - https://metacpan.org/author/KENTNL |