On Thu, 31 May 2012 16:27:48 -0400 Michael Orlitzky <[email protected]> wrote:
> On 05/31/12 16:09, Michał Górny wrote: > > On Thu, 31 May 2012 15:58:43 -0400 > > Rich Freeman <[email protected]> wrote: > > > >> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <[email protected]> > >> wrote: > >>> What would git signing work with rebased commits? Would all of > >>> them have to be signed once again? > >>> > >> > >> The whole point of rebasing is to throw away history (which is > >> either good or bad based on your perspective). > >> > >> So, if 14 devs spend 3 years and 2000 commits working on something > >> in a branch, and I commit it to master using a rebase, then all > >> you'll see in the master history is that rich0 committed 20k lines > >> of code to master on May 31st, and that would be signed by me. > >> > >> I think that rebasing before merging is a pretty typical workflow > >> anyway - when you submit a patch to Linus, he doesn't really care > >> that you spent six months tweaking it - he just is getting a big > >> blob of code that either works or doesn't. Does all that > >> sub-history really matter? You could always push the branch to > >> the repository if you wanted to keep it on the side. > > > > That sounds like a pretty poor workflow to me. If I tweak something > > for 3 years, I'm likely to have a larger set of logically organized > > commits. I'm not saying it's unlikely I'm going to rebase fixes for > > obvious mistakes but putting everything onto one blob just makes > > the changes harder to read and less maintainable. > > > > For example, if I first create a basic function and then add > > additional options to it, I'm likely to keep those as separate > > commits. If one of the changes was a really bad idea, I'd like to > > revert the appropriate commit rather than removing all traces of it > > by hand and mistakenly introducing even worse breakage. > > > > That isn't what rebasing does, unless you do an interactive rebase and > decide to squash the commits. Yes, it isn't but such kind of work flow was presented in the message I replied to. > The usual use case for a rebase is just to avoid the ugly merge > commit. Which devs should simply do whenever they use the scenario you mentioned. I agree we could block 'auto-merges' when pushing to a modified repo but not disallow a valid merges from devs who know what they're doing. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
