Consider the following scenario:
Some content (e.g. a web-site) is under git repository having several branches like master (for dev), qa and prod.
A .net application (e.g. some cloud service) needs to have always the latest version of one specific branch (e.g. prod). There is no need to fetch full repository, only HEAD of this branch (git clone -b <branch> --depth=1 <remote_repo_url> --single-branch) and perform consequent updates.
How would you implement such scenario with libgit2sharp library?
Cloning only a truncated portion of the history from a repository (ie. shallow cloning) is not supported by LibGit2Sharp yet.
You can subscribe to issue #229 to be notified of future progress.
Related
we have an local DevOps Server 2019 with our old projects and I am able to clone this projects with git-tfs to local Git repositories. Everything is fine. After that I can push this repositories to our AzureDevOps Git repositories. Everything ok.
Now we have some projects and colleagues who want to use TFVC for these special projects. So my idea was to clone these projects from local TFS to Git and then use git-tfs rcheckin to push it to our AzureDevOps project.
But when I use "git-fts rcheckin --remote azuretfs" I get "error: latest TFS commit should be parent of commits being checked in"
When I use "git-tfs checin --remote azuretfs" all files are uploaded to the AzureDevOps project but without the history.
So can anyone describe what I have to do?
Note: I don't want to use the MigrationTool offered by Microsoft because of to many erros during validation the templates of work items etc. (we dont use it...)
For those who are looking for the same:
With the 'old' git tf tool (https://archive.codeplex.com/?p=gittf) you can migrate old TFVC project to Azure DevOps(TVFC).
If you want to migrate old TFVC projects to AzureDevOps(GIT) you should use git tfs (http://git-tfs.com/)
What you could try without guarantee of success...
Note: As I said, you will be able to migrate the history from one branch only.
Create the folder/project in TFVC where you want to put the source code.
Migrate this folder with git tfs clone (to have a git commit with the git-tfs metadata required to rcheckin)
Add the already migrated history repo (let's call it RepoWithHistory) as a local remote in this new repository (let's call it NewRepo). And git fetch
Clean metadata for only the commit coming from RepoWithHistory with something looking like: git filter-branch -f --msg-filter "sed 's/^git-tfs-id:.*$//g'" -- --all. But be careful to keep the metadata on the commits coming from NewRepo.
Use git replace --graft <sha1_of_first_commit_of_RepoWithHistory> <sha1_of_last_commit_of_NewRepo> to graft the 2 histories (the history must be on top of the one from the new one)
Use git rcheckin --no-merge to migrate the history to TFVC (that will be long...)
I hope it will help.
PS: perhaps you should try to do it on a small subset of commits to be able to verify it will works before doing it in the real TFVC project.
I use TFS with Jira to managment my team tasks.
I want to integrate a Code Review tool at development process.
When i try to use crucible i reveal that it not support TFS.
I want to know if , there is a good and credible solution for this ,to enable me use crucible with TFS.
additional , if there are another suggests for code reiview tool for VS and JIRA.
Thank!
Some time ago we decided to run Crucible on our project. Our project uses TFS 2012. We use one branch in TFS called 'dev' as a trunk, i.e. branch where developers make commits and where raw code located. Second branch where release code located called 'main'
Our workflow for peer review was:
Make some changes and shelve code
Send email to reviewer
Reviewer doing review in some custom tool and send email with notification that he is done
Commit code into 'dev' branch on TFS
Wait while build-server makes successful build
Commit to 'main' branch where production code resides
Our goal was to improve step 2 and 3. Crucible is great tool, but it doesn't support TFS out of the box, thus we decided to use some TFS bridge. Actually, there are two main options either using tfs->svn or tfs->git. Finally, we decided to use tfs->git bridge, because creating branches in git extremely cheap and it might have been helpful (it did), because we was thinking use branches in git for out shelvesets in TFS. Finally we made our mind to use git.
So far I know only 2 options to convert TFS into git:
git tf - this one works on Linux and recommended by Microsoft
git tfs - this one works only under Windows, but we choose this one, because of large set of commands
We need to convert TFS branch into Git repo and maintain our git repository in fresh state. We don't work with git to push new changes back into TFS, we need git repo only for Crucible.
There are steps we made to achieve the goal:
1. Firstly, we cloned our TFS "dev" branch into "dev" repo. We needed only this one branch, and we haven't any back merges from "main" branch. We have tried to do this with clone command, but without any luck:
git tfs clone http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
This command cloning full history from TFS, but it seems our TFS branch quite large and at some time git-tfs crashed with System.OutOfMemoryException exception. Another time, we failed with exception that max limit of path was exceeded, we found workaround by mapping workspace dir into as short path as possible as follows:
git config --global git-tfs.workspace-dir e:\ws
When we failed with clone command, we went to use quick-clone command. This one cloning starting from any time in history, from any changeset.
git tfs quick-clone -c545532 http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
Option -c545532 here is the number of changeset to starting copying from. Once per year we update all our source files with new header, thus we just to copy from beginning of current year. In that way we should have all necessary history to make branches from shelvesets.
If you hadn't used -c argument here, you would have haven't any history at all, because quick-clone copies just history if you asking for it.
Once repository was cloned, we had written "script" and put it into task scheduler to run every 5 min. What script is doing is just checking for new commits in TFS and creates new branches on our git repository. Again, we use git-tfs here. To get all new commits we call pull command:
git tfs pull
To unshelve TFS shelveset into particular git branch we use unshelve command:
git tfs unshelve -user=TFSDOMAIN\Username "Shelveset Name Here" Branch_Shelveset_Name_Here
This last command creates branch 'Branch_Shelveset_Name_Here' in git from shelveset 'Shelveset Name Here' in TFS. A shelveset's name can contains spaces and some escape chars, so our "script" clean up such cases. As I said, creating branches very cheap on git, thus we haven't any problems with this. If something was pushed into git repo we call crucible API to refresh it.
BTW: To make git repo visible in network I just installed SCM-Server. Crucible was installed and configured to use our domain username/password, thus we get email notification as well. As result we drastically improved step 2 and 3 from our workflow and it works for few months and we are happy with it.
Our workflow became:
Make some changes and shelve code
Wait for our shelveset in crucible (about 6-8 min), create review
Reviewer doing review in crucible
Commit code into 'dev' branch on TFS
Wait while build-server makes successful build
Commit to 'main' branch where production code resides
While working with this I noticed few issues:
Issue1: If you added new file into project and shelved it, you would not see it in git repo, because git-tfs can't find parent commit for it. I'm not sure is it bug of this tool or not, but simplest workaround for this, is having at least one file in shelveset with existing parent. For example, you have added 2 new files and want to send it for review. Instead of creating shelveset with these files, just touch any file which already in git repo (make it pending in Visual Studio), finally you will be able create shelveset with three files (2 new files [add] and 1 for edit [edit]). In that case everything works and git-tfs can unshelve TFS' shelveset into git branch., i.e. we can see it in crucible.
Issue2: One day our HEAD in git repo became detached from "master" branch. Once that happened crucible didn't see new changesets. I have fixed it with command:
git rebase HEAD master
I have created picture how this everything works on our project, may be it could be helpful:
You can integrate Mira and TFS with TaskTop and then use the code review tools built into Visual Studio.
Code Review added in Visual Studio 2012
TaskTop integration with TFS & Jira
These I think are your best options.
Once upon a time we had a TFS repository. We wanted to move to Git. At the time we took just the latest working version, copied that to a new git repo and started working on that.
However due to decommissioning of TFS we'd like to clone the TFS repo to Git (with git-tf) and rebase our changes on that.
Is this possible?
Assuming you are just talking about the source code (TFS is also a work item tracker, build server among other things)
the --deep argument will clone all TFS changesets
git tf clone <tfsurl> <teamproject> --deep
update: bear in mind that this doesn't take into account linked work items, branches, tags.
beware: this will take a while for large repositories...
further reading: http://gittf.codeplex.com/wikipage?title=Clone&referringTitle=Home
I am an almost perfect beginner at Github so please humor me with this elementary question.
I have a laptop PC that I've been using to interact with a repo on Github. I just bought a Mac and I would like to do my programming on both machines.
I have installed Git on the new machine and I have set up my username, e-mail, and Github token on the Terminal.
What are the basic commands I need to do this:
Download the repo from Github the first time? I've created a new folder on my Mac but going there and typing git pull git#github.com/sscirrus/repo.git produces fatal: not a repository (or any of the parent directories): .git.
Upload those changes again such that the main repo is updating cleanly with each new push. I assume that once I have the code in my new folder, it would be a matter of git add . and git push with password entry?
I am reading through tutorials on Git but just want to make sure I'm doing something sensible for my situation before my newbieness screws up a lot of prior work. Thank you!
Go through this book, http://progit.org/book/ and http://gitcasts.com/ for video tutorial.
And I recommend you follow these steps
Clone the repository (git clone repoAddress)
create a new branch (git branch branchName)
checkout that branch (git checkout branchName)
make changes and commit in that branch (git add files)
checkout master (git checkout master)
perform a pull (it updates the local repository with the remote one) git pull
If there is change, checkout the branch and rebase it with local master
If there is conflict resolve it and add that file and make a commit again
checkout master again and merge the branch (git merge branch)
push the commits to the remote repository.(git push)
If you want a GUI tool, then there is GitX which is made for Mac OS X. http://gitx.frim.nl/
Download the git repo for first time - do a clone of the repo first. this will bring your code from github to your machine for the first time.
git clone your_git_repo_url
from second time, you can
git pull your_git_repo_url
Upload the changes after commits
git push your_git_repo_url
Please read scott chacons git books. these will get you the basics of git. and learning this will help in the long run.
You need to use git clone, not git pull.
You'll want to git commit after add and before push. add just adds something to the index (Worst name ever. The "index" is essentially a pending commit.) and commit actually commits it to your repository. push then pushes committed stuff from your local repository to a remote repository.
Whilst there's a lot to be said for using git from the command line (to help understanding) you might like to try the github clients (for mac & windows - download them from the github homepage - at the bottom in the section marked 'clients') which I'm guessing might not have been available when you posted your question.
The Windows one lets you specify a default storage directory (where it clones the repos into) - the Mac one prompts you with each clone as to where you want to stick it.
Both very easy to use to do what you want (clone, pull, push etc and also good for seeing what branches you have and changing between them)
I had been using a Subversion for my source control, combined with git ONLY to deploy (push) to heroku. My pattern was: Update local working copy from latest master at remote subversion repository. Then do git commit and git push heroku (Git was set to ignore .svn stuff). This working copy I only used to push to heroku, I had another subversion folder for doing live development, and committing to the remote subversion repository for tracking.
I have now switched to git fully. I did a complete import from subversion into a new remote git repository. I've successfully been working on my local working copy of the git repo (origin), and pushing changes when it suits me (also collaborating with one other developer, but I basically run the operation).
MY Question:
I would now like to return to my OTHER git working copy that I had previously been using to push to heroku (that has .svn/ stuff in it as well). I'm thinking of just adding my new git repository as an [origin] entry in the .git/config.. pulling the latest changes from my new git remote, and pushing to heroku, but I'm wondering if it will freak out.
It will try and merge and get confused won't it? AND, even if the pull worked, will the heroku remote get confused about a push that originated from some new git repo?
I could clobber (delete) that working copy (used to push to heroku from subversion), and make a new clone of my new git repository, then add heroku to the .git/config. But I'm concerned pushing to heroku will still cause it to get confused, since I used to push from a different working copy.
Any advice would be great!
Thanks in advance!
If I understand you correctly, you want to switch back to the former SVN repository as your working copy, and you want to preserve the old SVN history?
There are a couple of options available.
Push the recent changes from the new Git repository to Heroku, then switch to the old repository and pull from Heroku. This will bring you old repository up to date.
Temporarily change the URL in the old repository's config file to point to the local path of the new repository. Pull the recent changes from there, and then revert back to the Heroku URL when done. This will also bring your old repository up to date.
The first option is the most expedient, and the second is the long way round. Either way, you will have the same net result of an up to date local repository containing all history. The surplus new repository can be disposed of in either case.
Edit:
To address your concerns about whether Heroku will care about the origin of the commit, in brief, no the repository on Heroku is another git repository that accepts commits from authenticated users.
As long as the credentials are correct, the originating repository does not matter. This is the beautiful thing about DVCS - there is not one controlling or corruptible repository - It is entirely possible for you to now clone from Heroku on another machine and continue work from there. As long as your credentials are the same, the history will show any and all commits you push, but does not care where from.
If your desire is to simply use a clean repository to work with, the new one will be the favorite. The old one can be deleted without ill effects.
To prove this - check the SHA-1 hashes for a commit in both new and old repositories, and you will see they are identical. The hash is unique for all commits, and can be used to check the code integrity at all times. There will never be more than one change for any given hash.
As a side note, the repository is portable in that it is entirely self contained, and can be moved around freely on your storage space, or even be used on external storage such as a USB thumb drive.