Hi Jon,
On Thu, May 30, 2019 at 9:54 PM Jonathan Corbet <corbet@xxxxxxx> 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@xxxxxxx>
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@xxxxxxxxxxxxxx
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
