Wow, really helpful responses, thanks a lot.
I think having read all this that I'll do it manually. I'll still use
git to track my latex source and will commit to it as often as I like
and not worry about commit granularity. Whenever I've finished a
significant chunk I'll add a PDF of it to a manually edited web page
along with a description of what changed since the last time I added a
PDF. I can use git log etc to help write the manual changelog. My
supervisors can just look at this manually constructed page and if it
gets too big I'll just archive the oldest PDFs. I can tag the git repo
at the points where I add a PDF to the web page. I guess this is pretty
close to what software projects do with version releases and their
public website.
On Thu, Aug 27, 2009 at 01:41:04PM -0700, Sverre Rabbelier wrote:
If they only care about the pdf anyway, why not have a separate branch
to which you commit the pdf's instead?
Well I was thinking they'd look at the changelogs with the diffs showing
exactly what changed in the latex source files, which should be pretty
self-explanatory, but then when they wanted to read a whole chapter and
add comments to it they'd want the PDF not the latex.
I don't really understand the script Junio posted (not literate in sh)
but I think it might have something to do with copying changelogs over
from the source repo to a PDFs repo.
On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
As you can generate the PDF's from the latex then just hack gitweb to
let them download it from there.
Unfortunately gitweb is written in Perl. But I know what you mean, it
should in theory be possible for them to click on a 'Get PDF' link for a
particular revision that causes the PDF to be built and returned to
their browser.
In response to Matthieu and Paolo, I'm not sure I understand the git
internals involved in the discussion around merge --squash, I had a
feeling this would produce a 'merge' that git in some sense would 'not
know about', since it sounds complex and I don't understand it I don't
think I want to go there.
Thanks all
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:47:19
On 08/28/2009 03:37 PM, seanh wrote:
In response to Matthieu and Paolo, I'm not sure I understand the git
internals involved in the discussion around merge --squash, I had a
feeling this would produce a 'merge' that git in some sense would 'not
know about', since it sounds complex and I don't understand it I don't
think I want to go there.
Yes, the problem is that git does not track what happens when you do
"git merge --squash", which makes it harder to do merges after some time
(because of conflicts).
The solution I gave (and Matthieu explained how it works, even though
it's very technical) is a way to "explain" git what you did. If you try
it on a fake example with gitk, you should understand it better.
mkdir test
cd test
# import
git init
echo a > test
git add a
git commit -m1
# some changes happen in your local "fine grained" branch
git checkout -b local
echo b > test
git commit -a -m2
echo c >> test
git commit -a -m3 ##<<<
# the magic incantation brings those commit to master
# (first two commands) and teaches git what happened (last two)
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
# more local changes
sed -i s/b/d/ test
git commit -a -m4
echo z >> test
git commit -a -m5 ##<<<
# the magic incantation, again
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
Use gitk at the points indicated with ##<<<
It is actually very similar to what you chose to do. My commits to
master, in practice, are your tags. You may want to see how gitk's
graphs looks in both scenarios, and choose the one that you prefer.
Hope this helps!
Paolo
On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
quoted
As you can generate the PDF's from the latex then just hack gitweb to
let them download it from there.
Unfortunately gitweb is written in Perl. But I know what you mean, it
should in theory be possible for them to click on a 'Get PDF' link for a
particular revision that causes the PDF to be built and returned to
their browser.
What is unfortunate about that? Perl is a duct tape/swiss-army-knife
of the internet. Hacking gitweb to generate PDF's on the fly from
latex documents should be a fairly trivial hack, even if you aren't a
Perl hacker.
See:
http://search.cpan.org/~andrewf/LaTeX-Driver-0.08/lib/LaTeX/Driver.pm
for just one of many Perl modules to interface with with LaTeX.
Good luck.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
quoted
As you can generate the PDF's from the latex then just hack gitweb to
let them download it from there.
Unfortunately gitweb is written in Perl. But I know what you mean, it
should in theory be possible for them to click on a 'Get PDF' link for a
particular revision that causes the PDF to be built and returned to
their browser.
What is unfortunate about that? Perl is a duct tape/swiss-army-knife
of the internet. Hacking gitweb to generate PDF's on the fly from
latex documents should be a fairly trivial hack, even if you aren't a
Perl hacker.
I have a situation where I need to generae pdf's from files that are under
git. I have a git repository on by webserver that I push to and have a
trigger that regenerates the pdfs any time there is a push.
David Lang
On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
quoted
As you can generate the PDF's from the latex then just hack gitweb to
let them download it from there.
Unfortunately gitweb is written in Perl. But I know what you mean, it
should in theory be possible for them to click on a 'Get PDF' link for a
particular revision that causes the PDF to be built and returned to
their browser.
What is unfortunate about that? Perl is a duct tape/swiss-army-knife
of the internet. Hacking gitweb to generate PDF's on the fly from
latex documents should be a fairly trivial hack, even if you aren't a
Perl hacker.
I have a situation where I need to generae pdf's from files that are under
git. I have a git repository on by webserver that I push to and have a
trigger that regenerates the pdfs any time there is a push.
Actually this discussion makes me think that there is room for a hack
to gitweb to provide extensible and pluggable renderers of the files
in a repository. Such a framework would for instance provide for
syntax highlighting, PDF generation from latex files, etc.
Hypothetically it wouldnt be too hard to do. A Win32 (dare I say)
registry of file extensions/shebang lines would be linked into a set
of renderer plugin's, which in turn would automatically add the
required links to render the file as needed. Quite doable actually.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"