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: "Arwed Merkatz" <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git and usability
  • Date: Fri, 07 Jul 2006 17:07:52 +0200

-------- 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.

> 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.

> 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.

> 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.

> 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.

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




Archive powered by MHonArc 2.6.24.

Top of Page