Mercurial: Merge two local repos - version-control

I'm using Mercurial with TortoiseHg on a Windwos host.
We have a central repository for the team and it must always be in a stable state.
Now I'm working on a feature with a colleague and we want to merge our work, without going via the central repository because our work isn't stable yet.
So we have a common ancestor, then we have individual commits to our local repos and we need to merge this work and test it, before pushing it to the central repo.
How do we do that?
As a an additonal difficulty, I'm working on Windows with TortoiseHg, while my colleague is on a Linux box. We're both only basic users of Hg, so apologies if this is a question with an evident solution. For me it isn't.

You can use named branches and create special named branch (pushed to central repo) for your WIP
You can use Mercurial in true DVCS-way:
Start embedded web-server on both sides hg serve in the Working Directory
Get URL of repo
Pull from remote side hg pull URL-OF-REMOTE-REPO

Related

After a github fork, how can I compare my branch to a branch in the upstream repo?

I was trying to compare changes I made to a forked repo.
To make this real, here is the example:
I forked https://github.com/springframeworkguru/sfg-di as https://github.com/steranka/udemy-sfg-di.
I got a local copy of the (forked) repo git clone git#github.com:steranka/udemy-sfg-di.git
I changed to the branch I wanted to work on git checkout property-source.
Made changes and committed the changes (to my local repo).
Push my changes to my fork so the changes can be compared to the original repo. git push
Now I want to compare my changes to the equivalent branch on the original repo.
The origin and upstream are set to:
origin: git#github.com:steranka/udemy-sfg-di.git
upstream: git#github.com:springframeworkguru/sfg-di.git
Searching for solution
My searches indicated that there was not a built in way to do this using the git CLI, nor the github website.
What I did find was:
https://stackoverflow.com/a/66613981/3281336. Basically do the compares via local repo.
How to compare a local Git branch with its remote branch - How to compare local vs remote branch. Later, I learned this is basically what a forked repo is... Just another remote.
General info about forks (from GitHub.com) https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests - The GitHub.com docs indicate that this is doable if you create a pull request. This is not what I want to do.
My question
How do you do this? I ran across gh-cli which might do it.
Can this be done via the github.com web interface? If so, how?
Append /compare to the URL of your repo. Example (try it):
https://github.com/mattneub/amperfy/compare
That's a public fork of a public upstream. You can select two branches, possibly at the two different repos, to see the diff.
I've selected the answer from Matt because that is the answer I was looking for. But another possible solution is based on #torek's answer.
The solution is to pull the upstream repo's branch that you want to compare locally and then do normal git diff commands. The result is that the compares are done via my local repo.
The steps to do this are:
Setup the pointers to the upstream (the repo you forked)
Get the upstream source and put it into your local repo
Compare the upstream source's (local copy) to your code.
The code commands to do this are:
git remote add upstream git#github.com:springframeworkguru/sfg-di.git
git fetch upstream property-source
git diff upstream/property-source..
This turned out to be simpler than I expected.
One benefit of this approach over the GITHUB web ui is I could compare my code changes without pushing my code to the github.

Using GitHub and Eclipse to pull code

I have a repo on GitHub here.
I have pushed to this repo from two different machines, so now one machine is current and another has outdated code. Right now, I am on the machine with outdated code, and I want to pull in the master/HEAD/whatever from GitHub.
And then I get to stare at this:
I do not want to do something stupid like delete the project from Eclipse and then pull in all the code from GitHub.
Can someone please help me merge/synchronize the projects? This is as simple as it sounds.
Unfortunately, this is what happens when I click "Pull" on the above menu:
Would someone also explain what the difference is between Pull, Merge, Fetch and Synchronize?
eGit doesn't know, which remote branch you want to pull from.
If you create your local branch based on a remote tracking branch, then the key is generated automatically. Otherwise you have to create it yourself:
branch.master.merge=refs/heads/master
branch.master.remote=origin
where master stands for the branchname, in the key it's your local branch, in the value it's the branch in the remote repository. Place that in the repository-specific configuration file %repositorypath%\.git\config
As for the terms:
merge: join two or more development histories together
fetch: download objects and refs from another repository
pull: fetch from and merge with another repository or local branch
sync: allows you to compare 2 branches
In general, I urge you to read eGit user guide, where you can get even better understanding of Git and eGit. It can be found at http://wiki.eclipse.org/EGit/User_Guide

setting up egit repos for team programming

I am trying to find out what would be the best way to set up egit repos for mutliple developers.
I found some arguments to set up independant repos for each developer and then the recommendation to merge the files by setting the respective external upstream repo to eg developer B in Eclipse of developer A so A can pull and merge with B. However A then needs to change the repo back to his own all the time. And switching upstream repos in the settings is quite cumbersome.
Alternatively all developers could work off the same repo in different braches - then merging would be easier since noone has to go to settings and change the upstream repo. On the other side this is also kind of "dangerous" since every developer is working on the same repo without restrictions (so I heard)
Which way is better in the long run?
In the long run, having one upstream repository is easier to manage.
Each developer can make their own branches locally.
They should agree on a common branch to push to though. It can be master, or a feature branch (if a few of them are collaborating to a specific feature).
The idea is, before each push, to pull --rebase that branch from the upstream repo in order to replay your local work (the commits you haven't pushed already) on top of upstream/branch (git pull --rebase will fetch and then rebase your local work on top of what has just been fetch).
That way, a developer will only push commits which will be merged on upstream as a fast-forward merge.
In EGit terms, that pull --rebase is configured when you create a tracking branch.
Rebase: When pulling, new changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be rebased onto the updated remote tracking branch

From github to bitbucket

Imagine situation like this:
You have a working repo in bitbucket - you were pulling revisions from another bitbucket repo in Windows 7 through TortioseHG.
Now the second project has moved to Github system and you can not pull from it anymore.
So my question is like this:
How can i somehow create new repo in bitbucket where I will pulling changes from github and from this repo i can easily pull in Tortiose HG to my working repo?
I do not want to use Github etc, so please do not advice it to me etc just help me with my question. Thank you.
The ideal solution consiste to keep local Mercurial repo, and work only with this local repo to the existing bitbucket Mercurial remote repo.
With a plugin like Hg-Git, you can at least push to and pull from a Git server repository from Mercurial, allowing you to pull from the GitHub repo to your local Mercurial repo.
From that local (Mercurial) repo, you can then work as usual with the bitbucket remote repo.
The OP adds:
It didn't work for me so i tried to transfer git repo to hg repo and from this repo pull to my working repo with changes - but it says that: abort: repository is unrelated - but I merged a lot from it. Any help here?
That makes senses, if both repos have been developed separately, you cannot push/pull 2 (mercurial) repos one into another.
This is confirmed at the bottom of the page "Understanding Mercurial", and detailed in the blog post: "What Mercurial Can't Do: Subtree Repos".
The more practical solution would be to make one extra repository (a "parent one") with your two repos declared in it as nested repository.
It would keep both repos independent, allowing to push back to the GitHub repo from your second mercurial repo.
If you don't have to push back to GitHub, but really want to have one repo in which you merge common files, then you can look in "Merge tip from an unrelated repository with Mercurial", but that is much more complex.
I would rather:
keep both repos separate
delete from the first one the common files you need to merge in the second one.
report and merge those common files in the second one.

Git/Mercurial locally ontop of local cvs checkout

I have read :
"Best practices for using git with CVS"
"How to export revision history from mercurial or git to cvs?"
, and neither suit my needs.
At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.
However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:
Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.
My plan is something along the following lines:
Copy the checked out files to another folder [gitRepo].
Create a master git repo in gitRepo
Branch in gitRepo and make changes.
Commit to gitRepo
Copy gitRepo back to checked out files
Sync with remote cvs.
I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.
Are there any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.
The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.
It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.
~Thanks for reading.
You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.
Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.
The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.
I have done exactly this at work and I found the following practices helpful:
Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.
When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!
You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.
Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.