| 1 |
On Thu, 31 May 2012 16:27:48 -0400 |
| 2 |
Michael Orlitzky <michael@××××××××.com> wrote: |
| 3 |
|
| 4 |
> On 05/31/12 16:09, Michał Górny wrote: |
| 5 |
> > On Thu, 31 May 2012 15:58:43 -0400 |
| 6 |
> > Rich Freeman <rich0@g.o> wrote: |
| 7 |
> > |
| 8 |
> >> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@g.o> |
| 9 |
> >> wrote: |
| 10 |
> >>> What would git signing work with rebased commits? Would all of |
| 11 |
> >>> them have to be signed once again? |
| 12 |
> >>> |
| 13 |
> >> |
| 14 |
> >> The whole point of rebasing is to throw away history (which is |
| 15 |
> >> either good or bad based on your perspective). |
| 16 |
> >> |
| 17 |
> >> So, if 14 devs spend 3 years and 2000 commits working on something |
| 18 |
> >> in a branch, and I commit it to master using a rebase, then all |
| 19 |
> >> you'll see in the master history is that rich0 committed 20k lines |
| 20 |
> >> of code to master on May 31st, and that would be signed by me. |
| 21 |
> >> |
| 22 |
> >> I think that rebasing before merging is a pretty typical workflow |
| 23 |
> >> anyway - when you submit a patch to Linus, he doesn't really care |
| 24 |
> >> that you spent six months tweaking it - he just is getting a big |
| 25 |
> >> blob of code that either works or doesn't. Does all that |
| 26 |
> >> sub-history really matter? You could always push the branch to |
| 27 |
> >> the repository if you wanted to keep it on the side. |
| 28 |
> > |
| 29 |
> > That sounds like a pretty poor workflow to me. If I tweak something |
| 30 |
> > for 3 years, I'm likely to have a larger set of logically organized |
| 31 |
> > commits. I'm not saying it's unlikely I'm going to rebase fixes for |
| 32 |
> > obvious mistakes but putting everything onto one blob just makes |
| 33 |
> > the changes harder to read and less maintainable. |
| 34 |
> > |
| 35 |
> > For example, if I first create a basic function and then add |
| 36 |
> > additional options to it, I'm likely to keep those as separate |
| 37 |
> > commits. If one of the changes was a really bad idea, I'd like to |
| 38 |
> > revert the appropriate commit rather than removing all traces of it |
| 39 |
> > by hand and mistakenly introducing even worse breakage. |
| 40 |
> > |
| 41 |
> |
| 42 |
> That isn't what rebasing does, unless you do an interactive rebase and |
| 43 |
> decide to squash the commits. |
| 44 |
|
| 45 |
Yes, it isn't but such kind of work flow was presented in the message I |
| 46 |
replied to. |
| 47 |
|
| 48 |
> The usual use case for a rebase is just to avoid the ugly merge |
| 49 |
> commit. |
| 50 |
|
| 51 |
Which devs should simply do whenever they use the scenario you |
| 52 |
mentioned. I agree we could block 'auto-merges' when pushing to |
| 53 |
a modified repo but not disallow a valid merges from devs who know what |
| 54 |
they're doing. |
| 55 |
|
| 56 |
-- |
| 57 |
Best regards, |
| 58 |
Michał Górny |
Archives