Re: [PATCH RFC] Rough draft document on merging and rebasing

From: Geert Uytterhoeven
Date: Tue Jun 04 2019 - 06:33:42 EST

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>


> --- /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


> +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.



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