On Thu, 31 May 2012 16:27:48 -0400
Michael Orlitzky <michael@...> wrote:
> On 05/31/12 16:09, Michał Górny wrote:
> > On Thu, 31 May 2012 15:58:43 -0400
> > Rich Freeman <firstname.lastname@example.org> wrote:
> >> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <email@example.com>
> >> 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
> The usual use case for a rebase is just to avoid the ugly merge
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