Back to the main page.
Bug 1841 - get hands-on experience with branching and merging with SVN and/or GIT
| Status | CLOSED FIXED |
| Reported | 2012-11-21 13:44:00 +0100 |
| Modified | 2019-08-10 12:03:50 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 2123 |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=2036http://bugzilla.fcdonders.nl/show_bug.cgi?id=780 |
Eelke Spaak - 2012-11-21 13:44:54 +0100
This goes for the whole team. first step: try to find good literature about it. second step: read it. third step: explain it to one another. fourth step: apply it in small 'projects'. fifth step: the real deal.
Eelke Spaak - 2012-11-21 13:47:22 +0100
test
Eelke Spaak - 2012-11-21 13:47:54 +0100
please assign yourself to the cc list
Robert Oostenveld - 2012-11-21 15:37:20 +0100
On http://fieldtrip.fcdonders.nl/development/svn#how_to_work_with_an_svn_branch we already provide a little bit of information. That wiki section should eventually be extended with out joint findings.
Robert Oostenveld - 2012-11-23 13:59:11 +0100
Tim (the boyfriend of Lilla) has been explaining me really useful stuff on branching. He will help us with some concrete issues. Already some reading material http://git-scm.com/book http://www.ericsink.com/vcbe/html/bk01-toc.html
Robert Oostenveld - 2013-01-23 11:04:31 +0100
Gio triggered the discussion on the fieldtrip-dev list. Let's continue and try to accumulate all relevant information here. See also http://fieldtrip.fcdonders.nl/development/git where I want to have the final documentation (like http://fieldtrip.fcdonders.nl/development/svn).
Robert Oostenveld - 2013-01-23 11:23:55 +0100
Yesterday I made a first version available on github, but then realized that the authors were more or less anonymous. Today I made an authors.txt file and repeated the export git svn clone svn+ssh://roboos@svn.fcdonders.nl/home/svnroot/fieldtrip -T trunk -b branches -t tags --authors-file=authors.txt --no-metadata This version should replace the current one on github.
Robert Oostenveld - 2013-01-23 12:18:37 +0100
I removed the existing github/fieldtrip repo and tried uploaded the new one cd fieldtrip git push origin master git remote add origin git@github.com:fieldtrip/fieldtrip.git but it asks for my username, password (which I know is correct) and then does nothing.
Gio Piantoni - 2013-01-23 12:22:14 +0100
try pushing again with git push origin master the order is: 1) link your local repo with github repo git remote add origin git@github.com:fieldtrip/fieldtrip.git 2) push local changes to github repo
Robert Oostenveld - 2013-01-23 12:30:21 +0100
(In reply to comment #8) mac001> git push origin master Username for 'https://github.com': oostenveld Password for 'https://oostenveld@github.com': and then it sits there forever. I'll try it with another copy of the svn repo, now with git svn clone svn+ssh://roboos@svn.fcdonders.nl/home/svnroot/fieldtrip -T trunk -b branches -t tags --authors-file=authors.txt i.e. with the authors but also with metadata
Gio Piantoni - 2013-01-23 12:44:27 +0100
I have never had this problem. I don't think it depends on the repository. It seems a problem with the configuration of the remote. Can you push any file at all? Maybe try: git remote -v In my case, it looks like this: origin git@github.com:gpiantoni/fieldtrip.git (fetch) origin git@github.com:gpiantoni/fieldtrip.git (push) (sorry, not an expert myself)
Robert Oostenveld - 2013-01-23 21:42:19 +0100
(In reply to comment #9) the attempt without the "--no-metadata" option worked fine and I pushed it to github. mac001> git remote -v origin https://github.com/fieldtrip/fieldtrip.git (fetch) origin https://github.com/fieldtrip/fieldtrip.git (push) looks fine.
Robert Oostenveld - 2013-01-25 14:11:30 +0100
I ran into this problem http://blogs.coreboot.org/blog/2010/08/27/git-svn-info-unable-to-determine-upstream-svn-information-from-working-tree-history After doing it once more and now taking very good care of not doing anything with the git-svn exemplar on my local computer, I now have a git-svn repo on my local computer and on github that allows me to do mac001> git svn rebase mac001> git push origin master resulting in the latest svn changes being sent to github. So https://github.com/fieldtrip/fieldtrip/commits/master looks ok, including the svn updates from today. I will do tar cvzf fieldtrip-git-svn-r7407.tgz fieldtrip-git-svn/ to secure this specific copy, as appears that is the only one that allows me to keep them synched. I'll also try to make an svn hook (or cron job) to do this automatically to keep all (public) versions always in sync. On a related note: the page http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows is important. We are used with SVN to use the "Centralized-Workflow". With regards to git we should move to the "Integration-Manager-Workflow".
Robert Oostenveld - 2013-02-20 18:03:15 +0100
I now have two branches, one for bug1961 (arduino stuff) and one for bug780 (filter issue). I have managed to get the bug780 merged into master and from there into svn. See the comments in bug 780 for details. The bug780 branch is not needed any more and I should be able to delete it.
Robert Oostenveld - 2013-02-21 10:10:00 +0100
when we discussed this yesterday, I mentioned (but could not find) a page that explains why git branches are usefulI. I found the page back on my ipad: http://nvie.com/posts/a-successful-git-branching-model/ Please read it and try to understand the figures. I hope it clarifies the different aspects of the development that we often don't explicitly think about - writing pieces of new code or fixing existing code - combining pieces of code - making decisions on what goes where - testing and releasing In our current FT svn model, everything is tightly integrated and focussed on immediate releases. E.g. we release every small snippet of code, and we only test after we have released (to home/common and to the ftp server). Git allows to take a step back and to separate the implementation of new functionality, fixing bugs, integrating, testing, releasing.
Robert Oostenveld - 2013-03-08 11:33:57 +0100
Having used it a bit, I found this explanation on the difference between a fork, branch and clone quite useful http://stackoverflow.com/questions/3329943/git-branch-fork-fetch-merge-rebase-and-clone-what-are-the-differences/9204499#9204499
Gio Piantoni - 2013-03-10 16:23:21 +0100
Hi, Last week, I used github.com to send a "pull request" and Robert added my changes to the main (svn and ftp) repository of fieldtrip. This means that external contributors without access to the svn repo can send patches and improvements to the code using git and github.com. I wrote a short tutorial on writing external contribution for FieldTrip at: http://fieldtrip.fcdonders.nl/development/git Please, feel free to edit it and improve on it. There is quite some information on the internet. A very clear tutorial (by the MNE-python people) is at http://martinos.org/mne/contributing.html Let me know if you have comments or suggestions. Gio
Robert Oostenveld - 2013-03-10 18:32:03 +0100
(In reply to comment #16) > Let me know if you have comments or suggestions. Great explanation, thanks a lot!
Jörn M. Horschig - 2013-03-20 16:32:59 +0100
this may be of interest for us: http://sourcetreeapp.com/
Roemer van der Meij - 2013-04-16 18:17:21 +0200
A question on our linking of svn and git. I just pushed a commit in git that affected the same file (ft_findcfg) in two different locations (utilities and utilities/private). I edited both copies because it was recursively calling itself in both locations, and committed them at the same time. Hopefully, this doesn't put svn in an eternal syncing loop, i.e. seeing file1 changed and changing file2 as well, than changing file1 again because file2 changed ad nauseum. I don't expect it to, but thought to ask just in case. Doing it here, so the rest of the team is aware of it too.
Robert Oostenveld - 2013-04-16 20:24:07 +0200
(In reply to comment #19) On our svn server we have implemented a number of svn hooks, i.e. scripts that are executed upon each commit. One of these scripts deals with synching similar files. Git does not have something like this yet, so the mechanism would be git commit -> svn sync (using cron) -> autosync script -> svn commit -> git sync (using cron) with the cron job that presently runs every 15 minutes it takes between 15 and 30 minutes before you are able to see the effect of the autosync script. We can discuss this tomorrow at the FT meeting.
Roemer van der Meij - 2013-04-17 17:37:10 +0200
We talked a little bit about pulling/merging/rebasing during the meeting today, the following is an interesting read: http://stevenharman.net/git-pull-with-automatic-rebase http://matthew-brett.github.io/pydagogue/rebase_without_tears.html If I understand correctly, pulling automatically merges, which can create messed up history tree. However, you can do an automatic rebase when pulling. Maybe this is what causes the funny empty/nearly-empty "re-commits" Robert. I.e., I pushed commits to fieldtrip/fieldtrip, which you then pulled into one of your local clones, changed some stuff, and pushed again to fieldtrip/fieldtrip? Haven't found anything yet on ways to handle multiple copies from the same files (which we have in many private folders)
Robert Oostenveld - 2013-04-17 17:40:26 +0200
(In reply to comment #21) even separating it into a fetch and rebase brings tears to my eyes... Please have a kleenex tissue at hand and then check for yourself at http://code.google.com/p/fieldtrip/source/list I'll read the links though!
Roemer van der Meij - 2013-04-18 17:28:58 +0200
Ouch, that must have hurt. Hmmm, strange. In rev7986 https://code.google.com/p/fieldtrip/source/detail?r=7986 on google code, so the repo as how SVN sees it, contains git-merge conflict code. E.g., stuff like <<<<<<< HEAD ======= That stuff shouldn't have been in there, because the merge should not complete itself until the conflict is resolved right? Yet it ended up in the SVN repository... The git-clone that you use to get all changes automatically from git into SVN, is that one separate from the one you use to handle git-merges? If not, it might be the case that temporary git-code (like the above) accidentally get's put into the SVN repository, which then get's fed back into git after you resolved the conflicts (and thus removed the temp code). If so, maybe it's better to have a separate git-clone for the svn-merging (one that only get's updated after all merge conflicts have been resolved). Just a guess!
Robert Oostenveld - 2013-04-18 17:54:34 +0200
(In reply to comment #23) I have been trying to resolve it all sorts of ways, including continuing with merge conflicts in the files and fixing them afterwards. now again: the git master and svn trunk contain exactly the same files. Still I cannot do git pull origin master && git svn rebase without getting many conflicts. Even though I have already solved those conflicts 10 times! Somehow the git and svn history are out of sync. The files are ok, the history is not.
Robert Oostenveld - 2013-07-01 10:27:31 +0200
Although we need to continue the efforts, I think that it is fair to close this specific issue. Some of us have worked with it, and the major problems with two-way synching seem to have been resolved. I created bug 2214 to follow up on the synching and we should follow up to enhance our skills in specific follow up projects.