lkml.org 
[lkml]   [2019]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2019-06-04 12:30    [W:0.136 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site