Downstreams from core

đź”® Meta
1

There are several questions about merging commits of owncloud/core into nextcloud/server:

  • How often will we do such downstreams?
  • Will we “stream down” every commit?
  • How long will we do this, or will we stop with that once we have more independent functions and code?
1 Like
2

@blizzz and @LukasReschke has prepared something. They planned to do this regularly. I think we will try to get as much downstream as possible.

3

Like the motto of the mail-app: “We are not reinventing the wheel!” :stuck_out_tongue_winking_eye:

4

The changeset until yesterday is here: https://github.com/nextcloud/server/pull/25 (input still welcome).
When this is merged, I’ll prepare today’s downstream PR later.

5

Ah, to be more precise

The idea is to do this daily for now.

We pull all commits that happened at ownCloud and create the PR out of it. Thus, basically it will include any commit. But not everything will be taken over (e.g. branding related things), which should end up in merge conflicts anyway. In the mentioned one I dealt with that for instance.

Until we experience bigger issues with backporting, or decide to just leave it. No fixed date, yet.

6

I’ve just created a downstream label on GitHub to make them better sortable :wink:

cc @blizzz

1 Like
7

Lesson learnt: Always

git pull upstream master

No rebase. Ever. This rewrites history and follow-up downstream PRs will always bring in already merged commits.

(upstream is the remote git repo, initialized by git remote add upstream https://github.com/owncloud/core.git)

8

I would be very interested by an explanation as I think I already saw this pb without correct understanding :confused:
Would you have some times to describe what happens with rebase and why we must avoid it ?

Pleeeease ? :beer:

9

First, and to clarify, the “No rebase. Ever.” relates solely to this use case: pulling commits from upstream (owncloud).

My issue was caused, because of these steps:

  1. git pull uptream master – :green_heart:
  2. Open pull request – :green_heart:
  3. Meanwhile other Nextcloud PRs were merged resulting in conflicts – :green_heart:
  4. I did an git rebase origin master :red_circle:

A git rebase put’s the commit of your current working branch on top of the specified branch. By doing so however, there will be a new history, because the underlying base changed. The commits will have a new hash, for instance. Anyway, this will result that in a subsequent, second git pull upstream master the already merged commits were not matched with those present in upstream and you would merge them twice.

This does not happen, if you do the git pull upstream master again on a fresh branch based on origin master (as step 4). You can even force push to the branch you opened the pull request with.

In the usual pull requests that you do when fixing bugs or doing improvements it is absolutely OK to rebase.

@Armage is all clarity dissolved now? :wink:

10

Many thanks for your answer !

Will it work if, before step 1, if you insert systematically a “git pull origin master” ? You will get the last commits from origin missing on your working branch. Then you update from upstream (step 1) and hope that nobody will merge a PR on origin before yours :slight_smile:
Is that right ?

Git is not simple, as usual… Powerfull but not easy to master. :scream:

Anyway, thanks again :beers:

11

Yes! That’s in my workflow also.

Other merges are OK as long as they don’t insert conflicts :wink: Otherwise, you just do the aforementioned steps again and overwrite (force push to) the PR branch. No problem.