[Potlatch-dev] Git starter?
Serge Wroclawski
emacsen at gmail.com
Wed Aug 31 14:13:37 BST 2011
On Wed, Aug 31, 2011 at 8:28 AM, Andy Allan <gravitystorm at gmail.com> wrote:
> Yes, but this was causing lots of issues, as I'm sure you remember.
> Think of it instead as being a much more relaxing way of developing -
> you can make your changes public without needing to worry about
> stepping on anyone's toes - I can (and frequently have) published
> half-working, half-finished things on a branch and asked others to
> take a look, or made a few commits on one topic before changing to
> another. Previously I'd need to make sure it was completely finished
> and polished or open the can of worms that was svn branching.
+1
The advantages are several fold.
1. You work in your sandbox, and when your work is ready, you show it off.
As Andy says, this is liberating. If a new feature takes a week, or a
month, no problem. I have my private branches. I can show them to some
people, not show them to others, etc. And when it's ready, I can make
a pull request back to the project maintainer, saying "Okay, this is
now ready to be put back to the canonical branch.
No worrying about permissions or access, or asking "May I please have
commit rights?" or not being able to save until the patch is
absolutely positively ready. As Andy says, it's more relaxed, and more
collaborative.
2. Private changes
There may be changes you make that either aren't applicable to all of
PL2 (or whatever project) or else are changes you don't want to share.
I have one of these; a stylesheet for a PL2 instance that would not be
appopriate for PL2 general use. I maintain my own repo, my own
branches, And in that way, I keep up to date without needing to be in
lock-step with Andy and Richard.
3. The canonical repo can change
Let's say that the PL2 team contracts brain slugs which make them slow
and unresponsive. PL2 languishes as a result, with no bug fixes and no
new features. But during this time, your branch is up to date, has bug
fixes and accepts new features.
Sooner or later, your repo will be the canonical repo.
A less extreme example might be that Andy wants to see a feature "in
action" before accepting it. Maybe you're on the bleeding edge and
he's a bit cautious.
I feel like we've been here before with Git. I hope this explanation
by Andy, with followup by me, explains why this is absolutely a great
direction for the project.
- Serge
More information about the Potlatch-dev
mailing list