Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] git and usability

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: Arwed Merkatz <v.merkatz AT gmx.net>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git and usability
  • Date: Fri, 7 Jul 2006 15:59:21 -0700

Fortunately, I was able to get stable released anyways by pushing
forward despite my late night bitchiness, but only with the help of
Andrew pushing me along...

(more below)

On Fri, Jul 07, 2006 at 05:07:52PM +0200, Arwed Merkatz wrote:
> -------- Original-Nachricht --------
> Datum: Thu, 6 Jul 2006 23:30:10 -0700
> Von: seth AT swoolley.homeip.net
> An: sm-discuss AT lists.ibiblio.org
> Betreff: [SM-Discuss] git and usability
>
> > As a real test for git, I'd like to get proficient at using Git as
> > powerfully as I used perforce.
> >
> > I think we need to really work on the git guide:
> >
> > http://wiki.sourcemage.org/Git_Guide
> >
> > It doesn't cover my normal use cases at all.
> >
> > 1) for example, cherry picking covers doing an entire file or a single
> > change, but not our normal case, how do I "cherry pick" an entire
> > spell/directory?
>
> There's no way to cherry-pick only one subdirectory of a bigger change
> directly, though you can fake that by using git-cherry-pick -n and then
> reset the non-wanted changes.
> To integrate a full directory from another branch, do the following:
> rm -r path/to/directory
> git-tar-tree <branch> | tar -xf - path/to/directory
> git add path/to/directory
> git commit -a
>
> I wanted to write a small script to do that in a way that also updates
> the index correctly, so you wouldn't need to use git commit -a, but
> haven't had the time to do that yet.

That would be cool when it's done. I had perforce scripts to handle all
the integrations I needed and I feel a little naked here :).

>
> > 2) we need an "integrate" script that properly checks that grimoire
> > functions get pulled up and gpg keys are validated upon integrate, and
> > any other inherited files don't conflict under the new inheritance
> > scheme. This could all be scripted up and we could maintain these tools
> > for ease of distribution work. It could even warn of potential
> > dependency mismatches with versions and generate a test list of spells
> > to test.
> >
> > 3) I don't know how to release the stable grimoire without Arwed's
> > modifications to my scripts, which were modifications of previous
> > scripts, etc, etc. This should be documented somewhere.
>
> I don't have a way to get those to you right now, but with the full
> grimoire in git, it's mostly just a matter of checking out the right
> branch, tar'ing that up and signing it.

I found your /home/arwed/scripts/update-grimoire script, made it create
the directories automatically, made it fail if a previous part failed,
made it not be so hardcoded by putting variables up on top, added my key
to it, and updated it to the latest versions. It worked great for me.
I dropped it into /home/swoolley/update-grimoire on fawkes.

>
> > 4) since git is so space efficient, git should be supported as a
> > first-class download utility for the grimoire so that we can drop rsync
> > and the convoluted hashsum scheme we have (although is there any way to
> > use a hash other than sha1 in git? -- if not that seems like a major
> > oversight.
> >
> > 4a) in a related vein, perhaps we need to make "release" branches such
> > as stable-rc-release and stable-release that are the live, "this is what
> > is published" branches. That would allow us to submit directly into
> > stable, delay release while final testing happens (mostly automated --
> > for security update and integrate sanity) and then ship the bits to
> > stable-release, where there's a trigger to actually tarball up the
> > trees.
>
> Not sure how much we can automate with automatic tarball generation
> due to the required gpg signatures. Having named branches for the
> current 'stable-release' and 'stable-rc-release' would be nice, all
> development would happen on the 0.x branches and once the tarball has
> been generated and uploaded, the named branch is set to the tree that
> was uploaded.

Of course. I like this idea, as well.
>
> > 5) Does anybody know of any _good_ documentation on git. The git
> > documentation is mostly "command docs" and a general philosophy. I need
> > a "general use case" or "best practices" guide. It's perhaps too
> > flexible for me to decide which way to do things.
> >
> > 6) And lastly, I would like to branch versions of the grimoire out and
> > delete branches later. The reason for this is that I'd like to maintain
> > security updates for older stable branches at least going back six
> > months. I think that amount of time is required for deployment in a
> > corporate environment. I'm not and we aren't necessarily the people to
> > do this maintaining, but if we store them back that far, at least others
> > can help maintain them and we can host the bits for their efforts. The
> > alternative is simply to rename the branches to the new version and
> > overwrite them (or delete the old branches very quickly -- I have no
> > idea which way is "better" in git philosophy, for example --
> > again there's no "best practices" document).
>
> Having that as official branches is certainly possible, additional
> branches in git are cheap. Maintaining them is obviously something the
> grimoire team currently lacks the resources to do.

Yeah, I just want it to be an option for those who desire to do this.

>
> > 7) cherry picking has a different strategy for local branches and remote
> > branches in the git guide? Why? Can we get those merged and explained
> > step-by-step? I don't learn anything from a paste of commands. I need
> > to know what those commands _do_. A paste of your insights doesn't let
> > me know how you got them.
>
> Don't know what that remote thing is about, since you usually have all
> remote branches as local ones, I don't see a difference in
> cherry-picking.

Then maybe that's a case we need to be less concerned about and simply
say yes, cherry-picking is local.

Seth

>
> Arwed
>
> > It's late, I've been planning on getting a stable update out now for a
> > couple weeks but have been too busy with scheduled events. I don't
> > think only Arwed and I should be responsible for releasing an approved
> > release if both of us are busy, we need to have a documented process...
> > granted, neither of us have done a full release on git before, and
> > that's slowing us down (at least me) -- it's a totally new process.
> > I'll have tons of time this weekend to get it done, but if somebody can
> > go through and answer some of my questions and rework the git guide a
> > bit, I'd much appreciate it.
> >
> > Seth
> > _______________________________________________
> > SM-Discuss mailing list
> > SM-Discuss AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>
> --
>
>
> Echte DSL-Flatrate dauerhaft f?r 0,- Euro*!
> "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss




Archive powered by MHonArc 2.6.24.

Top of Page