2

I'm looking for a simple way to pull in additional commits after rebasing or a good reason to tell someone not to rebase.

Essentially we have a project, crons. I make changes to this frequently, and the maintainer of the project pulls in changes when I request it and rebases every time.

This is usually okay, but it can lead to problems in two scenarios:

  • Releasing from two branches simultaneously
  • Having to release an additional commit afterwards.

For example, I commit revision 1000. Maintainer pulls and rebases to create revision 1000', but at around the same time I realize a horrible mistake and create revision 1001 (child of 1000). Since 1000 doesn't exist in the target branch, this creates an unusable merge, and the maintainer usually laughs at me and tells me to try again (which requires me getting a fresh checkout of the main branch at 1000' and creating and importing a patch manually from the other checkout). I'm sure you can see how the same problem could occur with me trying to release from two separate branches simultaneously as well.

Anyway, once the main branch has 1000', is there anything that can be done to pull in 1001 without having to merge the same changes again? Or does rebasing ruin this? Regardless is there anything I can say to get Maintainer to stop rebasing? Is he using it incorrectly?

Improve this question

1 Answer 1

Reset to default
4

Tell your maintainer to stop being a jacka**.

Rebasing is something that should only be done by you, the one that created the changesets you want to rebase, and not done to changesets that are:

  • already shared with someone else
  • gotten from someone else

Your maintainer probably wants a non-distributed version control system, like Subversion, where changesets follows a straight line, instead of the branchy nature of a DVCS. In that respect, the choice of Mercurial is wrong, or the usage of Mercurial is wrong.

Also note that rebasing is one way of changing history, and since Mercurial discourages that (changing history), rebasing is only available as an extension, not available "out of the box" of a vanilla Mercurial configuration.

So to answer your question: No, since your maintainer insists on breaking the nature of a DVCS, the tools will fight against you (and him), and you're going to have a hard time getting the tools to cooperate with you.

Tell your maintainer to embrace how a DVCS really works. Now, he may still insist on not accepting new branches or heads in his repository, and insist on you pulling and merging before pushing back a single head to his repository, but that's OK.

Rebasing shared changesets, however, is not.

If you really want to use rebasing, the correct way to do it is like this:

  1. You pull the latest changes from some source repository
  2. You commit a lot of changesets locally, fixing bugs, adding new features, whatnot
  3. You then try to push, gets told that this will create new heads in the target repository. This tells you that there are new changesets in the target repository that you did not get when you last pulled, because they have been added after that
  4. Instead, you pull, this will add a new head in your local repository. Now you have the head that was created from your new changesets, and the head that was retrieved from the source repository created by others.
  5. You then rebase your changesets on top of the ones you got from the source repository, in essence moving your changesets in the history to appear that you started your work from the latest changeset in the current source repository
  6. You then attempt a new push, succeeding

The end result is that the target repository, and your own repository, will have a more linear changeset history, instead of a branch and then a merge.

However, since multiple branches is perfectly fine in a DVCS, you don't have to go through all of this. You can just merge, and continue working. This is how a DVCS is supposed to work. Rebasing is just an extra tool you can use if you really want to.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I personally don't understand why you would ever want to rebase .. you're just destroying history (and the whole point of the VCS is to have the history for you to look at)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.