Hi, On Sat, 30 Dec 2006, Daniel Tonda wrote:
> ¿The commitish id has changed for these files, this is the expected > behaviour? Yes. A commit in git is sort of a tag: It contains everything which makes up a revision. So, if you say "git commit", you actually construct a new state from the _whole_ tree. There is no such thing as a file version in git. (More technical: the commit _object_ contains the commit message, author and committer information, a pointer to the tree and pointer(s) to the parent commit(s). The commit id is a hash of the commit object, including the pointers. Thereby it really hashes _all_ ancestors, too.) > git-rev-head HEAD | head -1, which shows a different committish than the > previous, but git didn't complain, so I assume I'm doing it right. You meant "git-rev-parse", right? A much easier method to verify where you are is to say $ git show HEAD This gives you the commit id, the message and the patch of the last commit. > For each file: > scripts/check-translation.py <file> > git-update-index --add <file> Easier: $ git add <file> > Checked which files wer to be commited via git-status, and finally: > > git-commit -m "message" If you only added files, that is okay. If you also modified files, you can do one of these: 1) Easiest: "git commit -a -m 'message'". This tells git to commit all added and modified files (it will not add untracked files). If you deleted a tracked file, it will commit that, too. 2) More precise: "git commit -m 'message' <file1> <file2>". This allows you to exclude some modified files (if you want to commit them separately, for example). 3) Inconvenient: "git update-index <file1> <file2>; git commit -m 'message'". This is only for hardcore git hackers who want to live a hard life. > ¿After this commit, it is recommended to do the pull? Yes. Ciao, Dscho
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel