Re: [translations] lost committishes [WAS Re: Doc-it: revision of snippets in LM (please backport to 2.14)]

[Francisco Vila <paconet.org@xxxxxxxxx>]

2011/8/8 Federico Bruni <fedelogy@xxxxxxxxx>:
>> Something that would work instead is this: you publish your
>> translations and the result of makelsr as a patch.  When the commit
>> from your patch is online in Savannah, reset and pull, then take its
>> commit ID from your updated tree. Check that this commit ID is the
>> same as on Savannah.  Then you can fix the committishes of your
>> translations taking this published ID as a valid one.  make check
>> should work properly without bad object errors and it should not show
>> any diff for updated files.
>
> This method requires one more patch, right?

I think no, just two as before, but you should wait before doing the
second one until you have a published commit ID for you to put in your
translated files.

> There's a way to avoid that?
> For example, what if I used the last committish of the snippet I'm
> translating (as I normally do with all the files)?

For normal texinfo files, this is correct. Do 'git log <file>' and put
this in your translation.  'Git log <file>' should give you a
trustworthy log for the original file if your tree is in sync with
Savannah.

For LSR texidocs, it's a different problem. It does not work the same.
You are translating files, then running makelsr.py, then committing
the result, and finally putting the commit ID of that result in your
translations. It is impossible to do all in a single commit.  You need
to commit the result of makelsr.py and know its commit ID
_beforehand_. Then put it, then make another commit for this.  If this
is what you are referring to when talking about another commit, then
yes, it does need another commit.  Two commits in total.

> I think that this issue would deserve some lines in the CG.

I agree.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com