[GRLUG] Git 'philosophy'

Zach Dennis zach.dennis at gmail.com
Mon Jan 4 21:56:21 EST 2010


On Thu, Dec 31, 2009 at 5:38 PM, L. V. Lammert <lvl at omnitec.net> wrote:
> At 07:32 PM 12/29/2009 -0500, you wrote:
>
>>You can have as many repositories as you want. Each repository will
>>typically have a *master* branch.
>
> Follow up, .. thanks for all the replies! I have 'git clone'd' two
> repositories to use:
>
> my working reposity -> my local repository to share among machines ->
> production master
>
> Problem is, the local and master repositories do not 'see' changes as they
> are pushed; for the local, a 'git checkout master' is required to update
> the local pointer to HEAD, and a push from working to local does not send
> branches, .. for the produciton master, updates pushed from the local
> repository show "D" for the files I'm testing.

Some of my assumptions about what you're saying...

1. I think you are talking about changes from your local copy of a git
repository and a remote copy of the git repository. Above you mention
local and master repositories, but I don't think that's what you mean.

2. Both the local and the remote copies of the repository have a
master branch (well most likely).

3. I think you are suggesting that:
   a. When you push/pull changes you are not seeing changes unless you
specifically check out the branch.
   b. When you push changes it does not send all branches.

Since 1 and 2 are most likely just terminology, here's my take on 3a and 3b:

3a. When you clone a repository git actually stores both the local
copy and the remote copies. For example, if I run "git clone
http://some-repos.git" it will set you up with a local "master"
branch, a remote "origin" repository and a remote "master" branch from
the origin repository denoted as "remotes/origin/master". If you run
"git branch -a" you should see similar output (maybe you have other
branches you'll see to I don't know, depends on your repos). Now, the
remote copy you have locally needs to be synced with the actual remote
repository from time to time, this is what "git fetch" does. This
updates your local "remote" copy, ie: your "remotes/origin/master"
that you see when you type "git branch -a". Even if there are changes
you will not see them unless you merge those changes into a local
branch, typically your local "master" branch. Git works this way
because you can compare the commit histories of your local branch and
the remote branch before merging w/o having to be online. For
example... "git log master..origin/master" or "git log
origin/master..master" will compare the two branches for differences.

When you're ready to merge in changes the easiest thing to do is
simply "git checkout master ; git pull". I typically run "git pull
--rebase", but if you're not familiar with rebasing yet then don't
worry about it for now.

3b. When you run "git push" with no other arguments git will try to
apply a default push strategy to determine what to do. The possible
values are nothing, matching, tracking, and current. See "man
git-config" and search for "push.default" for a brief description of
each of these configuration settings. If you would like to push all
branches then you have to tell git that, ie: "git push --all" which
will try to push all refs under $GIT_DIR/refs/heads. See man git-push
for more information on --all option.


>
> Is there a special way/mode to run the *repositories*? [In this case, they
> would actually BE true repositories, they are only used to store changes.]

I'm not sure what you mean "run the repositories" or "BE true
repositories". If you could clarify perhaps we can be or more help.

I'll end this email on this note. Outside of running some kind of
cronjob or daemon to constantly fetch and sync a remote repository
with a local repository I am not aware of any way to have git run as a
daemon to constantly be fetching changes. You can definitely set this
up. I know we use hooks provided by git when we push to a particular
remote repository to a whole slew of things, from updating tickets in
Pivotal Tracker, to running continuous integration, to sending out
instant message notices, etc.

>
>         Happy New Year!

Same to you! Hope this has been helpful and clarifying opposed to long
and confusing,


-- 
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)


More information about the grlug mailing list