Messages in this thread | | | From | Geert Uytterhoeven <> | Date | Tue, 4 Jun 2019 12:29:33 +0200 | Subject | Re: [PATCH RFC] Rough draft document on merging and rebasing |
| |
Hi Jon,
On Thu, May 30, 2019 at 9:54 PM Jonathan Corbet <corbet@lwn.net> wrote: > This is a first attempt at following through on last month's discussion > about common merging and rebasing errors. The hope here is to document > existing best practices rather than trying to define new ones. I've > certainly failed somewhere along the way; please set me straight and I'll > try to do better next time. > > Thanks, > > jon > > ------------- > docs: Add a document on repository management > > Every merge window seems to involve at least one episode where subsystem > maintainers don't manage their trees as Linus would like. Document the > expectations so that at least he has something to point people to. > > Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Thanks!
> --- /dev/null > +++ b/Documentation/maintainer/repo-hygiene.rst
> +One thing to be aware of in general is that, unlike many other projects, > +the kernel community is not scared by seeing merge commits in its > +development history. Indeed, given the scale of the project, avoiding > +merges would be nearly impossible. Some problems encountered by > +maintainers results from a desire to avoid merges, while others come from
result
> +merging a little too often.
[...]
> + - Realize the rebasing a patch series changes the environment in which it
Realize that
> + was developed and, likely, invalidates much of the testing that was > + done. A rebased patch series should, as a general rule, be treated like > + new code and retested from the beginning.
> +Finally > +======= > + > +It is relatively common to merge with the mainline toward the beginning of > +the development cycle in order to pick up changes and fixes done elsewhere > +in the tree. As always, such a merge should pick a well-known release > +point rather than some random spot. If your upstream-bound branch has > +emptied entirely into the mainline during the merge window, you can pull it > +forward with a command like:: > + > + git merge v5.2-rc1^0 > + > +The "^0" will cause Git to do a fast-forward merge (which should be > +possible in this situation), thus avoiding the addition of a spurious merge > +commit.
I usually use
git rebase v5.2-rc1 <mybranch>
_after_ verifying everything has been merged, i.e.
git cherry -v v5.2-rc1 <mybranch>
did not give any output.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
| |