Re: [Libreoffice] Some hints about git please...

> 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.