On Mon, Feb 12, 2018 at 1:44 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> But I wonder why "update to upstream" is merging a signed tag in the
> first place. Wouldn't downstream's "try to keep up with" pull be
> grabbing from branch tips, not tags?
I'm actually encouraging maintainers to *not* start their work on some
random "kernel of the day".
Particularly during the kernel merge window, the upstream master
branch can be pretty flaky. It's *not* a good point to start new
development on, so if you're a maintainer, you really don't want to
use that as the basis for your work for the next merge window.
So I encourage people to use a stable point for new development, and
particularly actual release kernels. The natural way to do that is
obviously just to create a new branch:
git checkout -b topicbranch v4.15
and now you have a good new clean branch for your development.
But clearly we've got a few people who have gotten used to the whole
"git pull" convenience of both fetching and updating.
Some maintainers don't even use topic branches, because their main
work is just merging work by subdevelepoers (that goes for my own
tree: I use topic branches for merging patch queues and to
occasionally track my own experimental patches, but 99% of the time
I'm just on "master" and obviously pull other peoples branches).
And some maintainers end up using multiple repositories as branches
(the old _original_ git model). Again, you can just use "git fetch +
git reset", of course, but that's a bit unsafe. In contrast, doing
"git pull --ff-only" is a safe convenient operation that does both the
fetch and the update to whatever state.
But you do need that "--ff-only" to avoid the merge.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
