I am working on a git-svn project with two branches, lets call them
trunk
branches/foo
How can i merge branches/foo to trunk?
they both have the latest update
Thanks
It is inadvisable to merge two SVN branches via Git. If in Git you merge from your branches/foo clone to your trunk clone and then managed to successfully push back to SVN, the files would be correctly updated on trunk, but SVN wouldn't be aware that it's the result of a merge - no merge-tracking information will be updated in SVN.
In fact it gets more complicated than that - when you merge between two Git branches that are both tracking remote SVN repos, git-svn can get really confused and it's very easy to mess up your repository. This is because git-svn looks back through your Git log to find the SVN tracking information, and if it finds a merge then it won't necessarily head down the branch you expect. So even if you've merged from branches/foo into trunk and you're now on trunk, it's possible that a dcommit would push back to branches/foo.
Better to switch back to your regular SVN tools to do merges and just use git-svn for development.
Another roof option could be next:
checkout your trunk branch # git checkout -b trunk git-svn-trunk
and cherry-pick dev commits into trunk branch,
i prefer pick one by one and solve conflict slowly
after that you have a 2 branches with the same commits
maybe do you want remove dev branch and create a new dev branch from trunk branch,
now this branch (new dev branch) has a correct git-svn reference to your svn trunk...
keep recommendations write by #simonp answer
i hope this help to you
Related
I am new to managing code revisions and need guidance on how to merge to code sets. I have a MASTER branch with my latest UI and I have a branch called "Feature-A" with lots of Django additions + template additions to the previous UI files.
Since I am new to Github, I want to take the safest approach incase I need to revert mistakes. Should I make a new brach of master and merge Feature-A into that branch or should I merge Feature-A directly into the MASTER?
Since you're new, I would say the best approach would be to create another branch (clone of master branch) and then merge feature A into that, and see if it works. If not, keep testing feature A to make it compatible. If it works, great! Just remove that extra branch and merge feature A into the master.
I.e.,
git checkout master
Then, create a new branch (git checkout -b 'featuretest')
Now, git branch shows
* master
* featureA
* featuretest
Then, do git checkout featuretest, and git merge featureA to merge it.
If the feature works, great! Remove the branch (git checkout master; git branch -d featuretest)
and do it for real (git merge featureA)
If the feature doesn't work, go back to the feature branch (git checkout feature) and keep testing.
I am using git-svn in my workplace since our current version control server is subversion and switching completely to git does not seem to be on the horizon for now (*cry*)
My workflow is as follows
I have the following branches
master tracks remotes/trunk
local/0.4 tracks remotes/0.4
work is my development branch for the master branch
work-0.4 is my development branch for the local/0.4 branch
I work in my work branches, then I merge to master and local/0.4 using
git merge --no-ff <branchname>
After that I check in to svn via
git svn dcommit
and I use
svn.pushmergeinfo=true
to update the svn:mergeinfo properties so my colleagues won't get angry with me messing up that metadata for them :)
However, I just had the following problem which stumps me.
I had done two commits on the work-0.4 branch, then I merged these to my local/0.4 branch with git merge --no-ff work-0.4. After this, I did git svn dcommit and recieved the following message
Committing to https://svn-server ...
e138050f6ebd2f2ca99cbefc5e48acae412e1f86 is merged into revision f5f2345e8e5fc64
20423bdc00397b5853b3759c4, but does not have git-svn metadata. Either dcommit the
branch or use a local cherry-pick, FF merge, or rebase instead of
an explicit merge commit.
After some rebasing and reset'ing of branches I managed to push everything to svn, but my solution entailed doing a rebase of my local/0.4 branch to the work-0.4 branch which in turn meant that I did not get to squash my two git-commits into one svn-commit :/
I feel that I'm probably doing something wrong with my workflow here, and it might be related to svn.pushmergeinfo. The docs for svn.pushmergeinfo says
config key: svn.pushmergeinfo
+
This option will cause git-svn to attempt to automatically populate the
svn:mergeinfo property in the SVN repository when possible. Currently, this can
only be done when dcommitting non-fast-forward merges where all parents but the
first have already been pushed into SVN.
and to be honest, I'm not quite sure that I understand that correctly? Am I doing something weird here that makes svn.pushmergeinfo not work correctly? How should I structure my workflow to optimally work with git-svn correctly (setting proper mergeinfos etc)?
The company that I'm working is working with SVN but I would like to start working with git to take advantage of the light branching and stashing features (disclaimer, I'm pretty new to git). I've started with git-svn and I'm trying to figure out the ideal git-svn workflow for what I'm trying to do (and suggestions if what I'm trying to do needs tweaking).
I've read through git svn workflow - feature branches and merge and a few other posts but its still not clear how I should approach it.
How I plan to work:
I plan on having my master branch be clean from development and only used for merging/rebase/dcommit.
I would like break apart each new feature/bug into separate git branches so they can be worked on independently. Meaning, I can work on one feature for a few hours, then put it aside and work on the next issue. When I was in SVN it was a problem when I had two different features/bugs in one file because when it came time to commit, I would remember that it had both changes and temporarily take out what I didn't want to commit now - a pain.
And the are some features which are while I might want to work on now, will not be added to the main repo for some time.
After a feature is ready to be shared/tested in the main repo, I'll merge/rebase into my master branch and then dcommit to the svn-repo. I only want to have one SVN commit message for each dcommit - I want to be committing in more often with comments more specific to me and then dcommit to svn with a message for the rest of the team. I assume for this I'll either be using a git merge --squash or a git rebase --interactive for this.
The basic git flow I've envisioned is like this:
// it begins...
git svn clone <repo>
//
git checkout -b feature 1
// work commit, work commit
//
git checkout -b bug-123
// work commit, work commit
// bug-123 finished - ready to send back
// got back to master for step 5
git checkout master
// get whatever changes other devs did
git svn rebase
//
git checkout bug-123
// rebase branch so I have fewer smaller changes. not sure here..
git rebase master || git svn rebase
// Assuming I'm doing a FF rebase so my commits are just addons to the current repo
// I don't know if I rebase the master or svn repo or it doesn't matter.
// need to get my changes back to master to send off
git checkout master
// add my changes to master
git rebase bug-123 (--interactive?) || git merge --squash bug-123
// do I add a new commit message here?
// push my changes back out to the team
git dcommit
So there are a few questions:
How should I get the changes into the branch I want to commit - by rebasing the master or the svn branch
how do I get the changes back into the main branch - rebase or merge - remember, I want only one commit for each commit - unless this is going to complicate things - I really would prefer to keep my git commits separate from the SVN commits because I might start something - it's half-working, and want to commit it so I could try something else - but I don't want to commit these broken steps.
would it make sense to dcommit directly from the working branch (eg bug-123)?
how do I get the changes from bug-123 back now into feature-1? I'm assuming I'll do it via the SVN repo - meaning the changes that I added will get merged in when I do the rebase when it's time to add feature-1 to the repo - but maybe not.
I'm no expert, but these are the experiences I've made (related answer).
I think it doesn't matter. The important thing is that you rebase the latest changes from SVN into the branch you are going to dcommit from.
Let other branches receive the changes through SVN. If you want a single SVN commit from a series of git commits, squash them together first.
I think this doesn't matter either. You're going to rebase the latest changes from SVN, and need to get them linearly in front of your Git commits. If you do git svn rebase in master, and then rebase master into a feature branch, or the other way around is same-same. Afterwards you probably want to delete the branch, as it has done its work (as per SVN restrictions, you're not allowed to merge again).
Always let changes flow into other branches and repos through SVN rebasing.
Just try it out and try to get the most simple/practical workflow for you and your team. Try to keep branches short-lived (SVN won't get any notion of them anyway), and remember that the commits must always be linearized at the top of your log before you dcommit back.
We are in the process of converting from CVS to Mercurial hg.
Our infrastructure is Windows 2003/IIS6
Each developer develop on their machine
1xDevelopement server
1xStaging server
Production environment
Here's what I have done so far:
Installed Mercurial on my machine, on the development server and on the staging server.
Created a repository on the dev. server.
Imported our CVS repository in there.
Cloned that repository to my local machine.
Cloned that repository to our staging server.
For development in the past we always shared 1 branch, not ideal but merging was such a pain that we never bothered and dealt with it.
Now if I understand correctly, we should be doing this:
Local:
hg branch myfeature1 //Start work on feature1
Urgent bugfix required, using the affecting the SAME files as our feature
hg update default
hg branch bugfix1 //fix bug
hg commit --rev bugfix1 //done fixing bug we commit
hg push --rev bugfix1 -f //-f seems odd here, forcing to create a new branch
hg update feature1 //we return to work on feature1
hg commit --rev feature1 //done work commit
hg push --rev feature1
DEV
hg branches //we see the bugfix and feature1
hg merge --rev bugfix1
hg commit //commiting bugfix1
hg merge --rev feature1
hg commit //commiting feature1 //Dev master is now our main trunk ready for a new developer containing the feature1 and bugfix1.
Staging (The QA needs to signoff on that important bugfix before testing feature1
hg incoming //we see the new stuff
hg pull --rev bugfix1
hg merge --rev bugfix1
hg commit
//QA test and signoff bugfix1 we clone to a production repo and sync.
//QA can now test feature1 which we finished some days after bugfix1
hg pull --rev feature1
hg merge --rev feature1
hg commit //commiting merge feature1
//QA test feature1 and signoff
We clone to a production repo and sync.
Does this way make sense? Am I complicating things and will it bite me in the ass later?
It looks like you've got the concepts down great, but you've got some oddities and some questions in there, I'll hit them as a list below:
commit doesn't take a --rev option. It commits the current working directory as a new changeset whose parent (or parents if it's a merge) is whatever hg parents returns, which is always whatever you last hg updateed to.
your hg push --rev bugfix1 -f won't require a -f in very new (1.5+) versions of mercurial. Historically the warning "you're creating a new head" usually meant you forgot to merge, but now if the new head is a new named branch the warning is suppressed.
If I were your person doing the emergency bug fix on my local machine I'd just create a new clone and do the branch and fix in there. If you set up your webserver/webapp config to support that you can allow new instances at new path locations easily/automatically
In your staging environment, I recognize the desire to have them test the bugfix independent of the feature and that's a good idea, your QA team shouldn't be merging. Make/let the developers merge and have the QA team pull the merge revisions into their working area. For example, the developer changeset created in DEV step 3 already provides the proper integration of the bugfix and what-used-to-be, so have the QA team pull that revision, which will be on the 'default' branch. Similarly, after QA has approved the bugfix and is ready to move on to the feature, have them pull from dev the changeset created in dev step 5.
Remember, merging is coding too -- the person doing the merge is making choices about what should and shouldn't be. The QA people might be capable of it, but it's the developer's job. Also, why do it twice? The usual handoff for this is something like "QA, pull revision 897a9d9f9a7 and test please -- the developers". If you want to get fancy you can have a tag like 'readyforQA' that the developers move along the 'default' branch as they go (in this example they'd hg tag after their steps 3 and 5 and let QA know there's new stuff to pull.
The one piece of advice I'd give you is don't try to over-engineer the process. DVCSs lead to a sort-of haphazard way of working, that's a little scary at first, but tends to work out. YOu'll find sub-teams and pairs of folks have clones you never knew about and in the end so long as you have a few firm rules like "nothing goes to production without first passing through QA" the rest sort of works itself out.
I would like to do some experimental work in a hg project. So I would like to create branch, commit to it. And if the experiment works, I can merge it back to main branch.
In git, I can do
$ git branch experimental
$ git checkout experimental
(edit file)
$ git commit -a
$ git checkout master
I've read A Guide to Branching in Mercurial. It said hg branch feature. But what is next?
I don't follow.
$ hg branch experimental
(edit file)
$ hg commit
$ hg update default
First note that git branch is different from hg branch. Branches created with hg branch are permanent and live in a global name space, whereas branches made with git branch are transient. The nearest equivalent of git branch is hg bookmark: bookmarks can be renamed and deleted and behave more like Git-branches.
I've recently written a guide for Mercurial bookmarks. Compare this with the named branch guide. Both guides contain worked examples of how to use (named) branches in Mercurial for keeping track of the development. It shows how to merge branches and how to close them or delete the bookmark when you are done.
If it's not a big feature (i.e. the branch doesn't have to have a name), it's quite simple.
Let's say your repository is at changeset X. You work on the feature as much as you like, commit, commit, commit and if you're happy with the result, continue as if you knew it would work all along. ;) If you aren't happy, do a hg update X and continue development from there. All the work you did on your experiment will become an anonymous branch.
Strangely enough, it appears that Git doesn't provide such a way to work with anonymous branches which is what might be confusing you.