I have project A. The project A is in perforce as well as in github( Business decision). They are both out of sync. I see that I can use git-p4 tool http://git-scm.com/docs/git-p4 to submit git changes to perforce. Problem is first instruction of it says is:
git p4 clone //depot/path/project
This command will create a new repo in git hub. I do not want that. I want my existing perforce depot to connect to exiting github repo and then sync files from github to perforce. Is it possible?
No. git p4 is basically just a wrapper around Perforce. It reads changes to a Git repo and issues the proper Perforce commands to commit them (and vice-versa -- it reads changes to a Perforce checkout and issues the proper Git commands to update a Git repo accordingly). So you need to have a Perforce checkout and a local Git repo that can talk to that Perforce checkout.
Fundamentally you have two different histories for the same project, so you need to find some way to reconcile them.
git-p4 can sync from Perforce (create a new git repository), then you can add a new remote pointing to github, and sync the branches from there.
However that doesn't help with the problem of merging the histories.
You can either:
Go with Perforce, and rewrite github history
Go with Github history, and get your perforce admin/Perforce (company) to rewrite your Perforce history.
2 is probably (politically) impossible. May be impossible technically. Perforce is designed to prevent history from being altered.
1 will break anyone cloned from your github repository.
You may want to take a look at Git Fusion, which is a bridge between Git and Perforce:
http://www.perforce.com/git-fusion
This KB article gives an example of how you may wish to work with a project that is both in Perforce and a public Git repo:
http://answers.perforce.com/articles/KB/7481/
Hope this helps!
Related
I have copied repository from my team member and I want to synchronize with GIT repository.
Please keep in mind that I am new to GIT and I only have URLs of the repository where I need to synchronize. I need help to connect my repository with GIT repository. I have not imported any repository and I have just copied that. I will be able to push or pull or merge etc. only if my project is synchronized with remote repository. Please let me know that how can I synchronize. Thanks
It's unclear from your question whether you are trying to simply keep two copies of the same repository synchronized or something else.
If it's the first, then what you want to do it a git clone. Your changes should be git commit, to get remote changes you should git pull and to push your changes to your co-worker's repository, you should git push.
Depending on your operating system, there are different front-ends for Git. I gave you the command-line version. I saw you tagged your questions with the eclipse tag, which suggests you are trying to do this inside Eclipse. In that case, you might find EGit useful. See the EGit User Guide here.
If all this sounds too complex for you, you should first Read The Manual - that is, check out the Getting Started chapter of the Git Documentation.
I found the solution. I had to go in team-> share projects. then "create a new repository location" and paste the url of git repository. then team->share project-> git and add the repository. Now my copied repository is linked/connected with my git repository and I am able to synchronize my repository.
Our team is looking to migrate our perforce server over to Git. Is there a way to sync check-ins from a branch in our Github Server back to Perforce to keep them in sync? I have been looking at git-p4 and there seems to be lots of documentation of how to sync Perforce -> Git but not the other way around. I would ideally like to have it syncing both ways perforce <-> git, is that possible with p4-git?
Perforce GitFusion can do this, but the developer would have to push changes to the GitFusion server instead of the github server.
For most of the time, merge conflicts were sorted out automatically. Perforce was the "master". People submitting from Perforce always had their change go straight through. People submitting from git would have their change submitted via this process:
lock master git repo
fetch upstream p4 changes
rebase against upstream p4
submit to p4 if that all went ok
That still left a very small window between (3) and (4) where someone in Perforce land could submit a conflicting change to the same files. But in practice that only happened a couple of times, over the course of several years of probably hundreds of commits per week.
In those two cases I went in and manually patched things up which was a bit clunky. I think you could just automatically discard the problematic change quite easily, but in the end, switching to git entirely made this problem go away.
Git-p4 is designed such that the git repository is initialized with data imported from Perforce. After this initial import bidirectional communication between git and Perforce repositories is fully supported, with the exception of branches/merges that have limited support.
To import updates from Perforce to git:
git p4 sync
To submit changes from git to Perforce:
git p4 submit
For more details regarding git-p4 configuration please consult its documentation.
Update: I would always advise to test any flows in temporary repositories before deploying.
In the past I setup something like this. I had a gitolite repo and a p4 server. Changes pushed to the gitolite repo would be picked up by a cron job and turned into P4 commits (via git-p4 submit). Similarly, changes submitted to p4 would be picked up by the same cron job and synced back to git (via git p4 rebase).
There were two git repos involved: the gitolite repo that normal git developers committed to, and a separate git-p4 based repo where the git-p4 operations took place.
I had a fairly small shell script to co-ordinate everything. The main tricky areas were:
locking: you have to forcibly rebase the gitolite repo so you need some way to ensure developers don't lose changes when this happens (I used a lock file).
Merge conflicts. Very occasionally two people would edit the same section of a file in P4 and git at the same time.
I have faced this problem myself and as far as I know there's nothing of the kind.
In my case I have to basically:
Create a patch for the changes in Git: git diff sha1..sha2 > mypatch.diff
Make a list of the affected files: git diff --name-only sha1..sha2 > files.list
Apply the patch in the P4 repo: git apply mypatch.diff
Reconcile changes in P4: for each file in files.list; p4 reconcile $file; done
Edit your P4 change list and then submit it (I'm sure this can be automated too but I haven't had the need for it).
I have a couple of scripts that help me with this, you can find them here: https://github.com/pgpbpadilla/git-p4-helpers#sharing-changes-git-p4
I have been using this workflow for ~6mo and it works for most cases.
Caveats
This creates a single change lists for all commits in the sha range (a..b).
My client is using SVN and my company is using Git (central bare Git repo). So I have the task to sync both servers. I can't use SubGit , because I can't do any modification on either server.
I successfully used git-svn to download the SVN to my local Git repo (using TortoiseGit). But I can't figure out how to set up a remote upstream to the central Git Repository (using Egit in Eclipse).
Is it possible to set up a remote branch, so I can check in the SVN stuff from my local Git into the central Git repo? How?
thanks.
If I understand correctly, you can't update hooks in SVN and Git repositories. That complicates the task a lot, because you can't reject pushes Git if someone is committing to SVN at the same moment and vice versa.
I think, that git-svn is not a solution because on sending commits to SVN ("git svn dcommit") it changes Git commit SHA-1 to add git-svn-id: signature. As result when one pushes commit C to your Git repository, you fetch that commit to your git-svn repsository, run "git svn dcommit", it translates it to SVN and adds git-svn-id: signature to commit message thus changing commit SHA-1, so you'll get another commit C' in git-svn repository. After that C' should be sent back to the Git repository, and after that the user that pushed C should download C' and replace C with C' in his working copy. So you won't have easy and transparent synchronization.
With SubGit you can reduce your problem to synchronization of 2 Git repositories by creation of an "intermediate" Git repository with SubGit installed into it. Synchronization of 2 Git repositories is a simpler task (and there's a lot of solutions on the internet) but it's still isn't a piece of cake, because 2 different users can push into both repositories simultaneously (and you can't discard one of the push, because you can't create hooks in the repositories). If these changes are conflicting, you can resolve that only manually, and I'm afraid this is the best you can do: create a repository with 2 remote and using a script constantly fetch changes from one of them and push the changes to another one and vice versa (and notify the administrator and stop synchronization on simultaneous conflicting changes).
Disclaimer: I can be biased because I'm one of SubGit developers.
I have git repository on bitbucket. I use it from Eclipse for a while, but then copy Eclipse project with local git repository to another place on the filesystem and work locally for 3 weeks. I'm a newbie with git, so I just copy the project as is.
Yesterday I try to push local changes and then switch to the remote branch. Now I see in git-gui only old bitbucket commits and no new files. I search in git-gui everywhere. But the size of the repository tells me that my new files are still there (on bitbucket 16mb, locally >300mb).
git branch shows me 2 branches (master and * (no branch)) and both have bitbucket commits. I didn't make any branches, I just first cloned the repo from bitbucket, then made commits, then made some actions trying to push the copied repo and then change branch. Any idea of how can I restore my local files will be greatly appreciated!
I'm really having a hard time understanding what the exact situation is.
However, if you say all the files are still in the local repo, a simple:
git reflog
is all you need to see recent commits on all branches. Find the right commit you want to go back to, and take it from there.
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.