Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:

>  5. Copy those to to software-generated.git, removing any that we
> didn't just create, adding any that are new
>  6. Commit that, tag it with generated-deployment-YYYYMMDD-HHMMSS

>  9. Do git clean -dxf on software.git remove old generated files
>  10. Copy new generated files from generated-software.git to software.git
> For this I'll need to write some "git snapshot-commit" tool for #5 and
> #6 to commit whatever the current state of the directory is (with
> removed/added files), and hack up something to do #9-#10.
> This should all be relatively easy, I was just wondering if there was
> any prior art on this that I could use instead of hacking it up
> myself.

FWIW, dodoc script in my todo branch was hacked up to respond to my
push into k.org repository, pull 'master' into "documentation build
repo" at the k.org machine and check it out, build docs and then
"removing any that we didn't create, adding any that are new" to
update the html and man "branches", and push it back to the main
repository, so in that sense, it has all the logic that was needed
(and more, as the rebuilt documentation from two revisions may only
differ from version stamp asciidoc-to-html/man toolchain adds, which
need to be filtered out when updating html/man branches).

There no longer is post-update hook at k.org, so I have to run it
manually at the end of day's integration cycle, just before pushing
things out.

I wrote it myself, not because I looked for suitable reusable code
and didn't find any, but because I was too lazy to look for existing
tools and evaluating them.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to