23 December 2008, 17:59

Hi!

Today I was working on my adminlang repository (it adds features allowing to translate Mahara thru the web interface). Basically, I did the following:

1) I rebased the branch "adminlang" against fetched master (1.1.0beta3)

2) I created new branch adminlang-1.0 off the recent 1.0_STABLE. Then I cherry-picked all commits from adminlang so the branch now behaves like Mahara 1.0.7 with the translation support.

(I am still learning git tricks - I believe that 2) can be done easily with git-rebase --onto or similar)

I was able to push both branches into http://repo.or.cz/w/mahara-contrib.git

But when I try to push adminlang to git.mahara.org I get an error message and I do not understand the problem. Can anybody help/comment? TIA

 This is the command and the output:

$ git push -v -f git+ssh://git.mahara.org/git/contrib/adminlang.git adminlang:adminlang
Pushing to git+ssh://git.mahara.org/git/contrib/adminlang.git
Counting objects: 4615, done.
Compressing objects: 100% (1505/1505), done.
Writing objects: 100% (4136/4136), 1.12 MiB | 58 KiB/s, done.
Total 4136 (delta 2978), reused 3597 (delta 2488)
error: denying non-fast forward refs/heads/adminlang (you should pull first)
To git+ssh://git.mahara.org/git/contrib/adminlang.git
 ! [remote rejected] adminlang -> adminlang (non-fast forward)
error: failed to push some refs to 'git+ssh://git.mahara.org/git/contrib/adminlang.git 

23 December 2008, 18:55

24 December 2008, 6:14

Hi David,

Many, many thanks. Your tool is very useful! Can stand to see it in the core.

Cheers and merry Christmas!

24 December 2008, 7:13

Hey David,

Rebases are good as long as you're not rewriting history that's already been pushed.

If you're rebasing local work on top of new changes from upstream, that's fine... but if you're rebasing upstream work on top of other upstream work, that's rewriting history and you can't push it (as it's not a linear fast forward).

git-rebase --onto is pretty cool and may be exactly what you want I think.  The docs have a pretty good explanation, I discovered it recently and it was exactly what I needed.

 Hope that helps! & thanks again for your adminlang patch ;)

24 December 2008, 9:37

Hey Penny, 

thanks for the comments. I haven't realized all these implcations of rebasing. I hope I did not screw up something too much as I'm pretty sure I used push --force at least once during my experiments :-/ 

Yep, I found git docs very useful, too. I have pluckered Git User's Manual into my Palm and it is now my good night reading under the pillow ;-) Still I am looking for some working procedures how to keep customized Mahara tree up-to-date. This requires not only new technical skills (ie. how to use git commands) but also the new style of development thinking - very different from what I used until now (Moodle centralized CVS). This might be a comment to Nico's post: actually there is no need to have adminlang features in the core distribution. All we need to do is to describe (in Mahara wiki) how to fetch and incorporate adminlang.git into a translator's installation.

24 December 2008, 10:40

Hey David,

Even with --force, the worst that would happen is that someone might need to reclone your repository.  It's generally not a good idea to do it, but not the end of the world :)

It's an interesting comment you make about workflow.  I've been using non-CVS version control for quite a while (gnu arch / tla before git) and I guess I just take this for granted.

If you're regularly  pulling changes from master into adminlang I don't think you really have any choice but to merge rather than rebase.   In general I think the rule to follow is: always rebase unless you're actually merging.  In the case of pulling new upstream changes, merging actually makes sense.

And about documentation - yup, definitely not our strongest point at the moment ;)  There's a lot of work to do to get the developer side of documentation up to scratch.

25 December 2008, 5:25

Hi David,

> This might be a comment to Nico's post: actually there is no need to have adminlang features in the core distribution. All we need to do is to describe (in Mahara wiki) how to fetch and incorporate adminlang.git into a translator's installation.

From a geek translator point of view, I think this could be ok. However, most potential translators are NOT geeks and for them git won't be an option :-( If we want more (a lot) of languages, we should think about an easier way.

Moreover, your solution wouldn't solve the problem of the installation of more languages in a Mahara site. Your patch enables the possibility to have lang packs in the data folder, which is IMHO necessary for a worldwide dissemination and adoption of Mahara in other languages. So we would need at least this very feature in Mahara core. 

Ciao and thanks for the work. 

26 December 2008, 7:23

26 December 2008, 10:06

23 December 2008, 20:44

I'm not sure if you should have rebased in the first instance. You probably should have merged master into your branch instead, given you actually did branch ages ago. The rebase might work, but it doesn't correctly describe what you're trying to do. Certainly, you should always abort a rebase if it causes conflicts.

I'm not exactly sure why you got that error but it might have been a result of your rebase. Anyway I see you fixed the problem now