Re: Managing multiple branches in git

I think it all makes a lot more sense if you think of your local git  
clone as just a cache. The real repo is still separate in a real repo  
on a server.

In that mental model the equivalent of CVS "commit" is actually git  
push not git commit. And the equivalent of CVS update is actually git  
pull.

git commit is actually just adding another commit to your local cache  
that you can push to the real repo at your leisure.

This is just like the rest of the world has had to do using rsync cvs  
repos except we can actually git commit into our local cache instead  
of having to be careful not to ever commit anything.

-- 
Greg


On 2 Jun 2009, at 22:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Blowing away your working directory shouldn't result in loss of your
>>> entire project history.
>
>> Such an outcome could not possibly be less likely with any other
>> system than it is with git.  Every single developer has a copy of  
>> your
>> entire history, as does the origin server and the public mirror of  
>> the
>> origin server.
>
> If it's a public project, and discounting any private branches you may
> have had.  I don't see what's so unfathomable about "I'd like a clear
> separation between workspace and repository".
>
>            regards, tom lane
>
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers