![]() ![]() You’re working in your local repository, and there have already been a few commits that you’ve pulled in from the central repository (two, in the screenshot below). How We End Up in This Situation (or, “It’s All Bob’s Fault”) If you’re not 100% confident that a rebase will succeed, choose to “Keep original changesets”.If a commit is in the central repository, it’s off limits. Never, ever rewrite history that’s been shared with others.It’s possible to seriously harm yourself or others if you’re not careful while driving. This shouldn’t scare you away, but it should make you pay attention to what you’re doing. If you don’t know what you’re doing, it’s possible to unrecoverably lose your changes or otherwise seriously screw-up your team’s repository. You’re re-writing history in your repository. My hope is that this post will make it easier for teams with varying levels of technical savvy to collaborate while keeping their repository history easy to read.īefore going down this path, let me emphasize that performing a rebase is not risk-free. However, the command line can be a scary place for the uninitiated. Of course, it’s possible to rebase from the command line. This tutorial will show you how to perform a rebase in a Mercurial repository using TortoiseHg. Rebasing lets you take a repository that looks like this… ![]() ![]() The goal of this post is to show you how to resolve the same situation by performing a rebase, which will help keep your repository history neat and tidy. It’s very common to resolve this problem by performing a merge. This creates a fork in your repository path (called an “anonymous branch”, for reasons I’ll explain later) that needs to be resolved before you can push your changes. (Let’s sidestep the debates about whether or not that’s a good idea, and just recognize that it’s a common practice.)įor teams working this way, it’s common that you try and push your recent changes to the central repository, only to find that someone else has beaten you to the punch. When working with a distributed verion control system like Mercurial or Git, some teams choose to have multiple developers work on the same branch. I assume you have TortoiseHg installed, and have a basic working knowledge of Mercurial including pushing, pulling, and merging. Rebasing your commits, instead of merging, can help keep your Mercurial history much easier to follow, with fewer “merge polygons” in your commit graph. If you have set up Issue Tracking for a different bug-tracking database than FogBugz, please leave a comment below with your Issue Regex and Issue Link for the benefit of others.This post demonstrates performing a “rebase” on your Mercurial repository using TortoiseHg. I wrote an in-depth explainer for that website here:. If you are having trouble getting your regular expression to work, I highly recommend for debugging purposes. FogBugz wiki article URLs are similar, except that you need to include the literal "W" in the query parameter. Since the original regex had a pipe character (i.e., either-or operator) separating two different regexes, only one of the two capturing groups will ever match.įogBugz cases can be looked up by simply passing the case number as the sole URL query parameter after your customer subdomain. In the example above, I use the following Issue Regex: (?i)FB\s: the second capture group from above Set Issue Link to a URL that references the capture group(s) from above. ![]()
0 Comments
Leave a Reply. |