Is there a way to associate a bunch of Mercurial changesets with a named branch after they have been committed, i.e. retroactively ?
相关问题
- Correct procedure to use pending branch changes in
- Mercurial compared to private branches in SVN
- How to abandon all Mercurial changes that haven
- Windows permissions on a directory: Mercurial - hg
- hg shelve installed but hg: unknown command 'u
相关文章
- Mercurial Commit Charts / Graphs [closed]
- What is the tortoisehg gui equivalent of doing “hg
- How to use Mercurial from Visual Studio 2010?
- Is there a version control system abstraction for
- Tag multiple branches in git?
- Mercurial discard local changes of a file or group
- Mercurial .hgignore Negative Lookahead
- Switch node_modules folder when I change git branc
No, branch names are part of the changeset (it's really like a label you add to the commit), it means the changeset hash depens on the branch name.
So the only way to change it retroactively is by rewriting history (which doesn't play well if you pushed your changes elsewhere, since you'll have to rewrite every repo which has the changes).
To rewrite history, you could use for example mq.
I just wanted to do this, and here’s the solution I found. A year has passed since the question was originally asked, this might explain why I can now find a solution. It has the disadvantage that you create an extra revision in the process, but this wasn’t too bad for me.
First, you go back to where you want to create the branch. In my case, I actually wanted to start a new root (because I wasn’t very sensible when I started the repository, but anyways), so I’m updating to null. You probably want to start somewhere else, it depends on your situation.
Then, create the branch.
Then, we rebase all the commits we made onto our new branch:
The SOURCE here should be the first commit you made in the commits you want to create the branch from, and the DEST should be the commit where the branch was created (the one we committed above).
Not a complete solution but, without re-writing history; you could tag the last change set in the unnamed branch. If you never rebranch from this the tag should surfice. If you do need to rebranch you can move on to a named branch after the tagged changeset.