Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] git feedback

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git feedback
  • Date: Fri, 28 Jul 2006 14:04:21 -0700

On Fri, Jul 28, 2006 at 12:08:53PM -0500, Jeremy Blosser wrote:
>
> On Jul 28, Ladislav Hagara [ladislav.hagara AT unob.cz] wrote:
>
> > Or only I have problems because it seems you all are happy with git.
>
> So far just you and Seth (and sometimes Andrew) have had some problems
> getting acclimated. These issues have mostly seemed to be around
> integrations and merges, but it seems to me to be familiarity problems more
> than lacking functionality. Others have done some pretty heavy
> integrations and liked how it worked. Yes, p4 supported our workflow
> model, but at least part of that was tautological in nature, since that
> workflow also in part came from p4. Give git some time and patience to
> learn how it wants to work. It's different, but several people who really
> liked p4 also really like git.

Frankly, I just didn't understand what git was trying to do, but after
Andrew and Jeremy explained things to me in IRC, and I actually sat down
and read the online docs (not just our guide), I'm getting more
comfortable with git. I still think git is very command-heavy (120+
commands, 20+ of which are commonly used by integrators, half dozen or
so used by non-integrators), but i can't say it lacks features. Where
it does lack conveniences, we've determined the problems to be tractable
-- meaning we can solve them with minor effort.

Regarding the perforce workflow, I also think the p4 workflow affected
our old workflow. I'm actually quite happy that in the future, we'll be
using cherry-picks _more_ than wholesale file integrates. Wholesale
file integrates just break more than a proper cherry-pick. for security
updates, I tended to do the ./... ../next-up/... itegrations because I
tended to want the latest version from upstream, not the correct fix
from our actual spell, so, yes, for you, that will be an issue that
you'll face until Arwed and/or I put together something to help automate
that. For actual spell bugfixing, we _should_ be using cherry-picking
(the old ...@change1,change2 (or ...@=change) notation in perforce), and
by default, that's what I hope the integrations will be, and something I
will be ingraining in our accepted integrators. With git, I also have
more flexibility to help automate our integration/patch testing
processes. When we get used to git more and more, it _will_ work better
for automation reasons. With p4 we didn't have as much of that openness
(although it too had commit hooks and things of that nature, but it
still wasn't as transparent). With p4 we also didn't have a
decentralized system. I can integrate that into our testing model if I
need to to make the process more scalable. Really, it's just that
flexible.

So, yes, we do need to get something working for ./.. ../next-up/...
style integrates for the version updates between branches, but that's
really a small issue compared to the benefits we haven't even begun to
realize.

I can't say it's all tautological, but as Jeremy said, "some" of it is
tautological.

Before we decide on git, the one thing I'd want is a list of things that
_will be done_ after the decision to go forward with individual
commitments and a timeline for when to expect those things with who will
do them within those timeframes. This way we can enumerate the
tractable problems and end up with a complete solution as far as we can
predict when the process is done.

As I haven't seen any intractable problems and the alternatives do have
intractable problems, I'm not opposed to moving to git.

I use perforce at work, so I do some pretty heavy integrations with it,
as Andrew did as well, so I have the "perforce" perspective down well.
I do miss some of the ease I have with perforce, but I don't think git
won't be able to have those same eases, and at least with git, we have
an opportunity to weak it toward our own workflows, and it happens to
_scale_ really well. That's a killer app for me, scalability.

Seth




Archive powered by MHonArc 2.6.24.

Top of Page