git command for making one branch like another

You could merge your upstream branch to your dev branch, with a custom merge driver "keepTheirs":
See "“git merge -s theirs” needed — but I know it doesn't exist".
In your case, only one .gitattributes would be required, and a keepTheirs script like:

mv -f $3 $2exit 0

git merge --strategy=theirs Simulation #1

Shows as a merge, with upstream as the first parent.

Jefromi mentions (in the comments) the merge -s ours, by merging your work on the upstream (or on a temp branch starting from upstream), and then fast-forwarding your branch to the result of that merge:

git checkout -b tmp origin/upstreamgit merge -s ours downstream         # ignoring all changes from downstreamgit checkout downstreamgit merge tmp                        # fast-forward to tmp HEADgit branch -D tmp                    # deleting tmp

This has the benefit of recording the upstream ancestor as the first parent, so that the merge means "absorb this out-of-date topic branch" rather than "destroy this topic branch and replace it with upstream".

(Edit 2011):

This workflow has been reported in this blog post by the OP:

Why do I want this again?

As long as my repo had nothing to do with the public version, this was all fine, but since now I'd want the ability to collorate on WIP with other team members and outside contributors, I want to make sure that my public branches are reliable for others to branch off and pull from, i.e. no more rebase and reset on things I've pushed to the remote backup, since it's now on GitHub and public.

So that leaves me with how I should proceed.
99% of the time my copy will go into the upstream master, so I want to work my master and push into upstream most of the time.
But every once in a while, what I have in wip will get invalidated by what goes into upstream and I will abandon some part of my wip.
At that point I want to bring my master back in sync with upstream, but not destroy any commit points on my publicly pushed master. I.e. i want a merge with upstream that ends up with the changeset that make my copy identical to upstream.
And that's what git merge --strategy=theirs should do.

git merge --strategy=theirs Simulation #2

Shows as a merge, with ours as the first parent.

(proposed by jcwenger)

git checkout -b tmp upstreamgit merge -s ours thebranch         # ignoring all changes from downstreamgit checkout downstreamgit merge --squash tmp               # apply changes from tmp but not as merge.git rev-parse upstream > .git/MERGE_HEAD #record upstream 2nd merge headgit commit -m "rebaselined thebranch from upstream" # make the commit.git branch -D tmp                    # deleting tmp

git merge --strategy=theirs Simulation #3

This blog post mentions:

git merge -s ours ref-to-be-mergedgit diff --binary ref-to-be-merged | git apply -R --indexgit commit -F .git/COMMIT_EDITMSG --amend

sometimes you do want to do this, and not because you have "crap" in your history, but perhaps because you want to change the baseline for development in a public repository where rebasing should be avoided.

git merge --strategy=theirs Simulation #4

(same blog post)

Alternatively, if you want to keep the local upstream branches fast-forwardable, a potential compromise is to work with the understanding that for sid/unstable, the upstream branch can from time to time be reset/rebased (based on events that are ultimately out of your control on the upstream project's side).
This isn't a big deal and working with that assumption means that it's easy to keep the local upstream branch in a state where it only takes fast-forward updates.

git branch -m upstream-unstable upstream-unstable-savegit branch upstream-unstable upstream-remote/mastergit merge -s ours upstream-unstablegit diff --binary ref-to-be-merged | git apply -R --index --exclude="debian/*"git commit -F .git/COMMIT_EDITMSG --amend

git merge --strategy=theirs Simulation #5

(proposed by Barak A. Pearlmutter):

git checkout MINEgit merge --no-commit -s ours HERSgit rm -rf .git checkout HERS -- .git checkout MINE -- debian # or whatever, as appropriategit gui # edit commit message & click commit button

git merge --strategy=theirs Simulation #6

(proposed by the same Michael Gebetsroither):

Michael Gebetsroither chimed in, claiming I was "cheating" ;) and gave another solution with lower-level plumbing commands:

(it wouldn't be git if it wouldn't be possible with git only commands, everything in git with diff/patch/apply isn't a real solution ;).

# get the contents of another branchgit read-tree -u --reset <ID># selectivly merge subdirectories# e.g superseed upstream source with that from another branchgit merge -s ours --no-commit other_upstreamgit read-tree --reset -u other_upstream     # or use --prefix=foo/git checkout HEAD -- debian/git checkout HEAD -- .gitignoregit commit -m 'superseed upstream source' -a

git merge --strategy=theirs Simulation #7

The necessary steps can be described as:

1. Replace your worktree with upstream
2. Apply the changes to the index
3. Add upstream as the second parent
4. Commit

The command git read-tree overwrites the index with a different tree, accomplishing the second step, and has flags to update the work tree, accomplishing the first step. When committing, git uses the SHA1 in .git/MERGE_HEAD as the second parent, so we can populate this to create a merge commit. Therefore, this can be accomplished with:

git read-tree -u --reset upstream                 # update files and stage changesgit rev-parse upstream > .git/MERGE_HEAD          # setup merge commitgit commit -m "Merge branch 'upstream' into mine" # commit

It sounds to me like you just need to do:

$ git reset --hard origin/master

If there is no change to push upstream, and you simply want the upstream branch to be your current branch, this will do that. It is not harmful to do this locally but you will lose any local changes** that haven't been pushed to master.

** Actually the changes are still around if you have committed them locally, as the commits will still be in your git reflog, usually for at least 30 days.

You can do this rather easily now:

$ git fetch origin$ git merge origin/master -s recursive -Xtheirs

This gets your local repo in-sync with the origin, and preserves the history.