Re: webwml in git?
* Peter Krefting <peter@softwolves.pp.se> [2008-09-17 14:16:34 CEST]:
> If webwml was to change to Subversion, I would most probably be using
> git-svn anyway, so for me, a native Git implementation is just as good.
Yes, git-svn might be an approach, not needing to use submodules. But
that means that the build scripts would have to work with _both_
approaches, or that www-master also uses git-svn. On the other hand,
that might solve the problem with the partial checkouts for translators,
though they'd have to update both trees (or a three, which stores all
the tools).
> The problem is handling the translation revision tracking, as Git does
> not have any numerical revision numbers. It can of course be solved,
> but it might be a bit more inconvenient for translators since it most
> likely will need to work with the big SHA-1 hashes.
Yes, and this should definitely be addressed with helper scripts that
make it as convenient for translators as it is currently. I don't see
much of a problem here, it's even better for the translators because
they can generate the needed diff offline directly. I know that it's
possible to trim down SHA-1 hashes to as few as still is unambigious,
but given proper tools that shouldn't be needed, and giving them a tool
that generates the diff for them is something that we want anyway
(extracting sha1sum from translation and checking against HEAD version
of the file).
I guess this also solves your question, Joy? ;)
And Osamu, no no NO. We do *not* want get extremely huge refs files. A
tag for every single file and every commit? Please think again what that
exactly means. :)
[submodules]
> I wonder how much can be saved doing that. I haven't really tested
> submodules that much, but we need to make sure that a "sparse" checkout
> of submodules work properly, since you most probably do need to have
> the superproject, English and your language checked out.
Haven't tested with submodules neither myself, but I've heard that a
master commit would be needed to merge the various submodule commits
back. While this might be automated through some hooks propably, it
still sounds fishy. From most people I rather have heard suggestions to
stay away from submodules, but I don't want to outrule them completely.
> > P.S.: Had done git-cvsimport -v -k -d
> > :ext:alfie@cvs.debian.org:/cvs/webwml -m -a webwml -C webwml.git
>
> You might want to try and create an authors file, to make the committer
> names look prettier.
I thought of that, originally. But then, people changed email addresses
over time, and it won't get a proper history. But at least adding full
names to it should be possible, yes.
> > P.P.S.: Yes, -k kills the keywords, but they aren't used by any scripts
> > TTBOMK, are mostly cosmetic from what I can see.
>
> Indeed. We don't need them with Git. With CVS they can be useful if you
> do off-line updates, Git doesn't have that problem since you have full
> history even off-line.
Yes. But, we won't be able to get an ID into a file. While this doesn't
disturb us here, for other projects this might be problematic because
questions like "what version of that file are you using?" aren't as easy
to answer, and git-hash-object works only on unmodified files.
So long. :)
Rhonda
Reply to: