Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michael Orlitzky]

On 05/31/12 16:09, Michał Górny wrote:
> On Thu, 31 May 2012 15:58:43 -0400
> Rich Freeman <rich0@g.o> wrote:
>
>> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@g.o>
>> 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.

The usual use case for a rebase is just to avoid the ugly merge commit.
For example,

  1. I clone your portage tree
  2. I start making commits locally
  3. You add a new package
  4. I try to push my changes to you

Step 4 doesn't work because your repo has changed. I can either,

  a) pull from you again (merge)
  b) pull with a rebase

And then I should be able to push to you, assuming there were no conflicts.

The merge option works fine but generates an ugly merge commit. The
rebase takes our two histories and combines them into a nice linear
history. In this case, a rebase would (essentially) take all of my
commits and stick them on top of your "new package" commit. Afterwards,
it looks like there's a nice linear history: you added a package, and
then I did a bunch of other stuff. All of the commits are there.

Since that history is linear and it looks like just a bunch of stuff on
top of your existing tree, I can push it to you without problems.

The only downside to the rebase is that it modifies my local history.
So, if somebody cloned *my* repo in the middle of that, they could get
screwed up.