I’d advise against it for the reasons stated above, but more strenuously stated. Both mercurial and git have their own protocols for moving changesets between repositories. These protocols are optimized/built for: efficiency consistency (never can you pull from a repo in a half-updated state) hooks/triggers — doing things on push/pull including quality (no tabs allowed, … Read more
VonC has the answer you’re looking for, the Rebase Extension. It is, however, worth spending a second or two thinking about why neither mq nor rebase are enabled by default in mercurial: because mercurial is all about indelible changesets. When I work in the manner you’re describing, which is nearly daily, here’s the pattern I … Read more
Here’s what I’d do: Make default your “mainline” branch. The tip of this branch is the “currently released to the public” version of your code. Critical bugfixes can be committed directly to this branch and merged into development branches. To start working on version 2.0, make a 2.0-dev branch. Commit changes for 2.0 to that … Read more
The page at http://wiki.debuntu.org/wiki/OpenSSL#Retrieving_certificate_informations lists the command lines for that (and printing out the relevant information). From that page and some of the man pages, it seems like what you want is (for bash): openssl s_client -connect <host>:<port> < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin If you want the whole certificate, leave … Read more
It’s been almost 2 years since I originally posed this question. I’d do it differently now (as I mentioned in a comment above the question above). What I’d do now would be to instead commit my changes to the one file in my local repo (you can use the hg record extension to only commit … Read more
Git is very fast, scales very well, and is very transparent about its concepts. The down side of this is that it has a relatively steep learning curve. A Win32 port is available, but not quite a first-class citizen. Git exposes hashes as version numbers to users; this provides guarantees (in that a single hash … Read more
Update your repository to the head with the revision that you want to forget about, then use hg commit –close-branch to mark that (anonymous) branch as closed. Then update to the head of the branch that you do want, and continue working. You can still see the closed branch if you use the -c option … Read more
Enable the “strip” extension and type the following: hg strip #changeset# –keep Where #changeset# is the hash for the changeset you want to remove. This will remove the said changeset including changesets that descend from it and will leave your working directory untouched. If you wish to also revert your committed code changes remove the … Read more
Update: Mercurial has added –amend which should be the preferred option now. You can rollback the last commit (but only the last one) with hg rollback and then reapply it. Important: this permanently removes the latest commit (or pull). So if you’ve done a hg update that commit is no longer in your working directory … Read more
You could use the Timestamp extension, if creating new “reference” timestamps will not be a problem. From its website: It does this by means of a database file .hgtimestamp, residing in the repo’s root and thus being versioned. Other than this, I don’t think it’s possible. I’ve read a little about Timestamp hook, and it … Read more