git: Pushing Single Commits, Reordering with rebase, Duplicate Commits

Question

I want to push several single commits to a git remote repo. I followed Geoff\'s answer found here to do so:

How can I pushing specific commit to a remote, and not th

Answer 1

The short answer is that rebase does not change commits,¹ but rather copies them. Git normally then hides away the originals, but if your originals include those shared by other users, you (and of course they) and still see those originals.

As a general rule, you should only rebase your own private, unpublished commits. Since no one else has a copy of these by definition, the fact that you make your own copies and then (via rebase) hide away your originals is not a problem: you now see your copies instead of your originals, and no one else sees either, and you can continue to rebase if needed. As soon as you publish (via push or similar) a commit, though, you can no longer change it, because someone else now has a copy of your original, including its SHA-1 ID, and they will still have it later.

What you've done in this case is to rebase (i.e., copy) their commits as well as your own. Part of the problem stems from using git pull, which means "fetch then merge", when what you wanted was "fetch then rebase". You can either do the steps separately:

git fetch
git rebase

or use git pull --rebase:

git pull --rebase

which tells the pull script that after doing the fetch, it should do a rebase instead of a merge. You can also configure git to do this automatically, without the --rebase argument.²

The main problem right now is that you have a merge you probably didn't want. If so, you will need to "undo" that merge (with git reset; see other stackoverflow postings).

---

¹It can't: a git object, including a commit, is named by its object ID, which is a crypographic checksum of its contents. A commit is comprised of its parent ID(s), the ID of the tree, the commit's author and committer (name, email, and timestamp), and the commit message. If you change any of these, you get a new, different commit with a different ID.

²You can even configure it to use git pull --rebase=preserve. However, preserving merges across rebase operations is a separate topic (which I've covered somewhat before in stackoverflow postings).