--- Begin Message ---
Will Coleda wrote:
On Tue, Aug 5, 2008 at 11:04 AM, Kevin Tew <[EMAIL PROTECTED]> wrote:
Git is really nice for:
local branches,
This is on par with svk...
frequently(daily) rebasing local branches to keep in sync with HEAD,
How does this work? What's the pain threshold?
git knows which changes came from say svn.perl.org and which changes you
made in your local branch.
git-rebase removes all your local changes applies the new changes from
svn.perl.org and then reappGit is not that different from patches, the
pain threshold is just much lower.
lies your local changes giving you the opprotunity to edit each local
change if a conflict occurs while they are being reapplied.
publishing local branches for others to review,
Is this something that we'd host near the svn repository? On a machine
like feather? Wherever a developer wanted? (How would we advertise?)
Yes, Yes, and Yes.
With git, branches (ie patch sets) are just like html pages.
It doesn't really matter where they live. The url just has to be
publicly accessible if you want others to see the content.
allowing non-committers to make changes and publish those changes
publicly
So, like patches in RT, but closer to the 'metal', as it were?
The web analogy isn't perfect, but I like it so I'm going to stretch it
further.
Git is like a web-browser for source control changes.
Once I have the url for a branch I'm interested in, I can track that
branch and see the new changes on that branch each time I "browse"
to it.
Patches are like saving the raw html source of a web page and sending it
via email to let a co-worker know about this cool new web site I found.
Patches are a one-time snapshot of the work, they don't allow me to
continue to track its progress.
The pain of patches is kinda analogous to having to save raw html out
of an email to disk every time I want to visit a web site.
Git drastically reduces the pain threshold of implementing the patch
model of development.
Kevin
--- End Message ---
