> I'am very new to git (only have used sometimes 'git clone' before) , and I don't get it very well...
I am brand new to git and I felt confused alot until I found this -- http://wiki.documentfoundation.org/Development#Using_Git_for_LibreOffice_development -- this ref explains many things and gives the base reference for git -- http://git-scm.com/ -- Go there. The Quick Start workflow there is how git is supposed to work. See the big tree eat all the little trees - cute and incredibly effective. Git is source control but it is different: git follows content not files - git produces a tree of different codebase versions - other scms do something more like slices and versions on a single branch. Old scm branch is work and a big deal - branching built into git. >1) I update the 'clone' directory often. No problem with that. The rawbuild directory is almost entirely symlinks back to clone so even if the code is accessed through rawbuild it is still the code under clone. Or by update did you mean pull? I apologize if I offend or am no help. I am replying to you because I feel that I have started to be able to use git and I remember well my recent confusion. Probably the best I can do is refer you to Dev wiki and scm workflow: they helped me get git in focus. >2) I've read that when updating 'clone', 'bin/g' must be run. I don't find any 'g' in ./bin/. The Development wiki page above gives the ga script. Get the scripts from there into your bin directory. Then you can run ga checkout <branch>, hack away here and there in modules, build, test, get happy then do ga status, ga branch, ga commit - all from rawbuild and subdirs. ga lets you do the git stuff for preparing/making a commit across the entire code base from anywhere in the source tree. The ga command lets you do each git action once for all - 'ga' is an all version of 'g' further improved by find-lo-bin to work within any of several copies of the whole LibO multi-project source tree. >3) I don't know how to update easily the source in 'build/libreoffice-3.2.99.2' There are parts of three plans for work and build flow + working directory in the LibO tree: past, present and future. It is being sorted out so expect it to change (soon?) - but for now rawbuild is the intended home base. >4) I edit code in 'clone/module' and 'git diff' from there but, for building, I have to go to 'build/>libreoffice-3.2.99.2/submodule' where I have done a local git, modify the patch (paths are too long in it >eg : a/module/submodule --> a/submodule), 'apply' it, 'build', 'apply -R', and if it's ok, get back to clone/>module and undo my work (with the editor or with 'apply -R') I am not sure what you are doing here - preparing a commit and then pulling?. I am sure there is an easier way. Look at the basic workflow on the scm site: it will work for you in LibO. When you can't pull because of changes then either commit them if they are keepers or in the (sub)module do git checkout <rel-path-to-file> to erase the changes or rest a touched file that needed no change. Doing ga checkout <branch> or ga checkout master can give you different versions of the codebase. I have barely started to learn about and use branches but already I like being on a branch better than working in master. >From a bug/brokestuff branch, with ga checkout master you can get right back to a clean slate where you can checkout a codecleanup or feature/project branch. Freedom to have Fun. I see now that branches can be used to manage various sets of commits that are in different development phases ('improve'/build/test/debug/rework/prepare/commit). I used to wonder why there was not more info on managing a mixture of commits from different projects: finally I get that branches keep them sorted so there is only a local mess for a particular project to clean up at commit time. I should've read more... I hope this helps and is not too far off. Really - use the Dev wiki and scm workflow. Another way git is different is that git was made by an excellent developer for the purpose of organizing collaboration instead of being the brainchild of packaging, qa or management to restrict the movement of code. I know git should be easy and helpful when I git it down. I am just starting to get git to work for me - but I am old and slow. I will be reading/re-reading and reading further into the git man for some time yet. Havin' a blast... LeMoyne JLCastle -- View this message in context: http://nabble.documentfoundation.org/Some-hints-about-git-please-tp1831160p1833798.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
