1 |
On Thu, 31 May 2012 15:58:43 -0400 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@g.o> |
5 |
> wrote: |
6 |
> > What would git signing work with rebased commits? Would all of them |
7 |
> > have to be signed once again? |
8 |
> > |
9 |
> |
10 |
> The whole point of rebasing is to throw away history (which is either |
11 |
> good or bad based on your perspective). |
12 |
> |
13 |
> So, if 14 devs spend 3 years and 2000 commits working on something in |
14 |
> a branch, and I commit it to master using a rebase, then all you'll |
15 |
> see in the master history is that rich0 committed 20k lines of code to |
16 |
> master on May 31st, and that would be signed by me. |
17 |
> |
18 |
> I think that rebasing before merging is a pretty typical workflow |
19 |
> anyway - when you submit a patch to Linus, he doesn't really care that |
20 |
> you spent six months tweaking it - he just is getting a big blob of |
21 |
> code that either works or doesn't. Does all that sub-history really |
22 |
> matter? You could always push the branch to the repository if you |
23 |
> wanted to keep it on the side. |
24 |
|
25 |
That sounds like a pretty poor workflow to me. If I tweak something for |
26 |
3 years, I'm likely to have a larger set of logically organized commits. |
27 |
I'm not saying it's unlikely I'm going to rebase fixes for obvious |
28 |
mistakes but putting everything onto one blob just makes the changes |
29 |
harder to read and less maintainable. |
30 |
|
31 |
For example, if I first create a basic function and then add additional |
32 |
options to it, I'm likely to keep those as separate commits. If one of |
33 |
the changes was a really bad idea, I'd like to revert the appropriate |
34 |
commit rather than removing all traces of it by hand and mistakenly |
35 |
introducing even worse breakage. |
36 |
|
37 |
-- |
38 |
Best regards, |
39 |
Michał Górny |