Graham Percival <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
