| 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 |
Archives