Re: A few suggestions for http://live.gnome.org/TranslationProject/GitHowTo



On Mon, Mar 29, 2010 at 5:09 PM, Claude Paroz <claude 2xlibre net> wrote:
> Le lundi 29 mars 2010 à 11:36 +0200, Kenneth Nielsen a écrit :
>> Hello
>>
>> I was wondering if someone, someone more knowledgeable about git than
>> me, would add information to:
>> http://live.gnome.org/TranslationProject/GitHowTo about what to do
>> when you encounter this message:
>>
>> warning: You did not specify any refspecs to push, and the current remote
>> warning: has not configured any push refspecs. The default action in this
>> warning: case is to push all matching refspecs, that is, all branches
>> warning: that exist both locally and remotely will be updated.  This may
>> warning: not necessarily be what you want to happen.
>> warning:
>> warning: You can specify what action you want to take in this case, and
>> warning: avoid seeing this message again, by configuring 'push.default' to:
>> warning:   'nothing'  : Do not push anything
>> warning:   'matching' : Push all matching branches (default)
>> warning:   'tracking' : Push the current branch to whatever it is tracking
>> warning:   'current'  : Push the current branch
>>
>> Or possible show how to set it up right in the setup part of the guide.
>
> I suggest to add an entry in the troubleshooting section, suggesting the
> following:
> With recent versions of git, you have to indicate the default push
> method for your local branches. You will probably want to configure it
> this way:
> $ git config --global push.default tracking
>
> Does this sound correct to git gurus?

I am not a git guru. My view would be that it's better to have
'matching' instead of 'tracking'.

This option makes sense for translatros if they are committing to a
branch, as well to master.
If you are translating evolution for branch gnome-2-30, you normally
want to commit the same translation to master.

Here is a workflow,
1. Update/Clone a repository, for example 'evolution'.

2. Checkout the 'gnome-2-30' branch with

$ git checkout --track origin/gnome-2-30
$ _

3. Add the translation and commit it,
$ git commit -m "Updated Greek translation for evolution documentation" el.po
[gnome-2-30 afa65e1] Updated Greek translation for evolution documentation
 1 files changed, 23 insertions(+), 131 deletions(-)
$ _

4. Checkout master.
$ git checkout master
Switched to branch 'master'
$ _

5. Cherry-pick the 'afa65e1' commit,
$ git cherry-pick afa65e1
Finished one cherry-pick.
[master 3c1c071] Updated Greek translation for evolution documentation
 1 files changed, 23 insertions(+), 131 deletions(-)
$ _

6. Finally, perform a 'git push' and send both commits to
git.gnome.org in one go,
$ git push
Counting objects: 14, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.69 KiB, done.
Total 8 (delta 5), reused 0 (delta 0)
To ssh://simos git gnome org/git/evolution
   e8d32b7..afa65e1  gnome-2-30 -> gnome-2-30
   f84793e..3c1c071  master -> master
$ _

Both 'gnome-2-30' and 'master' succeeded, so we are fine.
Without 'push.default=matching', we would need to run 'git 'push'es
twice, once on each branch.

Simos

>> On another note, I assume there has been a ruling on this issue from
>> the same guide
>>
>> >Commit your changes
>> >
>> >... We probably will not have to update the ChangeLog file with Git. Watch this space for a final announcement.
>> >The issue is whether it would be sufficient to simply to use the commit message (the message you type with '-m').
>> >For translations, it would make sense to simply use the commit message.
>>
>> If someone knows about it, would they update that as well.
>
> Updated (no more ChangeLogs...).

-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]