Re: git: using branches
Which version is the new one? 1.6.2.x? Because I have a 1.6.0.x and it doesn't allow me to skip the -b and the local branch name. Cheers, El ds 18 de 04 de 2009 a les 00:07 +0100, en/na Simos Xenitellis va escriure: On Fri, Apr 17, 2009 at 10:41 PM, Jason D. Clinton m...@jasonclinton.com wrote: On Fri, Apr 17, 2009 at 4:29 PM, Simos Xenitellis simos.li...@googlemail.com wrote: Is the '--track' parameter required when using 'git checkout'? My git-config manpage says its on by default and it has been that way for as long as I've been using git. The issue about --track and -b _branchname_ is a bug in Git, http://kerneltrap.org/mailarchive/git/2008/10/19/3723354 So, with old/all git versions, $ git checkout -b composer-dev origin/composer-dev Branch composer-dev set up to track remote branch refs/remotes/origin/composer-dev. Switched to a new branch 'composer-dev' $ _ With old git versions, if you try to omit -b branch, you get $ git checkout --track origin/compose-dev fatal: git checkout: --track and --no-track require -b $ _ With newer git version, $ git checkout --track origin/composer-dev Branch composer-dev set up to track remote branch refs/remotes/origin/composer-dev. Switched to a new branch 'composer-dev' $ _ So, if you have the latest version of git, you do not need to specify the local branch in the command line. I think the new system looks cleaner and less error-prone. For now, we keep the old syntax at live.gnome.org. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
Hi,
I have some questions/doubts/things I can't understand quite well right
now with git and how to use branches.
I was trying to commit+push a new Italian translation for gtk+ 2-16
branch, since looks like it has one string left:
http://l10n.gnome.org/vertimus/gtk+/gtk-2-16/po/it
I switched to origin/gtk-2-16 using this command:
git branch --track -b origin/gtk-2-16
Doing a 'git branch' I saw:
master
* origin/gtk-2-16
I downloaded the Italian file from damned-lies, 'git status' showed me
the modified file.
'git add po/it.po'
'git commit --signoff --author '
'git push'
Result: it said everything is up to date, nothing to push.
So I switched back to master, deleted the gtk-2-16 branch ('branch -D
origin/gtk-2-16'), re-checkedout the 2-16 and have done this:
git log
And I saw my last commit on 'master' while I'm on 'origin/gtk-2-16'. Is
this behaviour expected?
I have done also a 'msgfmt' on it.po, and the result is 997 translated
as 'master', but still I'm on gtk-2-16 and it should have been, for
Italian, 996 translated + 1 untranslated.
I double checked the PO-Revision-Date of the it.po in my local copy and
is the one I pushed on 'master', but 'git branch' says I'm on
'origin/gtk-2-16'.
What am I doing wrong here?
--
Milo Casagrande m...@casagrande.name
signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
2009/4/18 Milo Casagrande m...@casagrande.name:
Hi,
I have some questions/doubts/things I can't understand quite well right
now with git and how to use branches.
I was trying to commit+push a new Italian translation for gtk+ 2-16
branch, since looks like it has one string left:
http://l10n.gnome.org/vertimus/gtk+/gtk-2-16/po/it
I switched to origin/gtk-2-16 using this command:
git branch --track -b origin/gtk-2-16
Doing a 'git branch' I saw:
master
* origin/gtk-2-16
This should be:
master
* gtk-2-16
I downloaded the Italian file from damned-lies, 'git status' showed me
the modified file.
'git add po/it.po'
If there is an existing it.po in the repository, it is not required to
'git add'.
'git commit --signoff --author '
The --signoff part is not required, so it can be omitted.
'git push'
Result: it said everything is up to date, nothing to push.
If you did a commit, then there should be something being pushed.
Did the commit above work? The command would have been something like
git commit it.po -m Updated Italian translation --author The Name
transla...@example.com
You can try 'git push --dry-run' for a test run of the push.
So I switched back to master, deleted the gtk-2-16 branch ('branch -D
origin/gtk-2-16'), re-checkedout the 2-16 and have done this:
git log
Normally, you do not erase branches of the 'origin/x' form.
The 'origin/gtk-2-16' branch and anything 'origin/xx' reside on the server.
I had a look at http://git.gnome.org/cgit/gtk+/log/?h=gtk-2-16
and I notice that no deletion was pushed to git.gnome.org, so it's OK.
In general, you can keep the branches.
And I saw my last commit on 'master' while I'm on 'origin/gtk-2-16'. Is
this behaviour expected?
Something must have gone wrong when you tried to checkout the branch.
Can you verify which version of 'git' you have? If it is earlier than
1.6.1, then
the above 'checkout' command did not work as expected.
I have done also a 'msgfmt' on it.po, and the result is 997 translated
as 'master', but still I'm on gtk-2-16 and it should have been, for
Italian, 996 translated + 1 untranslated.
I double checked the PO-Revision-Date of the it.po in my local copy and
is the one I pushed on 'master', but 'git branch' says I'm on
'origin/gtk-2-16'.
What am I doing wrong here?
Something went wrong with the checkout and we need to update the instructions.
The branch should not be called 'origin/gtk-2-16' but rather 'gtk-2-16'.
You can try to checkout with the command at
http://live.gnome.org/TranslationProject/GitHowTo
which is
git checkout -b gtk-2-16 origin/gtk-2-16
('--track' is default when you use this syntax).
Then, 'git branch' should show
master
* gtk-2-16
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Sat, Apr 18, 2009 at 04:24:18PM +0200, Milo Casagrande wrote: Hi, I have some questions/doubts/things I can't understand quite well right now with git and how to use branches. I was trying to commit+push a new Italian translation for gtk+ 2-16 branch, since looks like it has one string left: http://l10n.gnome.org/vertimus/gtk+/gtk-2-16/po/it I switched to origin/gtk-2-16 using this command: git branch --track -b origin/gtk-2-16 I t should be: git branch --track -b gtk-2-16 origin/gtk-2-16 Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer signature.asc Description: Digital signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
Hi,
Il giorno sab, 18/04/2009 alle 16.08 +0100, Simos Xenitellis ha scritto:
If there is an existing it.po in the repository, it is not required to
'git add'.
Hmmm... my 'git help add' says I have to do it even if I modify one
file.
If I try to 'git commit' without 'git add' before, it says:
no changes added to commit (use git add and/or git commit -a)
and git will not do the real commit.
Normally, you do not erase branches of the 'origin/x' form.
The 'origin/gtk-2-16' branch and anything 'origin/xx' reside on the
server.
I had a look at http://git.gnome.org/cgit/gtk+/log/?h=gtk-2-16
and I notice that no deletion was pushed to git.gnome.org, so it's OK.
In general, you can keep the branches.
Something must have gone wrong when you tried to checkout the branch.
Can you verify which version of 'git' you have? If it is earlier than
1.6.1, then
the above 'checkout' command did not work as expected.
The version I'm using is 1.5.6.3
Something went wrong with the checkout and we need to update the instructions.
The branch should not be called 'origin/gtk-2-16' but rather 'gtk-2-16'.
You can try to checkout with the command at
http://live.gnome.org/TranslationProject/GitHowTo
which is
git checkout -b gtk-2-16 origin/gtk-2-16
('--track' is default when you use this syntax).
Then, 'git branch' should show
master
* gtk-2-16
Yes, that's where I was doing wrong, I was doing:
git checkout -b origin/gtk-2-16
and git automatically use master as the base of the checkout even if you
don't specify it, that's why I was seeing my last commit. My local
checkout was called origin/gtk-2-16 but was a copy of master.
If I didn't screw up things, now my commit should be visibile on
gtk-2-16.
Thank you for the help.
Cheers.
--
Milo Casagrande m...@casagrande.name
signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
Hi! Il giorno sab, 18/04/2009 alle 16.08 +0100, Simos Xenitellis ha scritto: If there is an existing it.po in the repository, it is not required to 'git add'. Hmmm... my 'git help add' says I have to do it even if I modify one file. If I try to 'git commit' without 'git add' before, it says: no changes added to commit (use git add and/or git commit -a) and git will not do the real commit. Yes, if you use git commit -a you can omit the add step and git will commit all changed files. Otherwise it will just commit the files you added to the commit (using git add). Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Sat, Apr 18, 2009 at 4:43 PM, Johannes Schmid j...@jsschmid.de wrote: Hi! Il giorno sab, 18/04/2009 alle 16.08 +0100, Simos Xenitellis ha scritto: If there is an existing it.po in the repository, it is not required to 'git add'. Hmmm... my 'git help add' says I have to do it even if I modify one file. If I try to 'git commit' without 'git add' before, it says: no changes added to commit (use git add and/or git commit -a) and git will not do the real commit. Yes, if you use git commit -a you can omit the add step and git will commit all changed files. Otherwise it will just commit the files you added to the commit (using git add). There are at least three options/workflows, A. Use 'git add' to specify the modified files to add when you commit, so that you can use 'git commit' without having to specify the files at the end. B. Just use 'git commit -a' so that any modified and already tracked files are committed. We do not need to 'git add' the modified files, just use when we have to add a new file in the repository. The issue here is if we modify some other existing file by accident, which would get committed. C. Just use 'git commit LL.po' so that we specify which file we want to add and commit, in one line. We do not need to 'git add' the modified files, just use when we have to add a new file in the repository. Since the translator's workflow is to add the initial translation file once, and then commit modifications, I think that [C] is a good workflow, and this is what is reflected at http://live.gnome.org/TranslationProject/GitHowTo Of course, any of these options are equally valid. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
2009/4/18 Simos Xenitellis simos.li...@googlemail.com: On Sat, Apr 18, 2009 at 4:43 PM, Johannes Schmid j...@jsschmid.de wrote: C. Just use 'git commit LL.po' so that we specify which file we want to add and commit, in one line. We do not need to 'git add' the modified files, just use when we have to add a new file in the repository. Since the translator's workflow is to add the initial translation file once, and then commit modifications, I think that [C] is a good workflow, and this is what is reflected at http://live.gnome.org/TranslationProject/GitHowTo Of course, any of these options are equally valid. I agree, option C seems the best for translator purpose. Hoewver, I think could be good add a phrase like due to different behaviot betwenn git versions (1.5 vs 1.6), it's suggested to specify the filename of file to commit, using `git commit LL.po`. If this note is yet in wiki page, sorry for this spam :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
git: using branches
Hi all! I tried to follow the Git translators guide[1] to update the anjuta translation (which is already branched). So I git clone it and then I tried to switch to the gnome-2-26 branch but failed with the git checkout --track origin/gnome-2-26 command. After some research I finally found something that works: git checkout -b local-gnome-2-26 origin/gnome-2-26 With this, git creates a local branch named local-gnome-2-26 from origin/gnome-2-26 remote branch. Then edit files, git commit and git push as usual. I have git 1.6.0.6, don't know if it has changed with previous or newer versions. Should I update the working with branches section with this commands? Cheers, [1] http://live.gnome.org/GitMigration/Translators -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 12:59 PM, Gil Forcada gforc...@gnome.org wrote: Hi all! I tried to follow the Git translators guide[1] to update the anjuta translation (which is already branched). So I git clone it and then I tried to switch to the gnome-2-26 branch but failed with the git checkout --track origin/gnome-2-26 command. After some research I finally found something that works: git checkout -b local-gnome-2-26 origin/gnome-2-26 With this, git creates a local branch named local-gnome-2-26 from origin/gnome-2-26 remote branch. Then edit files, git commit and git push as usual. I have git 1.6.0.6, don't know if it has changed with previous or newer versions. Should I update the working with branches section with this commands? Thanks for catching this (-b 'branch'). Feel free to update the Wiki page. Just a note, the page has been moved to http://live.gnome.org/TranslationProject/GitHowTo Cheers, Simos Cheers, [1] http://live.gnome.org/GitMigration/Translators -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
I hope so too, but my small research ended up with this that at least works by now :) Cheers, El dv 17 de 04 de 2009 a les 14:23 +0200, en/na Luca Ferretti va escriure: 2009/4/17 Gil Forcada gforc...@gnome.org: Should I update the working with branches section with this commands? I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... BTW there is no way to produce a ligthweight local copy? I.e. only the latest versione of a single branch, instead full history form all branches for a given module. Could be good for simple commits like like this, waiting for commit support in damned-lies. -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 1:23 PM, Luca Ferretti elle@libero.it wrote: 2009/4/17 Gil Forcada gforc...@gnome.org: Should I update the working with branches section with this commands? I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... BTW there is no way to produce a ligthweight local copy? I.e. only the latest versione of a single branch, instead full history form all branches for a given module. Could be good for simple commits like like this, waiting for commit support in damned-lies. We have mentioned these some time ago. Search for 'shallow' clones. It's the '--depth' parameter in 'git clone'. My personal view is that a shallow clone (that is, a clone with limited history) provides small gains. More comments and benchmarking on this would be welcome. I think that it is better to get full clones of the GNOME release repositories and simply keep them locally, and update (with git pull --rebase) before committing. My view is to propose to the GNOME translators to dedicate around 2GB for permanent local GNOME repositories, for those that wish to keep using the command line. I plan to update my script at http://github.com/simos/intltool-manage-vcs/tree once git.gnome.org stabilises, so that you can simply let it run and it gets the repos for you. Another option would be to have anonymous git repository tarballs, so that you can wget in one go (or have then sent by DVD), then extract and use a git command to convert from anonymous to repositories with your account details. This would require some talk at gnome-infrastructure to see if the benefits are enough to put this in place. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
Simos Xenitellis ha scritto: We have mentioned these some time ago. Search for 'shallow' clones. It's the '--depth' parameter in 'git clone'. My personal view is that a shallow clone (that is, a clone with limited history) provides small gains. More comments and benchmarking on this would be welcome. git clone help says also that you cannot push after cloning with a --depth option, whereas Git for GNOME translators says it's (almost?) OK: has it been tested? I'm not keen on being a guinea-pig for this... :) I'm not really interested in ten years of repository history for pushing a couple of files, plus add to that if I also have to locally clone the repository... I think that it is better to get full clones of the GNOME release repositories and simply keep them locally, and update (with git pull --rebase) before committing. What is the status of damned-lies commit-upload of translations? This, from my POV, would be the best solution. Cheers. -- Milo Casagrande m...@casagrande.name ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
2009/4/17 Luca Ferretti elle@libero.it: 2009/4/17 Gil Forcada gforc...@gnome.org: Should I update the working with branches section with this commands? I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... Uh, so assuming this comment is in reference to the way SVN works, how did you commit to a branch without creating a local working copy in SVN? SVN: svn co url-to-branch svn commit Git: git checkout --track -b mybranch origin/somebranch git commit git push It's not like those really differ in other ways than in that with git you only keep a single working copy at any given time... -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
Simos Xenitellis ha scritto: In practice the space difference is not significant. We should be able to have real statistics on this soon, so that we can have a proper guideline on shallow clones. That would be interesting, at least to have an idea of what to expect. AFAIK, the standing issue is the creation of a generic account that damned-lies will use when committing on behalf of the translators. I asked 'cause I hoped something had changed in that front since last time... There Accounts team is understaffed and several requests take long to be fulfilled. There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. I would be happy to lend a hand... how is that suppose to work? -- Milo Casagrande m...@casagrande.name ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 3:51 PM, Milo Casagrande m...@casagrande.name wrote: Simos Xenitellis ha scritto: In practice the space difference is not significant. We should be able to have real statistics on this soon, so that we can have a proper guideline on shallow clones. That would be interesting, at least to have an idea of what to expect. AFAIK, the standing issue is the creation of a generic account that damned-lies will use when committing on behalf of the translators. I asked 'cause I hoped something had changed in that front since last time... There Accounts team is understaffed and several requests take long to be fulfilled. There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. I would be happy to lend a hand... how is that suppose to work? Have a look at http://live.gnome.org/AccountsTeam There was a call on planet.gnome.org recently, however I think it replicated the information you can find on the accounts team. Thanks, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
2009/4/17 Kalle Vahlman kalle.vahl...@gmail.com: 2009/4/17 Luca Ferretti elle@libero.it: I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... Uh, so assuming this comment is in reference to the way SVN works, how did you commit to a branch without creating a local working copy in SVN? Oh, no, my comment was in reference to the way MY MIND works ;) I mean, my mind expects something like those (fake) commands: $ dcvs clone module $ cd module $ dvcs where-i-am branch: master $ dvcs switch revision-2-26 $ dvcs where-i-am branch: revision-2-26 In my mind a new local branch should be creaed only if you plan to work on a large feature, not just to commit a small change or existing patch. But of course this is my own vision of DVCS. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 8:55 PM, Luca Ferretti elle@libero.it wrote: 2009/4/17 Kalle Vahlman kalle.vahl...@gmail.com: 2009/4/17 Luca Ferretti elle@libero.it: I hope there is a more simple way to do this. This seems a nonsense to me: create a new local branch in order to commit+push on an existing branch on server... Uh, so assuming this comment is in reference to the way SVN works, how did you commit to a branch without creating a local working copy in SVN? Oh, no, my comment was in reference to the way MY MIND works ;) I mean, my mind expects something like those (fake) commands: $ dcvs clone module $ cd module $ dvcs where-i-am branch: master $ dvcs switch revision-2-26 $ dvcs where-i-am branch: revision-2-26 In my mind a new local branch should be creaed only if you plan to work on a large feature, not just to commit a small change or existing patch. But of course this is my own vision of DVCS. When you 'git checkout' another branch, you perform an offline process. All the relevant information is already in the history, locally. Regarding the issue of having to specify the 'local branch name', I suppose there must be some story behind the question 'Why do we specify the branch name instead of reusing the remote branch name by default? It feels somewhat weird.'. With a big more experience we should be able to figure it out. In any case, any issues that come up, albeit simple, should be discussed so that we add it to the Git HowTo page on live.gnome.org, http://live.gnome.org/TranslationProject/GitHowTo Usability issues are very important too. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 3:09 PM, Simos Xenitellis simos.li...@googlemail.com wrote: I suppose there must be some story behind the question 'Why do we specify the branch name instead of reusing the remote branch name by default? It feels somewhat weird.'. With a big more experience we should be able to figure it out. For ease of use, DO NOT use a different local branch name. It will cause 'git push origin local-branch-name' (without other args) to create a new branch on the remote side named after your local branch. This is not what you want (and then you have to find someone to delete your mistake). If you name the local branch exactly the same as the remote tracking branch, 'git push' will just magically work correctly. So ALWAYS do: $ git checkout -b remotename origin/remotename ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 10:21 PM, Jason D. Clinton m...@jasonclinton.com wrote: On Fri, Apr 17, 2009 at 3:09 PM, Simos Xenitellis simos.li...@googlemail.com wrote: I suppose there must be some story behind the question 'Why do we specify the branch name instead of reusing the remote branch name by default? It feels somewhat weird.'. With a big more experience we should be able to figure it out. For ease of use, DO NOT use a different local branch name. It will cause 'git push origin local-branch-name' (without other args) to create a new branch on the remote side named after your local branch. This is not what you want (and then you have to find someone to delete your mistake). If you name the local branch exactly the same as the remote tracking branch, 'git push' will just magically work correctly. So ALWAYS do: $ git checkout -b remotename origin/remotename Is the '--track' parameter required when using 'git checkout'? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 4:29 PM, Simos Xenitellis simos.li...@googlemail.com wrote: Is the '--track' parameter required when using 'git checkout'? My git-config manpage says its on by default and it has been that way for as long as I've been using git. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On 4/17/09, Simos Xenitellis simos.li...@googlemail.com wrote: [...] There Accounts team is understaffed and several requests take long to be fulfilled. In general, only those with missing/erroneous/incorrectly filled in data. Or requests regarding teams with coordinators that forgot their Mango passwords (http://live.gnome.org/MangoFAQ). A correctly filled in Mango account request, for a team where the team coordinator remembers their Mango password, should not take more than 1-2 weeks to resolve, at the most. Mostly because I only have time to do GNOME work on spare time on weekends :-( There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. Don't I count? But more help is very welcome. I started out helping with accounts many years ago because I wanted to do exactly that; help resolve as many translator account requests in a speedy manner as I could. Nowadays, there's essentially just me doing almost *all* account work for all of GNOME. :-( Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 11:28 PM, Christian Rose ment...@gnome.org wrote: On 4/17/09, Simos Xenitellis simos.li...@googlemail.com wrote: [...] There Accounts team is understaffed and several requests take long to be fulfilled. In general, only those with missing/erroneous/incorrectly filled in data. Or requests regarding teams with coordinators that forgot their Mango passwords (http://live.gnome.org/MangoFAQ). A correctly filled in Mango account request, for a team where the team coordinator remembers their Mango password, should not take more than 1-2 weeks to resolve, at the most. Mostly because I only have time to do GNOME work on spare time on weekends :-( There was a call for volunteers recently and actually it would be great to have a GNOME translator on this team to push forward the translator requests. Don't I count? Sorry, I did not notice you in the Account Team list! But more help is very welcome. I started out helping with accounts many years ago because I wanted to do exactly that; help resolve as many translator account requests in a speedy manner as I could. Nowadays, there's essentially just me doing almost *all* account work for all of GNOME. :-( I'ld be happy to apply as well. I am e-mailing AccountsTeam. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git: using branches
On Fri, Apr 17, 2009 at 10:41 PM, Jason D. Clinton m...@jasonclinton.com wrote: On Fri, Apr 17, 2009 at 4:29 PM, Simos Xenitellis simos.li...@googlemail.com wrote: Is the '--track' parameter required when using 'git checkout'? My git-config manpage says its on by default and it has been that way for as long as I've been using git. The issue about --track and -b _branchname_ is a bug in Git, http://kerneltrap.org/mailarchive/git/2008/10/19/3723354 So, with old/all git versions, $ git checkout -b composer-dev origin/composer-dev Branch composer-dev set up to track remote branch refs/remotes/origin/composer-dev. Switched to a new branch 'composer-dev' $ _ With old git versions, if you try to omit -b branch, you get $ git checkout --track origin/compose-dev fatal: git checkout: --track and --no-track require -b $ _ With newer git version, $ git checkout --track origin/composer-dev Branch composer-dev set up to track remote branch refs/remotes/origin/composer-dev. Switched to a new branch 'composer-dev' $ _ So, if you have the latest version of git, you do not need to specify the local branch in the command line. I think the new system looks cleaner and less error-prone. For now, we keep the old syntax at live.gnome.org. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
