On Wed, Jun 3, 2009 at 12:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
>> Does that make sense?
>
> Maybe, but it still seems messy, brute force, and error-prone.
>
> I can't escape the feeling that we're missing something basic here.
> It's allegedly one of git's great strengths that it allows you to easily
> and quickly switch your attention among multiple development branches.
Well as long as the development branches are all "compatible" in the
sense that you don't nee to reconfigure and rebuild everything when
you switch then yes. Doing git-checkout to switch branches will work
fine for branches created to work on new code or review patches.
I really don't see what you mean by messy or brute force or
error-prone with regards to keeping a separate clone for each major
release. It's basically equivalent to having a CVS checkout for each
major release which you do now.
The main difference is that commit becomes a two step process --
commit to your repository, then push to the public repository. That's
three steps if you include the add but I suspect you're going to be
doing git-commit -a most of the time.
There's an advantage that you can commit several changes to your local
repo and push them all to the public repo together. That might be good
if you have, for example, a bug fix which requires an api change
elsewhere. You might want two separate commit messages and the ability
to merge one of them forward or back separately but not want to put
them in the public repo until both are available.
--
greg