Setup:
I have a client with a TFVC source control repository. The root is a folder, not a branch. Scattered throughout the hiearchy are branches, sometimes 2, sometimes 3 levels deep. For using git-tfs to migrate the repository, I need the root to be a branch. However, when I try to convert the root folder to a branch, I get this error:
You cannot create a branch at $/myProject because a branch already exists at $/myProject/Releases/7.3/Metadata.
If $/myProject/Releases/7.3/Metadata is not a branch convert it back to a folder and retry the operation.
Question:
Is there any impact to me "de-branching" some of those branches, turning them into regular folders, so that I can make the root a branch and then use git-tfs to migrate it? Could I possibly lose some of the history? Would I be risking corrupting the source control repository or losing any data? I'm trying to be very careful with the client's source code and not risk losing any data.
Thanks!
Update:
My justification for thinking I need to convert the root to a branch:
* When created a simple test repository to try out the migration, and ran this command
git tfs list-remote-branches https://mysite.visualstudio.com/
I got this message
"No TFS branches were found!"
And on this github issue, it said I should switch to a branch, then I would see it and that worked. So I assumed the clone wouldn't work since it didn't show up in the list. Also, with the similarly structured test repo, when I ran git tfs list-remote-branches, I got:
TFS branches that could be cloned:
$/myproject1/Releases/7.1/Metadata [*]
$/myproject1/Releases/7.2/Metadata [*]
$/myproject1/Releases/7.3/Metadata [*]
$/myproject1/Trunk/Main [*]
Cloning root branches (marked by [*]) is recommended!
PS:if your branch is not listed here, perhaps you should convert its
containing folder into a branch in TFS: -> Open 'Source Control
Explorer' and for each folder corresponding to a branch, right click
on the folder and select 'Branching and Merging' > 'Convert to
branch'.
Based on that, I thought I had to convert it to a branch.
The next command I ran was
git-tfs clone https://mysite.visualstudio.com/ $/myproject1
I thought this gave me an error when the root was a folder, but it just gave me a warning when I reran it just now. The folder structure was something like
folder/folder/branch
folder/folder/folder/branch/folder
etc
warning: you are going to clone the whole repository or too high in
the repository path ! => If you want to manage branches with
git-tfs, clone one of this branch instead :
- $/myproject1/Releases/7.1/Metadata
- $/myproject1/Releases/7.2/Metadata
So it looks like the reponses are right. You can clone off the root without a problem. Thanks!
Don't convert your branch to a folder.
What does the following command tell you to clone?
git tfs list-remote-branches http://tfs:8080/tfs
A doc on the subject :
https://github.com/git-tfs/git-tfs/blob/master/doc/usecases/manage_tfs_branches.md#find-the-tfs-branch-to-clone-optional
Edit: git-tfs is able to clone every folders in a TFVC Collection but if you want to clone the history with the branches, each folder should be converted as a branch.
Related
I use github desktop (https://desktop.github.com ) while developing the application with several other people, so, for some reason, when trying to merge two branches into one, the error "unable to merge unrelated histories" is displayed for one of the target branches.
What could be the problem?
First of all: You may also be able to find a solution using the search.
Potential reasons for the error message
From: https://komodor.com/learn/how-to-fix-fatal-refusing-to-merge-unrelated-histories-error
Here are some common scenarios where fatal: refusing to merge unrelated histories can occur.
You have a new Git repository with some commits. You then try to pull from an existing remote repo. The merge becomes incompatible because the histories for branch and remote pull are different. Git sees the situation as you trying to merge two completely unrelated branches, and it doesn’t know what to do.
There’s something wrong with the .git directory. It may have been accidentally deleted at some point or got corrupted. This can happen if you’ve cloned or cleaned a project. Here the error occurs because Git doesn’t have the necessary information about your local project’s history.
The branches are at different HEAD positions when you try to push or pull data from a remote repo and cannot be matched due to a lack of commonality.
Options to resolve the issue
The article describes two options on how to resolve/avoid such issues but targets command line /terminal users. I guess I would prefer option 2 over option 1 anyway, also using git in the terminal.
The article explains it like this:
The alternative (and longer) way of fixing refusing to merge unrelated histories issues is to unstage your current commits, stash them, clone your required remote repository, and then place your stashed branch contents into the new clone. This will ensure that any conflicts that you may encounter in the code are addressed before merging and prevent application errors from occurring.
How it (should) work in GitHub Desktop
In GitHub Desktop you should be able to use a modified version of option 2:
To unstage all the files in your last commit, double click staged files. This moves them to the unstaged area. Learn more in this GitHub issue.
To stash your unsaved files, right-click an unstaged file. Learn more about stashing files.
This will give you a clean working tree to pull your remote repository into. Once you’ve successfully pulled into your branch, you can:
unstash your files (see link above again) to reapply them to your current working copy.
commit them as a separate commit.
resolve any file conflicts that you may have.
I hope this explanation adds some clarity. Let me know if there are any wrong or misleading information in my text please.
This problem has several reasons.
But probably your project clone just differs from GitHub (main project).
First of all, save your project (because you probably don't want to code everything again).
Remove repo from GitHub desktop (not GitHub!!!)
Go to the project page in GitHub
Click code, open with GitHub Desktop, and code again.
The case:
Locally, I have a commit where I have deleted a file. Remotely, someone else have changed this file.
Now, when I merge, I find that git has the put the changed file in my working tree. This is probably the way git works, and in git command line, I'd be able to use git mergetool to choose between the deleted or changed file.
In eGit, however, how would I make this choice?
We ended up with a quite unusable work-around where we first addded the file to the index and then deleted it in working tree and then saved this change (deletion) to the index.
Technical info:
The version of eGit (feature) we're using is 4.9.2.201712150930-r.
The version of git we're using is 2.16.1
Background:
My team have recently moved to using Git as our revision control system. There's a general wish from team members to use an integrated solution and since we're working with Eclipse, eGit seemed to be the way to go.
I would suggest that all your team members follow this process:
Commit your changes to your local repository.
Pull with rebase to merge with the remote origin branch.
Resolve the conflicts, if any. In your case, if you deleted the file before the other team member modified it, then that person would have noticed that the file has been deleted.
Push the commit upstream.
This process has worked for us. Hope this helps.
I've got an ARM project in Eclipse...Actually, I'm using the STM Workbench packaging of Base-CDT-Eclipse.
I'm working with a few other guys and we're using a git server to push and pull from.
However, everyone has a little bit different setup as far as where their toolchains are, OS's, etc.
This is causing trouble, because we're git dummies, and when we push changes after working locally, we do
git add .
git commit -m "some message"
git push origin master
And when we pull changes, we just do
git pull origin master
And pray that there no one else did anything in the meantime, because we're afraid of merging differences, but that's a different story.
Anyway, this whole project has a few sub directories that include things like datasheets, Word documents, and what-not...but, it also includes the metadata for the Eclipse project. So, the last person to commit also pushes their unique settings for things like tool-chain path, preferred builder, etc. This breaks the other guys' setup and after each pull, everyone else has to manually update their project settings to fix this.
So, what files are special to Eclipse for project settings and how can I tell git to ignore these files if they already exist? They need to be available for, say, a git clone but they need to be ignored for subsequent git push's and git pull's.
If you need the setting file and not rename it and it's ok forsetting file need not to do version control, so there is a way by .gitignore with below steps:
Create a .gitignore file. touch .gitignore
Edit and save the .gitignore file
.gitignore
filename
Remove the caches from version control. git rm --cached filename
Commit and push
You can ignore those files changes locally with:
git update-index --skip-worktree -- .project
git update-index --skip-worktree -- .classpath
See: "Difference Between 'assume-unchanged' and 'skip-worktree'", it should better resist to git pull.
Another option would be to a content filter driver which generates (automatically on git checkout) a .classpath if it does not yet exist.
That allows you to version a .classpath.tpl template, and you can keep your actual .classpath completely private (and in your .gitignore)
See this answer for more.
I was recently tasked with creating a branching plan for our project, and part of that involved creating a few feature branches and release branches. I also had to clean up the source control tree so that the branches could be self contained. I basically started with this:
/
./src
./model
./processtemplates
./data
./otherfolders
I changed the structure to this:
/
./trunk
./src
./model
./data
./branches
./v1
./release1
./src
./model
./data
./release2
The problem is, I need to create a branch from a specific previous version, but the folder structure has changed, so I can't get that changeset for the /trunk folder to create a branch from. The exact error message I get is: "No matching items found in $/ at the specified version."
What's the best way to do this? I have though of creating a branch from the latest changeset and reverting all of the changes back to the older changeset. I was hoping there was an easier way.
Renames and deletes are dangerous territory in TFS 2008. You'll probably have to go to the command-line to do this. Take a look at your history to figure out the changeset from which you want to branch, then do the following at the command line:
mkdir c:\BranchFolder
cd c:\BranchFolder
tf.exe workspace /new /s:http://tfs:8080 BranchWorkspace
tf.exe workfold /map:"$/","C:\BranchFolder"
tf.exe branch "$/" "$/branches/v999" /version:Cxxxxxx /noget /noprompt
Validate and check in.
tf.exe workspace /delete BranchWorkspace
replace v999 with whatever folder you want to branch into, and change xxxxxx to the appropriate changeset number.
As always-- when you are working in these kinds of areas where you aren't quite sure what the results are going to be, check your work before checking in.
I want to use Bazaar on Windows XP for web-development and related tasks. Most of the files are edited locally and then transferred via FTP to the server. Just now the repository sits on my local workstation. Later on it should be shared locally with some co-workers. Perhaps we will use a local Linux server as a centralized repository, but this structure is not decided for now. But first I need to understand the impacts of the different repository setups, which I do not at all.
Using Bazaar-Explorer on Windows XP I’ve created a ‘shared tree repository’ from the option list of the init-dialogue in some location dev-filter/. Bazaar Explorer tells me:
Created repository with treeless branches at F:/bzr.local/dev-filter
Created branch at F:/bzr.local/dev-filter/trunk
Created working tree at F:/bzr.local/dev-filter/work
OK so far. Now I move a bunch of files into the work directory and add and commit them as Rev 1 ‘Start Revision’. Then I work on some of these files and commit them again as Rev 2. Here my confusion starts. Shouldn’t both revisions go into the trunk? The trunk is still empty, beside the .bzr directory which only holds some management information. If I delete my working directory, which I have tried during these first experiments, everything is gone. There’s obviously no hidden storage of those files.
OK. Perhaps I need to push it into the trunk? This does not work either. Entering the work/ directory and initializing the ‘push’ to the trunk, Bazaar-Explorer tells me
No new revisions to push.
So what? This looks like a severe conceptual misunderstanding about what should happen on my side.
Edit, 2010-02-03: Some conclusions
What I learned meanwhile is this:
I think I should switch to the command line until I really understand what’s going on, at least for creating the repositories and branches. Bazaar Explorer introduces a new level of abstraction which I only can handle if I understand the level beneath
One of the secrets of working with Bazaar at least for me is to understand those .bzr directories, their particular properties and states when created with ‘bzr init’, ‘bzr init-repository’, ‘bzr branch’ etc. in all their variants and how they are plumped together.
While there’s a whole chapter of ‘Organizing your workspace’ in the Bazaar User Guide, it’s more or less workflow oriented. The manual contains a lot of directory structures for the given examples. What I would prefer beside this and have not (or only rudimentary) found so far is some graphical representation of those ‘Lego like’ .bzr building blocks which create the linking of all the parts. So I started to invent some simple notation while working through the examples and looking into the .bzr directories to document what information is stored there, where does it come from, how and to what is it linked, is it complete or shared, etc.
Erich Schreiber
Created repository with treeless
branches at F:/bzr.local/dev-filter
This part of the output looks suspicious to me. Are you sure you chose 'Shared repository' and not 'Shared repository with treeless branches' from the init dialog?
Treeless Branches are branches without the working tree, if you indeed created a treeless branch for trunk then it makes sense that there are no files there.
Your changes are still saved in the F:/bzr.local/dev-filter/trunk/.bzr, and have indeed been committed there. You don't see those changes reflected in the file system because Bazaar has created trunk as a treeless branch, with `` as a lightweight checkout. See checkouts in the Bazaar User Reference.
If you open F:/bzr.local/dev-filter/trunk in Bazaar Explorer, you should see your revisions. If you create a new branch with a working tree or checkout based on trunk, Bazaar will create the files with your changes for you.
typically it goes like this.
bzr init-repo --no-trees F:/bzr.local/dev-filter
cd F:/bzr.local/dev-filter
bzr init trunk
bzr branch trunk work
---all above will not create any tree
Now in new directory say F:\temp
cd F:\temp
bzr checkout F:/bzr.local/dev-filter/work
bzr add
bzr commit
---back to F:/bzr.local/dev-filter/work
cd F:/bzr.local/dev-filter/work
bzr push F:/bzr.local/dev-filter/trunk