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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers