Yes, it was a rebase - there are arguments all around on the right way to do these things, but since this is an experimental branch and a rebase into a new topic branch, rewriting history isn't much of an issue for me - although it does change the way those github merges look. There no risk in my fork, because @tobetter would redo it and not use mine anyway.

Note the odroidxu4-v4.2-rc6 branch @paralin has includes some additional commits not in this repository. The HEAD of hardkernel's odroidxu4-v4.2-rc1 branch should be merged with the upstream 4.2-rc7 kernel, then these additional commits from @paralin reapplied.

The decision also depends on how all the commits to odroidxu4-v4.2-rc1 got there. If they were all direct commits to this branch or cherrypicks from elsewhere (so the SHAs don't match source anyway), then rewriting history is less of an issue. I'm not sure how the Samsung commits (for example) got there.

If there's a master-like origin to the branch, then rewriting history is a problem, especially if it will be merged back in. If this is just a topic branch that will eventually become a master-like branch then rewriting history is often acceptable (and again, this is done in a new branch anyway).

As @tobetter points out, this puts all local branch commits on top of the official kernel tree which makes dealing with those patches that will eventually make their way into mainline Linux kernel a bit easier. That even makes the argument easier, in my mind, because this branch really is just experimental until those SOC/etc changes are in mainline. To clean that up will result in rewriting history eventually regardless of the approach used.

We have to remember this is a fork of the kernel, not the origin - so it's a bit different than commiting back into the official master. I don't know hardkernel's ultimate plans for this repository, and it's branches, or how much of this stuff will end up in mainline versus being just in the hardkernel or XU4 forks. Those decisions tie in to the best way to manage this repository.

If you still want to go down the rebase route, here's the basics on how to do it. In this case rebasing on the main kernel branch means that git unwinds all commits on the local branch until it gets to a common ancestor, then fast-forwards to HEAD of the official kernel. Then, it replays each of the commits to your local branch.

This assumes that a remote tracking repository to https://github.com/torvalds/linux exists and that it's called "upstream". This is from memory, so syntax may not be syntactically correct.

# Sync branches from upstream
$ git fetch upstream

# Checkout the branch that we wish to rebase
$ git checkout odroidxu4-v4.2-rc1

# Make sure git status is clean at this point or bad things will happen
$ git status

# Create our new target branch
$ git checkout -b odroidxu4-v4.2-rc7

# Now we start the rebase from upstream kernel
$ git rebase upstream/master

# Git will now unwind to a common ancestor, fast-forward to HEAD of upstream, then
# start applying each local commit. For conflicts (where git is unable to resolve a merge
# because a file was changed in both branches), that has to be iterated on. In this case,
# there's only one (r8152.c).

# For conflicts, chose a winner. This is somewhat confusing at this stage because "ours"
# mean mainline and "theirs" means the local branch during a rebase. I generally always
# use mergetool with meld, since it gives me a nice graphical way to see which one I want.

$ git mergetool

# For r8152.c, I took the new version from hardkernel's branch, not the one in the upstream kernel.

# Once merged, make sure git status is clean, may require git adding additional artifacts.

$ git status

# Now continue to the next iteration

$ git rebase --continue

# That's it! Except for pushing the new branch up.

# If things go bad, it's no harm since this is on a new branch and it's easy to reset:

$ git rebase --abort

That's the git rebase primer, and again I'll defer to hardkernel on how they wish to manage the repository. There's no one right way with git! :-)

update odroidxu4-4.2 to rc6 #126

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions