Re: [gentoo-docs-it] Breviario del traduttore?

[Daniele Segato]

On 02/06/2012 12:32 AM, HUjuice wrote:
>>> .git/hooks/pre-commit
>>> ------------------------------
>>> #!/bin/sh
>>> for i in $(git diff --name-only); do
>>>          if ! xmllint --valid --noout $i; then
>>>                  echo "Errori XML nel file $i"
>>>                  exit 0
>>>          fi
>>> done
>>> -------
>>> Secondo te si può migliorare?
>
>>
>> exit 0 mi pare dica "tutto ok"
>
> Ovviamente hai ragione. E poi manca un --cached (dentro la
> sostituzione di comando).
> .git/hooks/pre-commit
> ------------------------------
> #!/bin/sh
> for i in $(git diff --cached --name-only); do
>          if ! xmllint --valid --noout $i; then
>                  echo "Errori XML nel file $i"
>                  exit 1
>          fi
> done
> --------------------------------
> Un check globale, come dici tu, è anche meglio.


Allora..

prendendo dall'esempio di hook che ha git lo cambierei così:


#!/bin/sh
#
# XML validation of files that are about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.

if git rev-parse --verify HEAD >/dev/null 2>&1
then
         against=HEAD
else
         # Initial commit: diff against an empty tree object
         against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

# If you want to allow non-ascii filenames set this variable to true.
allownonascii=$(git config hooks.allownonascii)

# Cross platform projects tend to avoid non-ascii filenames; prevent
# them from being added to the repository. We exploit the fact that the
# printable range starts at the space character and ends with tilde.
if [ "$allownonascii" != "true" ] &&
         # Note that the use of brackets around a tr range is ok here, (it's
         # even required, for portability to Solaris 10's /usr/bin/tr), 
since
         # the square bracket bytes happen to fall in the designated range.
         test "$(git diff --cached --name-only --diff-filter=A -z $against |
           LC_ALL=C tr -d '[ -~]\0')"
then
         echo "Error: Attempt to add a non-ascii file name."
         echo
         echo "This can cause problems if you want to work"
         echo "with people on other platforms."
         echo
         echo "To be portable it is advisable to rename the file ..."
         echo
         echo "If you know what you are doing you can disable this"
         echo "check using:"
         echo
         echo "  git config hooks.allownonascii true"
         echo
         exit 1
fi

XML_VALIDATION=0;
TMP_FILE="/tmp/tmp_check.xml"
TMP_LOG="/tmp/tmp_check.log"
rm -f "$TMP_FILE" "$TMP_LOG" 2> /dev/null

for file in ${git diff-index --cached $against};
do
	filename=${basename "$file"}
	extension=${filename##*.}
	if [[ extension = 'xml' ]] ; then
		echo "checking XML: $file ..." >> "$TMP_LOG"
		# copy the indexed version in a temporary file
		git show :"$file" > "$TMP_FILE"
		xmllint --valid --noout "$TMP_FILE" 2>> "$TMP_LOG"
		RESULT=$?
		if [[ ! $RESULT ]] ; then
			echo "XML non valido: $file"
			XML_VALIDATION=2;
		fi;
		rm -f "$TMP_FILE"
	fi
done;

if [[ XML_VALIDATION -ne 0 ]] ; then
	LOG_FILE="/tmp/git-commit-hook-log_`date '+%y%m%d%H%M%S'`.log"
	mv "$TMP_FILE" "$LOG_FILE"
	echo "See $LOG_FILE for details"
	echo "If you want to ignore this errors re commit with --no-verify option"
	exit $XML_VALIDATION
else
	rm -f "$TMP_LOG" 2> /dev/null
	exit 0;
fi





> C'è anche da dire che questo controllo potrebbe essere troppo serrato.
> Un commit si può fare anche a metà lavoro (ma allora c'è git commit
> --no-verify).

si... vero

si potrebbe usare un pre-push hook

la differenza nello script sopra è il calcolo dell'${against}
mi dicevano di usare "@{u}" al posto di "HEAD"

e subito prima fare un git fetch per essere sicuri di avere l'ultimo 
aggiornamento

lo dicono qui:
http://fclose.com/p/linux/man/7-gitrevisions/
git help gitrevisions


non correlato ma per completezza:
http://book.git-scm.com/4_git_treeishes.html

> È proprio per queste cose che troverei utile un piccolo host di
> lavoro, invece di gitorious.

si può anche creare un altro mirror, magari su github per non restare 
appiedati se uno dei due va giù...

il problema è che poi sta a noi tenere i mirror in sincrono :)