1 |
On 1 June 2012 07:58, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@g.o> wrote: |
3 |
>> What would git signing work with rebased commits? Would all of them |
4 |
>> have to be signed once again? |
5 |
>> |
6 |
> |
7 |
> The whole point of rebasing is to throw away history (which is either |
8 |
> good or bad based on your perspective). |
9 |
> |
10 |
> So, if 14 devs spend 3 years and 2000 commits working on something in |
11 |
> a branch, and I commit it to master using a rebase, then all you'll |
12 |
> see in the master history is that rich0 committed 20k lines of code to |
13 |
> master on May 31st, and that would be signed by me. |
14 |
> |
15 |
> I think that rebasing before merging is a pretty typical workflow |
16 |
> anyway - when you submit a patch to Linus, he doesn't really care that |
17 |
> you spent six months tweaking it - he just is getting a big blob of |
18 |
> code that either works or doesn't. Does all that sub-history really |
19 |
> matter? You could always push the branch to the repository if you |
20 |
> wanted to keep it on the side. |
21 |
> |
22 |
> Rich |
23 |
> |
24 |
|
25 |
I think you're conflating "rebasing" and "squashing commits". |
26 |
|
27 |
You should rebase a long commit sequence and squash pointless fixup |
28 |
commits, and to make the commit sequence logical and ordered, possibly |
29 |
divided by logical changes that one may wish to later revert. ( That |
30 |
way, backing out a problem is simply reversing that commit and |
31 |
applying the reversal patch ) |
32 |
|
33 |
You should not rebase for the purpose of squashing an entire history |
34 |
of changes into a single scattered commit. |
35 |
|
36 |
Rebasing is more to make the history itself linear and non-complex, |
37 |
as when walking backwards through history, there being 2 parallel |
38 |
histories that generated a merged commit can be confusing for humans, |
39 |
so eliminating the parallel histories is one of the primary purposes I |
40 |
advocate use of rebase for. |
41 |
|
42 |
Squashed commits are a handy feature of rebase, but I wouldn't want to |
43 |
see an entire overlay squashed into the main tree as a single squashed |
44 |
commit. |
45 |
|
46 |
Another bad reason for squashed commits: if you're getting rid of the |
47 |
Changes files, you'll have no history on anything if you just group |
48 |
long histories into a single commit. None. |
49 |
|
50 |
|
51 |
|
52 |
-- |
53 |
Kent |
54 |
|
55 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
56 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
57 |
|
58 |
http://kent-fredric.fox.geek.nz |