On Sun, May 24, 2009 at 4:35 PM, Tirumurti Vasudevan <agnih...@gmail.com> wrote: > On Sun, May 24, 2009 at 4:35 PM, Simos Xenitellis > <simos.li...@googlemail.com> wrote: > >> These files were last modified in 2007. >> When you type 'git log thumbnailer/evince-thumbnailer-ps.schemas.in' >> you get >> ... >> Date: Sun Apr 8 15:34:43 2007 +0000 >> ... >> >> It is unclear why they would be modified in your case. > > well. one of the several mysteries of the world! > ------------------------- >> >>> d...@narayana:~/git/evince/po$ git reset --hard HEAD^ >>> HEAD is now at f9b57c7 [printing] Fixes crash found by tests >> >> This resets your working copy and takes away the last commit in the process. >> It is better just to try 'git reset --hard'. >> You would use 'git reset --hard HEAD^' if you know that your latest >> commit (which you did yourself and has not been pushed yet to >> git.gnome.org) needs to be taken away. > > yes, now that you mention it i went back to read and it is so. mistake is mine > --------------- >> >> This file should be added to '.gitignore' because Git should not track it. >> In any case, you can ignore the file as it is untracked. >> I wonder if the maintainer would be OK to add this to .gitignore >> directly (without going to bugzilla, etc). > > ok, i will ignore. > --------------- >>> d...@narayana:~/git/evince/po$ intltool-update ta >>> ............................................. done. >>> 299 translated messages, 11 fuzzy translations, 15 untranslated messages. > > Looks like i shd have run git pull --rebase again, right?
I think the previous command removed your commit, or something went wrong. When you are in doubt, it is good to clean up your local repository and make it match to what is available on git.gnome.org. That is 'git reset --hard' and then 'git up' (see below). >>> d...@narayana:~/git/evince/po$ >>> >>> ------------ >>> >>> so the translations done last time are not counted though in damned >>> lies it has been. >>> so from where is this file updated? >>> it says 299 strings not 318 as shown in da.lies >>> >>> if git reset --hard HEAD^""was a wrong command here, then what would >>> be when it refuses to pull? >> >> With 'git reset --hard HEAD^' you removed a commit, and most probably >> the commit you did with the translation. >> Tell me if http://live.gnome.org/TranslationProject/GitHowTo is >> unclear with the instructions when trying to fix the local git >> repository. > > yes, this refusing to pull rebase seems to have been added since i > read last. that is in right direction. On the issue of 'git pull --rebase', the documentation has a new alias so that you can simply run git up and you get 'git pull --rebase'. This should make it easier and less error-prone. See http://live.gnome.org/TranslationProject/GitHowTo and 'Configure your git'. > question is why does it refuse to rebase when i know the file in the > repository has changed? > or should i be using intltool-update ta command? 'git up' (git pull; git pull --rebase or 'pull' in general) only work when there are no uncommitted changes on tracked files. That is, when you modify a tracked file (such as ta.po which is already on the repository), you cannot 'pull', unless you commit. You need to perform the pull before you change files. Or you need to commit the changes and then try to pull. Simos _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
