For the first issue, you can find in git-fetch(1):

The remote ref that matches src is fetched, and if dst is not empty string, the local ref that matches it is fast-forwarded using src. If the optional plus + is used, the local ref is updated even if it does not result in a fast-forward update.

So something like

  fetch = +refs/heads/*:refs/remotes/munnich/*

should just overwrite the master branch. (And yes, the git reset is how I'd do it manually...)

Finally, git clone --mirror should make a 1:1 copy, but it also forces a bare repo which probably is not what you want...

All my repos seem to already be set up with the optional + on their 'fetch =' bit. I think the issue is that this just updates the local ref, ie origin/master, but doesn't update my local branch (plain master) or check out the updated branch.

Christian:

Well… that fetch pattern is already the default configuration for any remotes you add. Did I misunderstand what you’re talking about, or did you misunderstand Chris? My understanding of what Chris said is that he wants his local master to always be the same the as the remote master. You seem to be talking about remote tracking branches. The default for those is already to always reflect the remote, regardless of whether an update was a fast-forward or not.

Chris:

Yes, git reset --hard origin/master would be the “obvious” way of going about that. Though your git checkout -f -B master origin/master has almost exactly the same effect, now that I look at it. (I never thought of doing it that way. Probably because the -B switch didn’t exist for a long time and git reset was the only way of doing that.) The only difference is that it will (or might) re-setup the branch on every reset, though most of the time that is a no-op.

Note that if origin/master is set as the upstream branch for master, you can refer to it as @{u}, i.e. git reset --hard @{u}, which is shorter and generalises to any branch.

Regarding case 2 – hey, you taught me something. 😊 I never thought of using git cherry-pick for anything. My approach would have been something along the lines of

git branch tmp master
git rebase -onto darktable-2.0.x origin/master tmp
git checkout -B darktable-2.0.x
git branch -D tmp

which is way more cumbersome, owing to the difference between rebasing and cherry-picking – that rebasing tries to manage the head of your branch for you. This is a case where you don’t want that.

For the case of two upstream repositories for rc – I’m not sure I understand exactly what you want to achieve. Did you just want to temporarily switch over to @muennich’s fork completely…? You didn’t add a remote for it, so I assume the answer is no… but then it seems to me the same cherry-picking approach would also work? What is your goal here, and what your particular confusion/problem?

As for the last case… yes, my StackOverflow answer covers exactly that scenario. Basically, before you fetch (because fetching force-updates branches by default, as mentioned), make a throw-away branch to record the state of the remote branch you care about, so you can use the three-argument for of git rebase --onto without scanning logs and copy-pasting commit hashes… and then do that.

Aristotle: for the two upstream repositories for rc case, what I wanted to do was wind up with a repo that at least temporarily switched over to @muennich's fork. My actual approach was a hack, but I think the correct way is to add it as a remote and a branch, something like:

git remote add muennich https://github.com/muennich/rc
git pull muennich
git checkout -b muennich muennich/master

Then I'd either cherry-pick or rebase my local commits from master to the muennich branch. A cherry-pick would be just the same as the darktable case; a rebase would be following your example for the darktable case:

git rebase --onto muennich origin/master master

(I tested it and this appears to work. I'm not clear why you created a tmp branch then deleted it, so maybe I'm missing something.)

I may have misunderstood, but my understanding of your situation was that you have some local commits on top of origin/master, and now you wanted the same commits copied to darktable-2.0.x on top of origin/darktable-2.0.x – without removing them from your master.

In that case, your git cherry-pick approach precisely expresses the outcome you want.

I would not have thought to do it that way myself, and would have reached for git rebase instead. In that case the tmp branch is necessary because git rebase is the wrong tool for the job. Namely if you just say

git rebase -onto darktable-2.0.x origin/master master

then that will not just replay your local commits onto darktable-2.0.x, it will also update master to the tip of the newly created commit series, making master branch off of darktable-2.0.x instead of origin/master. That’s not what you wanted. But since git rebase insists on updating a branch, you need a sacrificial branch to offer it. And since it updates that branch, you have fast-forward your darktable-2.0.x branch to it yourself.

So my way of achieving what you wanted would have been rather roundabout, whereas yours was just right.

Now as for muennich/rc – you say you wanted to switch over, in which case that git rebase command exactly expresses that. (For the same reason – it re-points your master to the newly created commits.)

That tmp branch is only necessary if you don’t want to switch over, but rather want to have a copy of your local commits on both branches, and you’re me and don’t realise that git cherry-pick will give you that directly.

So we’ve gone over all your scenarios, and you should be all covered now.

Some minor notes on that last one: you don’t necessarily need a local muennich branch at all, you can just say

git rebase --onto muennich/master origin/master master

And you should probably follow up the rebase with

git branch -u muennich/master master

which makes muennich/master your master’s new upstream. Then git pull --rebase will Just Work for example. (You can always change it back in the same way if you decide to switch back.)

Ah! I somehow missed that the git rebase updated where master pointed, not my muennich branch. So either I should change the upstream of master afterwards or I should use a temporary branch. For what I want to do, probably using a temporary branch would be the right answer with git rebase. But probably the really right answer here is to cherry-pick instead, since that's simpler.

I guess this makes sense for one view of what rebase is doing, namely moving commits instead of just copying them. What I usually want to do here is probably more copying commits instead of moving them, since I wouldn't mind having my old 'based on the master' version around too.

(Copying commits is definitely what I want in the darktable case, since at some point I'll go back to the development version when it settles down.)