On Fri, May 8, 2009 at 7:30 AM, Filippo Argiolas <fargio...@gnome.org> wrote: > On Thu, May 7, 2009 at 2:23 AM, Behdad Esfahbod <beh...@behdad.org> wrote: >> On 05/06/2009 07:00 AM, Simos Xenitellis wrote: >>> >>> On Tue, May 5, 2009 at 4:41 PM, Behdad Esfahbod<beh...@behdad.org> wrote: >>>> >>>> On 05/05/2009 01:28 AM, Shaun McCance wrote: >>>> >>>>>> This assumes that the branch is merged into master otherwise. I >>>>>> strongly >>>>>> suggest cherry-pick instead of merge. >>>>> >>>>> Isn't that going to cause merge conflicts for me the >>>>> maintainer when I try to merge from my stable branches >>>>> to master? I can pretty much guarantee I will always >>>>> do that. If I have to deal with merge conflicts from >>>>> one of 100 translations each time, I'm not going to >>>>> be happy. >>>> >>>> I *think* if the same commit exists in the destination, it doesn't cause >>>> a >>>> merge conflict. But I didn't test it to make sure right now. >>> >>> I have tried a few scenarios with 'git merge' and I managed to get a >>> situation that merge could not take place. >>> After that, it was not possible to commit and the message was too >>> cryptic to figure out what to do. >>> In terms of usability for this process, it was good (I was blocked >>> from messing up further), >>> so I resorted to the HowTo item from live.gnome.org named 'Ok, I >>> messed up, what do I do' in order to reset my clone. >>> >>> As a workflow, I find that the following is easy to follow >>> 1. First commit to your branch (such as gnome-2-26) as normal. >>> 2. Then, checkout 'master' and 'git merge gnome-2-26' >>> 3. Observe that no errors appear and that only your changes are merged. >>> 4. Do a 'git push' to push your work to git.gnome.org. >> >> What if the branch was not merged, perhaps intentionally? Now the >> translator will be pushing code changes. > > I'd like to stress Behdad's point here: merging stable into master is > not something a translator should even consider to do, it is a > maintainer's job, and most of all it is potentially harmful. > While it could be a common practice that changes to the stable branch > are merged back into the development one there is absolutely no > warranty about it. > Stable and master are two separate lines of development, there could > be large portions of code that have been removed, whole files deleted. > Just try git merge gnome-2-26 with epiphany for example you will see > tons of code changes getting merged with your translation some file > that was removed is restored etc. Fortunately this merge fails but it > could success if there are less deep changes between the two branches. > So *please* remove that merge reference from the translator's howto. > git cherry-pick is the way to go. > git commit returns the hash of the commit if it succeeds so I don't > think it is so difficult to copy and paste it into the cherry-pick > command line.
OK, I have updated the instructions at http://live.gnome.org/TranslationProject/GitHowTo#head-0a9ee3ff743fcd06eb70ab98c93780c48d724a1f I copy here: # We assume you checked out the branch gnome-2-26 and you updated your LL.po, and you are about to commit the change as normal. $ git commit -m "Updated Greek translation" el.po [gnome-2-26 4d7a0af] Updated Greek translation 1 files changed, 3 insertions(+), 3 deletions(-) $ git checkout master Switched to branch "master" $ git cherry-pick 4d7a0af Finished one cherry-pick. [master fdb65b4] Updated Greek translation 1 files changed, 3 insertions(+), 3 deletions(-) $ git push Counting objects: 12, done. Delta compression using 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 745 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://si...@git.gnome.org/git/yelp/ 9861647..4d7a0af gnome-2-26 -> gnome-2-26 152258a..fdb65b4 master -> master $ _ Thanks for picking up this issue, Simos _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n