I'm wondering if there's an easy solution to this workflow. I work using the perforce GUI (P4V), but I'm not adverse to using the command line for this. In any case, let's say I fix 3 bugs working on my personal development branch. Each one I submit to my personal devel branch in 3 different change lists.
Now I want to merge/integrate those to the main branch. Currently, when I do that all 3 change lists get squashed into a single one in the main branch. However, is there a simple way to do this so that all 3 changelists remain separated? The only other option I see is to cherry pick change lists -click on each changelist in the history tab,-- and merge them there one by one...
Suggestions would be appreciated!
Thanks,
Rodrigo
If you want 3 changelists on the main branch, you have to submit 3 times:
p4 integ my_dev/...#A,A main/...
p4 resolve -am
p4 submit -d "merged A to main from my_dev"
p4 integ my_dev/...#B,B main/...
p4 resolve -am
p4 submit -d "merged B to main from my_dev"
p4 integ my_dev/...#C,C main/...
p4 resolve -am
p4 submit -d "merged C to main from my_dev"
Related
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).
I have an old mercurial repository for a project that has the changes before a certain date, and I have another repository for the same project with all the changes after that date.
I want to merge these two repositories so the history reflects that the first commit in the latter repository is the child of the last commit in the former repository.
Is this possible? Or do I just have to merge both heads?
Reading here:
http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/
and here:
https://www.mercurial-scm.org/wiki/RebaseExtension
I looks like what I am wanting to accomplish can be done with a rebase, with some caveats.
I pull the changes from the newer repo into the older repo. This results in two heads since both repos only have the 'default' branch. In the older repo folder, I ran:
hg pull -f ../newer-repo
Then I have to use hg phases to make the pulled changes malleable. Normally, this is a bad idea, but since I know I am the only developer on this project, I can do this safely.
hg phase -f -d -r 15 16 ...
Finally, I can now rebase because the history pulled in from the newer repo begins with the same state as the last changelist in the old repo.
hg rebase -s 15 -d 14
I have a single history and no conflicts.
This probably wont work for everyone, but in this narrow circumstance, this was exactly what was needed.
We have two users working on the same class files in two separate git branches.
User A does nothing else but an "autoformat" Ctrl-Sift-F in Eclipse
User B just adds a space in a comment
Now we get a "conflicting change" and can't merge anymore.
Basically we are stuck just because of the autoformat.
How to resolve this situation in Eclipse git or on command line git bash?
You can use git merge -s ours or git merge -s their to decide which version of the file you wanna keep after the merge.
Resolve the conflict as you would with any merge conflict. It sounds like a pretty simple conflict to resolve. Or since the changes were trivial, the person doing the merge (i.e. the person who hasn't pushed their commit) can just reset back to a common commit, allowing them to pull the other person's changes.
git reset --hard THECOMMITID^
Where THECOMMITID is the unwanted formatting change. If it's just the most recent commit then you can use HEAD^.
I'm just starting out with bazaar, and I've found that the checkout feature is the most useful for the way I work - namely I can c/o from a "master copy", do some development and then commit my changes in the new directory. This then updates the "master copy".
But what if I'm working on (eg) two projects, changing different portions of code? Say:
~/master - master copy
bzr co master ./gui
bzr co master ./engine
So I'm doing gui-related stuff in the ./gui directory and under-the-hood stuff in ./engine. How should I commit my changes? If I commit gui first, then engine, I guess any conflicts will be flagged in engine?
Is there a way to merge gui and engine, and then do just one commit to the master copy?
To make things a little more complicated, how about if I do this:
bzr branch gui ./mouse
Now I perhaps I've been working on mouse, but also on gui. If I want to merge the code from gui AND mouse, and then commit to master, what is the best way to manage this? Or indeed, if I also:
bzr branch gui ./keyboard
If I've changed altered gui, keyboard and mouse, should I hierarchically merge - ie mouse+keyboard, then merge this with gui, then commit gui to master?
I hope it is clear what I'm trying to achieve! Thanks in advance for your time.
If you have two checkouts, any time you commit changes to one, you will first have to pull down any changes from the other one, potentially having to resolve conflicts at each step. This is generally a good idea, since it's easier to resolve conflicts over time and make sure your code doesn't diverge too much.
However, it sounds like you want to have separate developers working on "gui" and "engine", or you just want to save your conflict resolution till development on both branches has completed. In this case, you should probably create them as independent branches with "bzr branch". Each branch can use local commits and not worry about conflicts with each other. Then when it comes time to merge you can do it one of 3 ways, all of which get the same end result:
1. Merge one branch into the other, then push it up to master:
cd gui
bzr merge ../engine
# manually fix any conflicts
bzr commit
bzr push #back up to main
The downside to the above method is that your "gui" branch now has the "engine" changes in it. Which is fine if you're going to throw away both branches once they're pushed back into the mainline. But if you want to keep the branches longer, you can:
2. Merge into the mainline:
cd master
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit
This has the upside that you still have "gui" and "engine" as separate branches, but you've had to commit one to master before you were sure that they would both work together. So you really probably want to:
3. Create a merge branch:
bzr branch ~/master gui-engine-merge
cd gui-engine-merge
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit
bzr push ~/master
# since this branch was only for merging, you don't need it anymore:
cd ..
rm -r gui-engine-merge
Yes, bzr should prevent you from checking in changes from the engine repo if it detects conflicts. Normally, you first do "bzr up" just prior to check-in and then make sure your stuff plays nice with others.
As for the second part of your question, dealing with mouse/keyboard branches, this is how I would normally do it. Simply cd into the gui dir, and then do:
bzr merge ../mouse
After merging the changes, you can then commit from the gui directory and it will send the changeset to the "master" directory.
Note that I'm hardly a bzr expert, but this is the way I've been dealing with SVN repos.
How do I get a patch from a commit in order to send it to another developer? And how do I best avoid a merge conflict with this patch when merging our trees at a later date?
If you know how please explain how to do this in your VCS of choice such as subversion, git, Mercurial, bzr or etc.
In git you can pipe the output of git-diff between two commits like this:
git diff fa1afe1 deadbeef > patch.diff
Send the patch.diff to the developer and let him git-apply it to his workspace like this:
git apply patch.diff
If the other developer already has the commits available in his repository he could always pipe it in himself without merging like this:
git apply < git diff fa1afe1 deadbeef
You can then add and commit the changes in the diff the usual way.
Now here comes the interesting part when you have to merge the patch back to the master branch (that is public). Consider the following revision tree where C* is the applied patch from C in the master branch:
A---B---C---D master, public/master
\
E---C*---F feature_foo
You can use git-rebase to update the topic branch (in this example named feature_foo) with it's upstream head. What that means is when you type in the following:
git rebase master feature_foo
Git will rearrange the revision tree like this and will also apply the patch itself:
A---B---C---D master, public/master
\
E*---F* feature_foo
Merging to the upstream branch will now be an easy fast-forward merge. Also check that the new commits E* and F* work as the previous E and F respectively.
You can do the same thing against another developer's branch using the same steps but instead of doing it on a public repo, you'll be fetching revisions from the developer's repository. This way you won't have to ask the other developer for a patch if it is already available from what he published at his repo.
Please note to never rebase a public branch because the command will rewrite git history which is something you don't want to do on branches that people depend on and will create a mess when merging to remote repositories. Also never forget to integrate often so others in your team can take part of your changes.
In SVN you can simply make your changes then before commiting, pipe the output of the svn diff to a file as such
svn diff > mypatch.diff
you can then revert your changes and apply the patch at a later date using
patch -p0 -i mypatch.diff
As always don't blindly apply patches to your code and always inspect them first.
You may also find that the patch will break your source code if the source files have changed significantly enough since the patch was taken.
You also can not guarantee that there will not be merge conflicts when you attempt to check in the code.
Bzr handles sending a "merge directive", meaning it sends the patch for you so that the other party can simply click "OK" to merge and there's less futzing around with patch/apply etc.
just:
$ bzr send -o mycode.patch
In Subversion there is no nice way of doing this. Yes, you can use svn diff + patch but this will only postpone your problems until you are going to merge and by then chances are that you've forgotten about it.
The way you would do it in Subversion would be to create a branch, do the commit on the branch and ask the recipient of the patch to switch to the branch. Then you can merge the branch back to trunk in the usual way.