From: Martin Langhoff <martin.langhoff@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: offtopic: ppg design decisions - encapsulation
Date: Mon, 6 May 2013 11:34:28 -0400 [thread overview]
Message-ID: <CACPiFCL+cd1vmqj6JEj84L5rDvHGxDgo+zGw5__ard6-sumipA@mail.gmail.com> (raw)
[ Unashamedly offtopic... asking here because I like git design and
coding style, and ppg is drawing plenty of inspiration from the old
git shell scripts. Please kindly flame me privately... ]
ppg is a wrapper around git to maintain and distribute Puppet configs,
adding a few niceties.
Now, ppg will actuall manage two git repositories -- one for the
puppet configs, the second one for ferrying back the puppet run
results to the originating repo (were they get loaded in a puppet
dashboard server for cute webbased reporting). The puppet config repo
is a normally-behaved git repo. The "reports" repo is a bit of a hack
-- never used directly by the user, it will follow a store-and-forward
scheme, where I should trim old history or just use something other
than git.
So I see two possible repo layouts:
- "Transparent, nested"
.git/ # holding puppet configs, allows direct use of git commands
.git/reports.git # nested inside puppet configs repo
- "Mediated, parallel"
.ppg/puppet.git # all git commands must be wrapped
.ppg/reports.git
My laziness and laisses-faire take on things drives to to use the
transparent&nested approach. Let the user do anything in there
directly with git.
OTOH, the mediated approach allows for more complete support,
including sanity checks on commands that don't have hooks available. I
already have a /usr/bin/ppg wrapper, which I could use to wrap all git
commands, setting GIT_DIR=.ppg/puppet.git for all ops. It would force
ops to be from the top of the tree (unless I write explicit support)
and I would have to implement explicit. And it would break related
tools that are not mediated via /usr/bin/git (gitk!).
Written this way, it seems to be a minimal lazy approach vs DTRT.
Am I missing any important aspect or option? Thoughts?
cheers,
m
--
martin.langhoff@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
next reply other threads:[~2013-05-06 15:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 15:34 Martin Langhoff [this message]
2013-05-06 15:53 ` offtopic: ppg design decisions - encapsulation John Keeping
2013-05-07 14:32 ` Martin Langhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACPiFCL+cd1vmqj6JEj84L5rDvHGxDgo+zGw5__ard6-sumipA@mail.gmail.com \
--to=martin.langhoff@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).