Re: Please rebase local development on current master before pushing...

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Tue, Aug 02, 2011 at 10:32:15AM +0200, David Kastrup wrote:
>> 
>> We have had several single-commit branches recently.  Those appear in
>> the history just as "merge with master" and require additional work for
>> tracking the changes, worse so when the branchoff point is a long way
>> backwards.
>> 
>> So please make it a habit to do
>>     git rebase origin
>> before doing
>>     git push
>
> Thanks for the tip!  Sorry, I'm still fumbling around with git,
> and I'm not certain if this applies to me.
>
> When I build a release, I follow the @examples on this page
> completely literally -- I don't even glance at the text when I
> cut&paste it into my shell:
> http://lilypond.org/doc/v2.15/Documentation/contributor/minor-release-checklist
>
> If I need to have a few "git rebase origin" in those commands,
> could you please push a fix to that page?  It's in
>   Documentation/contributor/release-work.itexi
> line 70 - 230 or so.

No, heaven forbid.  The recipe is for working from changes which are
already in the upstream repository and likely are the base for the work
of others.  It is not relevant for the release preparation from a public
branch.

The main point of a "rebase" is when you have been working on some
private functionality, and the main development has continued.  If you
push your work after "git pull", you get a merge from your private
branch and the latest development.  If you do "git rebase origin"
before, then your development is rewritten as if it were done on top of
the current origin/master.  History is linear then and easier to follow.

-- 
David Kastrup