Moodle in English: GIT help needed

GIT help needed

by Joseph Rézeau - Sunday, 6 February 2011, 12:56 AM

Hi all GIT gurus

I'd be grateful for help in achieving a scenario which I frequently use when testing things out on my moodle local test site.

hack one or more core files
test the hack
produce a patch file against original core file(s)
restore core files to their original state

Using ECLIPSE and CVS the scenario was very simple:

hack file(s)
test
right-click file(s) /team / create patch (and save patch file somewhere)
right-click file(s) / Replace with latest

Using GIT and TortoiseGIT

hack
test
"commit" file(s) (in GIT parlance, "commit" means something different from CVS; your commit remains in your local folder; I do not need to take the next action, which is called "commit" in CVS and "push" in GIT, because I do not have writing rights on the main moodle GIT repository, but I have to "commit" in order to produce the patch in the next step)
Create patch serial (and save patch file somewhere)
now what do I do?

In GIT scenario step 5 I need to "un-commit" my commit, but I am lost with the choice of options I am offered in the TortoiseGit interface. I do not understand if or how I should use "rebase", "revert", "stash", etc. All I desperately need is to just "restore" my files the way they were before I hacked them.

Thanks in advance to anyone who can suggest the solution, alleviating my feelings against the "unfriendliness" I still feel about GIT.

Joseph

Average of ratings: -

Re: GIT help needed

by Davo Smith - Sunday, 6 February 2011, 1:58 AM

Before you start hacking things in git, the best thing to do is to create a new branch, on the command line you type:

git checkout -b nameofmynewbranch

(I'm not sure what the TortoiseGIT version of this is).

Then you make your changes and commit them.

At that point, you can get a patch from the difference between the main branch and your changed branch.

To get back to the original code, checkout the main branch again ( git checkout nameofmainbranch ).

Average of ratings: Useful (2)

Re: GIT help needed

by Andrés Chandía - Tuesday, 19 July 2011, 4:15 PM

Hi there,

I'm new to git way of doing things, so I have a question, may be silly for you, but I haven't found the answer going around the docs and forums.

Ok, so if you start doing this

git clone git://git.moodle.org/moodle.git (1)
cd moodle

it's assumes you will use "moodle" directory as the root, but how to change it to a different one, so instead of going to "moodle" by "cd moodle" you go to, for example, "mystuff" by "cd mystuff" without braking the possibility of further updating by git, and besides instead of visiting http://exemple.com/moodle you can visit http://exemple.com/mystuff. I know I could do a link moodle > mystuff, but I have a previous installation of moodle called "moodle", I mean over the root directory "moodle"

I hope I could explain myself.

Thanks in advance.

Average of ratings: -

Re: GIT help needed

by Davo Smith - Tuesday, 19 July 2011, 6:42 PM

Try:

git clone git://git.moodle.org/moodle.git mystuff

cd mystuff

(If I understood your question correctly)

You can also quite safely do the following:

git clone git://git.moodle.org/moodle.git

mv moodle mystuff

Git stores all its settings in [checked-out-repository]/.git - so you can move / copy the main folder as much as you like without breaking anything.

Average of ratings: Useful (2)

Re: GIT help needed

by Howard Miller - Sunday, 6 February 2011, 3:49 AM

As Davo says, get familiar with branches in Git. You can switch to a branch make as much mess as you want and then switch back to the original branch without any fear of loosing anything.

Reading between the lines I sense some confusion (rather like the confusion I had starting with Git). The cvs commit and the git commit aren't really different at all. They commit your changes into the repository. It's the repository that is different (one is on your machine and one is a central cvs repository) NOT the commit.

It might be useful to explain why you want to create patches. I find it's one thing you rarely have to do with Git as you just keep each of your hacks in a branch. If your branch gets out of date with the Moodle version you can just merge in the latest version of Moodle (hopefully with no conflicts).

Keep asking the questions - it all becomes clear eventually. The trick is to forget everything you know about CVS. Don't say "I used to do it in CVS like this", say "I need to do this, how do I do it with Git".

Average of ratings: -

Re: GIT help needed

by Joseph Rézeau - Sunday, 6 February 2011, 5:33 AM

Many thanks, Davo and Howard for your help.

Thanks for the tip about creating branches. I'll try it out.

@Howard: there are several reasons why I need to create patches: for my own use, before I revert to the current moodle version; to post to the bug tracker to accompany a bug report; ...

Er, can I create as many branches as I want (on my local repository)? I might get confused as to what each one does...

Joseph

Average of ratings: -

Re: GIT help needed

by Howard Miller - Sunday, 6 February 2011, 5:46 AM

Yes - just go nuts. Create as many as you like. However, yes, as you cannot annotate them you have to give them sensible names so you don't get confused. I had a lot of trouble with that but I seem to have got more organised

Let's try a typical workflow, maybe (from memory)

 

$ git clone git://git.moodle.org:moodle.git    (get the repo)

$ cd moodle

$ git checkout -t origin/MOODLE_19_STABLE   (create branch that tracks 19 and check it out)

$ git branch (branch you are on is shown with a *)

$ git checkout -b joseph_hack (make and change to a new branch)



....... make lots of changes ...



$ git add      (as required)

$ git commit -m 'I made some changes'

$ git checkout MOODLE_19_STABLE     (back to stable branch with your changes safe on the other branch. If you work was bad you can just delete that branch, or..)

$ git diff MOODLE_19_STABLE..joseph_hack >hack.diff   (get your diff)

$ git branch    (see your branches now)

One of the problems with Git is that there are many ways to configure it and many ways to use it. Some are beyond comprehension but you can do loads with simple commands. Just make sure you *properly* understand how branches and revisions work and you'll be fine.

When you no longer need a branch just get rid of it with

 

$ git branch -d  branch_to_delete

It's very hard to visualise how each branch relates to each other so you really want to get one of the Git GUIs. The standard one is GitK but it sounds like you are using Windeez so you will need to see what there is. These are vital as they show you visually how the branches interrelate (when you have forgotten.... which you will)

Average of ratings: Useful (3)

Re: GIT help needed

by Tim Hunt - Monday, 7 February 2011, 12:26 AM

Instead of attaching a patch to a tracker issue, another options (which may be more convenient for people reviewing your code) is to have a public git repository where you put code you want other people to have access to.

For example, you could

Sign up for an account on https://github.com/.
Create a 'fork' of the https://github.com/moodle/moodle project.
Make a branch, do your fix, and commit it locally.
Push your branch with the commit to github.
Add a comment to the bug saying something like "patch to fix this at https://github.com/timhunt/moodle/commit/5f11e00db1c94c6993ea57fdbc319df1db36c94a"

I have found a good convention is to use the bug name as the branch name. For example https://github.com/timhunt/moodle/branches. When I am fairly sure my fix is the right one, I will just use the bug number as the branch name. e.g. MDL-26242. When I am not sure, and their may be some discussion about the right solution, I call the branch something like wip_MDL-24575 (work-in-progress).

Actually, names like MDL-26242 aren't very helpful. Petr has taken to using something a bit descriptive at the end of the branch name to help you remember what each branch is. I think I will start doing that. e.g. https://github.com/skodak/moodle/tree/wip_MDL-25966_20_yui330

One other thing, when you are making a patch with git, it can be better to use git format-patch, instead of git diff > file.txt. The reason is that git format-patch includes your commit comment, and some other useful information, at the start of the patch, and someone else can then apply that patch using git am.

Average of ratings: Useful (4)

Re: GIT help needed

by Pierre Pichet - Monday, 7 February 2011, 10:23 AM

Tim,

Thanks for your flow chart which is somewhat similar to a recent email.

However GIT is somehow difficult to understand about.

For example although we create a fork on our github site somehow when we clone on our personal computer we use the official moodle site.

As a beginner I cannot find one "NON OBSOLETE" page in moodle docs that give us more detailed instructions on each step.

Your doc pages are always well done so ...

Pierre

P.S. just notice the date of reply.

Is back to the future a reality?

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Monday, 7 February 2011, 4:44 PM

Git is a classic example where you should focus, not on understanding the algorithms, but on understanding the data structure.

For example, you have a misconception: "although we create a fork on our github site somehow when we clone on our personal computer we use the official moodle site".

Your error is thinking of this as an either-or choice. Your clone on your computer can be linked to more than one remote repository. Look at the "git remote command".

Suppose you originally did:

git clone ...moodle.org...

and that later you did

git remote add github ...github.com/ppichet...

Then you can do both

git pull origin

and

git push github

(The origin there is not necessary, because it is the default, but it makes it clearer that when you do a pull, you have to say where to pull from, and when you do a clone, the place you clone from is automatically set up as a remote called origin.)

Average of ratings: Useful (1)

Re: GIT help needed

by Pierre Pichet - Tuesday, 8 February 2011, 5:39 AM

Suppose you originally did:

git clone ...moodle.org...

and that later you did

git remote add github ...github.com/ppichet...

Unfortunately I did the reverse i.e. create the fork and cloning it to my computer.

As moodle docs were obsolete , I go to github use their instructions to create a fork and clone the fork on my computer, a normal reflex from CVS.

Things seem to go correctly, I could change some code and see the diff using the GitGui interface. However the fork on github was in the inital loading data in november and I did not see an easy way to update by using a pull.

If I use the pull button on GitHub which always respond as OK.

So I remove existing git directory and start with the master from moodle git.

Then things seem OK, the moodle head is actual and I can see every modifications I am doing using Git Guy.

Incidently I also learned to use Git Bash which is a console in which I can type git command the way you are doing.

So I resume to real coding on MDL-images in multiple choice and come back later when code is ready, to do a pull request.

Pierre

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Tuesday, 8 February 2011, 6:33 PM

Actually, it does not matter if you did the fork on github, and then cloned that.

You could always later do

git remote add moodle git://git.moodle.org/moodle.git

Then you can do

git fetch moodle
git checkout master
git merge --ff-only moodle/master
git push

to update what you have on github. The link Myles Carrick gave is really worth a read.

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Tuesday, 8 February 2011, 10:12 PM

Thanks for the git instructions and effectively "the link Myles Carrick gave is really worth a read" and more than once .

However each one has his own learning processes when facing complex things like CVS or GIT or any of the computer language I worked with in the last 50 years.

My own processes involve a mix of theory and practice and having some problems with GIT is what I can handle furthermore that I continue to work on Windows...

However there is a need to reorganize the moodle docs but alas bugs have a greater priority...

Pierre

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Saturday, 12 February 2011, 11:59 AM

I try

"git pull origin

and

git push github"

the only answer is: Everything up-to-date for the two commands.

Something is missing

Pierre

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Saturday, 12 February 2011, 8:25 PM

The most useful tool I know for working out what git is doing is gitk. That gives you a nice view. Here is a screen grab I just took of it displaying my workspace:

gitk screen grab

Each splodge is a separate commit. At the bottom you can see various branches all being merged together. That was all the changes being integrated into this week's weekly build. That leads up to remotes/origin/master, which is the main version of Moodle from git.moodle.org. (The green label is how gitk shows branches.)

We can also see my master branch, which is my local copy of the branch from git.moodle.org. Because the master and remotes/origin/master branches are in the same place, I can tell that my local copy is up-to-date. If my master was behind the remote one, I could use git pull to update it. If you look closely, you will see that the master branch label is in bold. That is because that is the branch I have currently got checked out.

You can also see the MDL-26236 branch, which is a bug fix I am working on. And the fact there is a remotes/github/MDL-26236 label there shows I have correctly pushed that branch to github.

To know for sure what the remote/... branches refer to, you can use the git remote -v command, which for me gives the output:

timslaptop:moodle_head tim$ git remote -v
github git@github.com:timhunt/moodle.git (fetch)
github git@github.com:timhunt/moodle.git (push)
origin git://git.moodle.org/moodle.git (fetch)
origin git://git.moodle.org/moodle.git (push)

Also, to get an accurate picture of what is on the remote servers, you need to run

git fetch origin
git fetch github

before running gitk.

Average of ratings: Useful (1)

Re: GIT help needed

by Pierre Pichet - Sunday, 13 February 2011, 3:59 AM

Thanks,

I have access to gitk in using Git Guy (windows) and effectively it works beautiffully.

I applied git fetch origin which worked correctly.

When I tried git fetch github, there was an error. I will look later.

GitHub add a new feature Fork Queue that I did not have time to explore.

Pierre

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Sunday, 13 February 2011, 12:11 PM

My actual understanding is that.

As we have no write access to moodle code, our personal github site is only a convenient deposit of our personal commits created on our local clones of moodle code.
As far as possible our local clone should be up-to-date so that we could verify that there is no merging problem but this could happen between the time we create the commit and its integration in the weekly update. Git structure allow this.
That our github fork does not reflect the actual moodle code is not important.

Is that OK ?

Pierre

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Sunday, 13 February 2011, 3:04 PM

That is about right.

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Saturday, 12 March 2011, 11:17 PM

Tim,

I have set-up a local copy of origin, create a branch (wip_MDL-24594_HTMLanswers) on which I coded the multiplechoice HTML (mainly for images) answer code and create 3 commits that were pushed on GITHUB so they can be applied.

I continued to work on the wip_MDL-24594_HTMLanswers branch for implementing MDL-26511 i.e. images on Cloze as this can work only if the multiplechoice allows images.

I create a first commit on wip_MDL-24594_HTMLanswers for MDL-26511 so that I can checkout to master and pull from origin.

The present status is that

# On branch master

# Your branch is ahead of origin/master by 4 commits

i.e. the 3 commits for MDL-24594 and the last one for MDL-26511.

I know already that I need to modifiy the last commit which will be easy as it is the last and not pushed on github.

I plan to do this final update to the MDL_26511 after testing (before Wednesday).

How about merging ?

I let you do it ?

If I merge the 3 commits for MDL-24594 but if you or somebody else apply them with modifications ( there is already one little necessary see ), how my next pull from origin will work?

Pierre

P.S. I put this here as there is no clear answer on the new page http://docs.moodle.org/en/Development:Quick_GIT_starting_guide_for_Moodle_development

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Sunday, 13 March 2011, 8:00 AM

It looks like although you created a wip_MDL-24594_HTMLanswers branch, you did not do you commits there. (You need to check out the branch you want to work on before you start committing.)

The simple answer is that you can just push what you have to github/ppichet/moodle, and I am happy to sort out the mess, since you have implemented a key feature.

I realise that is not very good answer, because it does not help you learn git.

The basic tools for sorting out a situation like this are:

Use gitk to visualise what is going on with the various branches in your repository. Keep refreshing the gitk view as you sort out the mess, to make sure the effect of the commands you type is what you expect.
Use git rebase and/or git cherry-pick to build a new branch from the old commits that you made the first time, but which you now realise are not right. Create as many new branch names as necessary while doing this, to make sure you don't lose anything.
Once you have built the branch you really want, rename the old and new branches so that everything has the name you want, and delete any temporary branches you created while sorting out the mess, and which you no longer need.
If, during all this, your master branch got messed up, use git reset --hard to reset master to origin/master, once you are sure you have safely copied all you work to another branch.

The details of exactly what to do depend on exactly how you have messed up (in my experience of messing up with git), but things are almost always salvageable.

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Sunday, 13 March 2011, 1:57 PM

Let me explain my problem in a different way.

I cloned moodle, create a branch to work on (wip_MDL-24594_HTMLanswers) as the instructions are "do not work on master".

I do the code for multiplechoice in three steps and create 4 commits that were pushed on github

The three commits are on

https://github.com/ppichet/moodle/commits/wip_MDL_24594_HTMLanswers

and they contain all the necessary modifications.

All my testing were done when I was checkout on the branch.

Then I started the work on cloze always on branch wip_MDL-24594_HTMLanswers as I need the new code for multiplichoice to do the code for Cloze images.

I complete the code for testing and create a commit that actually is NOT pushed on github.

My plan is to continue the testing and modify the commit if necessary.

This is more easy to modify the last commit in my understanding of git functions ( I just discover stashing today).

This is why when I found a small error in the multiplechoice code , I did not want to do a specific commit that will modify my plan.

I just put the info on MDL-24594 so it can be applied by the reviewers.

Following my understanding that I shall not work on master and that I cannot change the master code giving that my new role is only to create commits

that will be processed by you and the the other reviewer, I did not do any merge to master even on my local copy.

Furthermore my fork on github need some modifications following the instructions on moodle docs for those who create their fork on CVS.

http://docs.moodle.org/en/Development:Quick_GIT_starting_guide_for_Moodle_development

I did not complete the conversion because I was afraid to loose the work done.

I did not find a specific help on moodle Git handling for contributor like me.

Pierre

Average of ratings: -

Re: GIT help needed

by Joseph Rézeau - Sunday, 13 March 2011, 4:10 PM

Pierre "I did not find a specific help on moodle Git handling for contributor like me."

That is currently the main issue that prevents a number of "small-time" moodle contributors to take the huge step of moving from CVS to GIT. We desperately need a step-by-step (not "elliptic") complete documentation, with lots of concrete examples/scenarios, to be made available in the Modle documentation wiki.

If someone knowledgeable with GIT and Moodle (but not too knowledgeable) starts that documentation I'll be happy to contribute.

Joseph

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Sunday, 13 March 2011, 4:53 PM

I can see why you are asking for step-by-step documentation, but actually, with git, that is not what you really need to learn.

What you actually need to understand is:

git's data model. The way it represents the whole history of a project as a (directed acyclic) graph of commits. (If you are not a mathematician, don't let the vocabulary there scare you.)
the way branches are just labels on certain commits.
the way the distributed side of things work, so that you can push and pull commits to other git repositories.
how the various basic git commands affect the contents of your repository.

These things are not particularly complicated. If fact, that is perhaps why git is so confusing. It is actually a very simple dumb system that just does some basic things very well and very fast. And those simple things happen to be what you need to track the versions of a software project, but there is a lot of flexibility in exactly how you use the git tools to do that. It is not like CVS which forces you do do things in one way.

The best way to get that understanding is to keep gitk open, which shows you the structure of the repository, and how it changes as you issue various commands.

I agree that the best way to learn this stuff is to have some docs with the basic sets of commands you need to get day-to-day tasks done, but I am sure you realise that your learning goal is not to memorise those steps by rote, but to understand how and why they work.

(I must go and play badminton now. More later.)

Average of ratings: Useful (1)

Re: GIT help needed

by Pierre Pichet - Sunday, 13 March 2011, 10:21 PM

just to help you on return from badmington...

The concept of having all the history on board of my computer and that means that checkout change the files that I see on my computer was the most surprising thing of Git.

Doing things on a branch which is the actual code on the computer become more evident once this first concept was understand.

Git allows you to create all your code locally ( even on a boat at Tahiti ) and then things can be retrieved back.

How to manage correctly between the branch and the master locally and on the fork created on github remains somehow mysterious...

Pierre

breakfast time, more later.

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Sunday, 13 March 2011, 11:12 PM

And there are differences if we are building commits for moodle core code or on contrib where we have complete access to all steps to the final code.

Pierre

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Monday, 14 March 2011, 5:38 AM

It sounds like you have done almost the right thing. Here is a rough reconstruction with screen-grabs from gitk.

So you make a new branch to work on an issue, and do the work as three commits. So far, so good.

git checkout -b MDL-24594 master
git commit ...
git commit ...
git commit ...

1. Screenshot 1

then you want to work on something different, but related, and because you need to build on top of what you have already done, you continue with the same branch:

git commit ...

2. Screenshot 2

This is not idea, as you find when you need to do a bug-fix relating to the MDL-24594 work. You don't want to make a mess like this:

git commit ...

3. Screenshot 3.

It is not a very big mess, but still there must be a better way, and there is. What you should have done is, when starting the second bit of work, create a new branch for it. However, because you need to build on your previous work, you need to start your new branch from the end of the old one, then you can do new work that builds on the old work but keep it separate:

git checkout -b multianswer MDL-24594
git commit ...

4. Screenshot 4.

Now, when you want to do the bug-fix, you can go back to the MDL-24594 branch, and do it there:

git checkout MDL-24594
git commit ...

5. Screenshot 5

Now, as a final thing, you would probably like to update your multianswer branch so that it contains the big-fix. You can do this using the git rebase command:

git checkout multianswer
git rebase MDL-24594

6. Screenshot 6

git has build a copy of all your multianswer work starting from the new end of MDL-24594. Note that the commits from the old branch are still there, but they are not part of any branch. (What will happen is that in due course, git will garbage-collect them.)

As an advanced exercise, you can get from that state 3. to the final state 6. without having to re-do you editing and just using git commands. ... and, like most things in git, there are various ways you could do it. The easiest to understand would be using git rebase -i. And alternative would be.

git branch multianswer HEAD^
git branch temp
git reset --hard HEAD^^
git cherry-pick temp
git branch -D temp
git checkout multianswer
git rebase MDL-24594

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Monday, 14 March 2011, 9:42 AM

Thanks,

In the actual situation the wip_MDL-24594 contains

the commits for multiple choice that have been pushed on github and there references put on the MDL-24594 tracker issue
the commit for multianswer (MDL-26511) which has not be pushed to github .

I worry about rebasing wip_MDL-24594 as in ProGit they write

Do not rebase commits that you have pushed to a public repository.

So perhaps I did the following.

create a branch for MDL-26511 from wip_MDL-24594.

I prepare the commit for multianswer in the MDL-26511,

then checkout in wip_MDL-24594 ,
midify the commit for 26511 as a useles one
do the commit about the forgotten test string.

the result :

git status

So everything seems OK although I am not sure about the status of MDL-26511 .

(which evidently does not contains the little correction on wip_MDL-24594).

Merging from wip_MDL-24594 to MDL-26511 will be necessary is

there was a bit change in wip_MDL-24594 as I used checkout to MDL-26511 for testing.

Pierre

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Monday, 14 March 2011, 4:16 PM

The advice Do not rebase commits that you have pushed to a public repository is good in general, but not in this case.

For example, it would be totally wrong for moodle.org to rebase the master branch of the moodle.org repository http://git.moodle.org/gw?p=moodle.git;a=shortlog;h=refs/heads/master, because lots of other people will have cloned that.

In your case, however, the aim is to prepare a good clean branch with the changes you want to add to the official moodle.org version. Rebase is a tool for cleaning up branches (at the cost of making life difficult for people who have cloned your branch.) In this situation, you don't expect many people to have cloned your branch, and it is very important to have a clean history to be integrated, so rebasing is right.

The reason for calling the branch wip_... (for work-in-progress) is as a warning to people that you are planning to rebase the branch later, so they should be careful what they do with it. That is another reason why it is OK to rebase, because you have warned people in advance that it might happen.

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Monday, 14 March 2011, 7:29 PM

As the code will be applied to moodle by the reviewers , is my procedure OK or do I need to change something ?

Pierre

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Monday, 14 March 2011, 10:43 PM

After doing a little modification to commit MDL-26511 when checkout in MDL-26511 branch the situation is the following.

gt2

I need to push on wip_MDL_24594_.. to remotes/github so that it can be used by the reviewers.

The commit MDL-26511does not contains any modifications in the same files lines than the commits for wip_MDL_24594_...

i.e in xml_format.

As the commits for MDL-24594 will be applied before those for MDL-26511, there should be no real merge problem.

Can I simply rebase wip_MDL_24594_... branch changing its name to MDL_24594 before pushing to remote?

Pierre

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Monday, 14 March 2011, 11:16 PM

Can the commit MDL-26511 on wip_MDL_24594_... branch be destroyed as there is a new copy on MDL-26511 branch?

I so how to do it ?

Pierre

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Tuesday, 15 March 2011, 7:07 AM

You can remove a commit from a branch using git rebase -i. See the interactive rebase section of http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

As I say, don't worry about spending too much time cleaning up the git history. As long as I can see what the current situation is when I review the code, I can do any final clean-ups that are necessary. (If any clean-ups are necessary, I will try to explain what I do an why, so you know what to do in future.)

It does not matter exactly which branch names you use providing the branch name contains the bug id somewhere.

After you do things like rebase, you may need to use the -f option to git push - it tells you when that is necessary.

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Tuesday, 15 March 2011, 9:11 AM

No answer necessary as I have find the response in GIT docs.

Average of ratings: -

Re: GIT help needed

by Pierre Pichet - Tuesday, 15 March 2011, 6:56 AM

Let's suppose that somebody is already working on MDL-24594 which in any case should be applied before MDL-26511.

If I just push the actual wip_25494.. on github the two last commits MDL-26511 no more usefull and MDL-24594 remove diagonsis will appear on github.

The reviewer just reject the MDL-26511 no more usefull and apply the remaining MDL-25494 commits with the necessary modifications.

When I will I have completed my tests, I will push on GitHub the MDL-26511 branch so the MDL-26511 commit necessary to solve MDL-26511.

This is not perfect by the moodle book but useable, don't you think so ?

Pierre

P.S. I prefer to do more complete testing than to complete my Git learning on how to do rebase -i on Windows with Git gui which means interact with my favorite editor ??? problems ahead...

Average of ratings: -

Re: GIT help needed

by Matteo Scaramuccia - Monday, 14 February 2011, 6:36 AM

Hi Pierre,
find below my way of working (to be tested in the next days) with Moodle and Git:

Carefully read about Git, having started with "Version Control with Git" (978-0-596-52012-0) and Pro Git;
Git requires attention to define a workflow to work with: Moodle get into SCRUM, some proposals, not to mention other git experiences;
Prepare the environment:
- GitHub account to share your local work when it will be ready;
- Windows w/ msysgit and TortoiseGit (+TortoiseSVN TortoisePlink + PuTTYgen + Pageant);
- Linux w/ git and SSH Keys/ssh-agent;
- Fork Moodle repo;
Fork Moodle on GitHb;
Create at least two Moodle separate environments, 2.0 and 1.9 respectively;
Configure the previous point by mapping two git repos as in the table below. I guess that there's no need to keep my GitHub fork main branches up to date with the parent ones: remotes should be my friend and they should help to save disk space since I'm using a free account;
Work exclusively with branches. Lurking at different GitHub Moodle-forks repos it seems the naming convention is: [wip_][<Tracker ref>_][m<Moodle branch version if needed, e.g.: 19, 20>_]<branch goal short description>. wip_ will be used when in work in progress i.e.:
- you've just started working and you've been in the need to share your partial work;
- you're not sure about your proposal: it works but... share the doubts into the Tracker;
Be prepared to solve issues about merge failures, rebasing, ...

My Moodle Git repos first setup and following work packages:

Task	Moodle 2.0	Moodle 1.9
Clone Moodle Git repo from GitHub fork	git clone git@github.com:<username>/moodle.git moodle-20 cd moodle-20 git config --global user.name "Your Name" git config --global user.email yourmail@domain.tld	git clone git@github.com:<username>/moodle.git moodle-19 cd moodle-19 git config --global user.name "Your Name" git config --global user.email yourmail@domain.tld
Track Moodle main repo	git remote add moodle git://git.moodle.org/moodle.git git fetch moodle git branch --track master-moodle moodle/master	git remote add -t MOODLE_19_STABLE -m MOODLE_19_STABLE moodle git://git.moodle.org/moodle.git git fetch moodle git branch --track MOODLE_19_STABLE-moodle moodle/MOODLE_19_STABLE
Track Moodle integration repo	git remote add integration git://git.moodle.org/integration.git git fetch integration git branch --track master-integration integration/master	git remote add -t MOODLE_19_STABLE -m MOODLE_19_STABLE integration git://git.moodle.org/integration.git git fetch integration git branch --track MOODLE_19_STABLE-integration moodle/MOODLE_19_STABLE
Show branches	git branch
Update remotes (ALL)	git remote update
Look at what has been cooked in the kitchen	git diff master-moodle...master-integration	git diff MOODLE_19_STABLE-moodle...MOODLE_19_STABLE-integration
Checkout current stable master	git checkout master-moodle	git checkout MOODLE_19_STABLE-moodle
Create a WIP branch	git branch wip_[<Tracker ref>_][m20_]<branch goal short description> git checkout wip_[<Tracker ref>_][m20_]<branch goal short description>	git branch wip_[<Tracker ref>_][m19_]<branch goal short description> git checkout wip_[<Tracker ref>_][m19_]<branch goal short description>
Start working	git status git add <./file/folder> git status git commit -m "<reasons for this commit>"
Optionally update (ff) your WIP branch on the next run	git checkout wip_[<Tracker ref>_][m20_]<branch goal short description> git merge moodle/master-moodle	git checkout wip_[<Tracker ref>_][m19_]<branch goal short description> git merge moodle/MOODLE_19_STABLE-moodle
Optionally rename your WIP branch	git branch -m wip_[<Tracker ref>_][m20_]<branch goal short description> [<Tracker ref>_][m20_]<branch goal short description>	git branch -m wip_[<Tracker ref>_][m19_]<branch goal short description> [<Tracker ref>_][m19_]<branch goal short description>
Publish/Update the branch and give refs into the Tracker + Test Cases	git push origin [<Tracker ref>_][m20_]<branch goal short description>	git push origin [<Tracker ref>_][m19_]<branch goal short description>
Optionally track your remote branch (required if you're the only one able to push on it?)	git config branch.[<Tracker ref>_][m20_]<branch goal short description>.remote origin git config branch.[<Tracker ref>_][m20_]<branch goal short description>.merge refs/heads/[<Tracker ref>_][m20_]<branch goal short description>	git config branch.[<Tracker ref>_][m19_]<branch goal short description>.remote origin git config branch.[<Tracker ref>_][m19_]<branch goal short description>.merge refs/heads/[<Tracker ref>_][m19_]<branch goal short description>

Feedbacks are welcome! I'm at the very beginning...

HTH,
Matteo

Average of ratings: Useful (1)

Re: GIT help needed

by Pierre Pichet - Monday, 14 February 2011, 12:38 PM

Matteo

Thanks a lot for all the details.

What I understand from Git doc is that when working on a project, they suggest to do commits in the WIB branch at different parts of the project so that things will be clearer for the others when everything will be pushed.

As usual in a larger project we create sub-tasks.

Pierre

P.S. It is a pitty that there are no more scrollling, printing you large table or copy and paste is the only way to give its full value .

Average of ratings: -

Re: GIT help needed

by Joseph Rézeau - Sunday, 13 March 2011, 11:25 PM

Hi Matteo,

This looks like the kind of "GIT for Moodle scenario" I have been asking for in this thread.

Could you please put it somewhere in the Moodle Wiki Documentation for easy reference and so that moodlers can add to it?

It would help a lot if you would number the various steps.

ATB

Joseph

Average of ratings: -

Re: GIT help needed

by Tim Hunt - Monday, 14 March 2011, 4:30 AM

That is a good start to what is asked for. Thanks. You even used the same remote names as me (origin and moodle).

Only a few things I would disagree with.

1. In "Track Moodle main repo" I think calling your local copy of master something different is a bad idea.

2. When doing "Create a WIP branch", you can do it with one line:

git checkout -b <newbranchname> moodle/master

That switches you to a new branch with the given name, starting from where moodle/master is.

3. Don't merge from master into your WIP brach. Eventually, once you work is included in Moodle core, that will leave a nasty mess (and so the integrators will probably reject your branch).

Instead, you should rebase your branch onto the latest moodle/master, so that when it is integrated, the history is as clean as possible.

4. I don't think it is ever required to "Optionally track your remote branch".

3. is the only serious comment.

Average of ratings: -

Re: GIT help needed

by Matteo Scaramuccia - Thursday, 17 March 2011, 9:06 PM

Hi Tim,
thanks for your comments! I shared something should map my preferred way of working before testing it in the real world, just to understand if I was in the right direction, especially being a newbie and not able to find some answers that are part of my workflow, see http://moodle.org/mod/forum/discuss.php?d=168094#p740189.

On evaluating your comments I've just realized that checking out a remote tracking branch doesn't update my "local working copy" as expected (see below in Windows, my origin was created @ 4 Feb!): I'll reconsider Martin's hint, http://docs.moodle.org/en/Development:Quick_GIT_starting_guide_for_Moodle_development... I've probably detached both HEAD and the thing over my neck .

matteo@MATTEO-NB /C/Projects/Moodle/www/git/moodle-20 (master-moodle)
$ git remote update
Fetching origin
Fetching moodle
Fetching integration

matteo@MATTEO-NB /C/Projects/Moodle/www/git/moodle-20 (master-moodle)
$ git branch -a
master
master-integration
* master-moodle
remotes/integration/MOODLE_16_STABLE
remotes/integration/MOODLE_17_STABLE
remotes/integration/MOODLE_18_STABLE
remotes/integration/MOODLE_19_STABLE
remotes/integration/master
remotes/moodle/MOODLE_16_STABLE
remotes/moodle/MOODLE_17_STABLE
remotes/moodle/MOODLE_18_STABLE
remotes/moodle/MOODLE_19_STABLE
remotes/moodle/master
remotes/origin/HEAD -> origin/master
remotes/origin/MOODLE_16_STABLE
remotes/origin/MOODLE_17_STABLE
remotes/origin/MOODLE_18_STABLE
remotes/origin/MOODLE_19_STABLE
remotes/origin/master

matteo@MATTEO-NB /C/Projects/Moodle/www/git/moodle-20 (master-moodle)
$ git diff master...master-moodle

matteo@MATTEO-NB /C/Projects/Moodle/www/git/moodle-20 (master-moodle)
$

TIA,
Matteo

Average of ratings: -

Re: GIT help needed

by Matteo Scaramuccia - Friday, 18 March 2011, 12:36 AM

Mmmhhh... it looks like I've missed git pull [moodle] to let my worflow run as I expected for 2.0 branch. I guess I'll have more issues during the long way to my first commits into github...

Matteo

Average of ratings: -

Re: GIT help needed

by Howard Miller - Monday, 7 February 2011, 5:40 PM

I found it very hard to get the cvs/svn workflow out of my head. You have to realise that all git repositories are just peers. You can have a central repository that all your devs work-through but it doesn't make it like a cvs setup. It's just a convenience thing that you have decided upon.

For example, I had terrible trouble trying to think how to keep the central repo up to date with the "official" moodle release, but you don't have to. *anybody* on any repo who needs the latest release can merge in the latest moodle from cvs.moodle.org. Because Git updates are *world* unique it doesn't matter who does such things or if everybody does. When you push to your 'central' repo (e.g. github) it "just works" which is cool

So, my dev machine has a huge list of remote repositories for different purposes.

Average of ratings: -

Re: GIT help needed

by Myles Carrick - Monday, 7 February 2011, 7:21 PM

I can definitely attest to the value of thinking beyond ways to replicate your CVS/SVN workflow. Back at the 06(?) Sydney Moot, Moodle legend Martin Langhoff spent a couple of beers convincing me about distributed VCS and git and I've been glad for it ever since!

Tom Preston-Werner (one of GitHub's founders) just posted this great story/parable designed to help provide a different way to understand Git - hope you find it useful: http://tom.preston-werner.com/2009/05/19/the-git-parable.html

Myles

Average of ratings: -

Re: GIT help needed

by Joseph Rézeau - Monday, 7 February 2011, 5:48 PM

Hi Pierre, Tim and Howard.

I'm afraid the difficulties of moving from CVS to GIT have been largely underestimated as regards moodle contributors. I am gradually beginning to understand the advantages of GIT over CVS and am not discussing Moodle HQ's decision to make the move. GIT is a great tool which will facilitate the life of Moodle "hardcore" programers.

I am only worried that the steep learning curve (of moving to GIT) may put off small 3rd-party contributors (like myself). Maintaining a moodle "fork" on github, plus a clone on one's own local machine, plus including as "sub-modules" one's own 3rd-party plugins is really like using a jackhammer to kill a fly. It would be a pity if that meant discouragement and abandonment of the maintenance of many 3rd-party plugins on the one hand and even the will to propose bug fix patches for Moodle core files on the other.

I agree with Pierre that what is very much needed right now is a complete, step-by-step tutorial in the Moodle documentation wiki explaining - with real-world examples - and for various platforms -

a) the migration process from CVS to GIT;
b) how to implement a github repository for a moodle fork;
c) how to implement github repositories for one's own3rd-party plugins;
d) how to implement a moodle installation on one's own local machine
etc.

Whenever I read online docs for GIT (and TortoiseGit which I'm using on Windows), I am struck by the fact that there are so many elliptical explanations, i.e. that people explaining things take too much for granted. For instance, I insist that it should always be made clear if we are talking about your local machine or the distant server. That simple but essential piece of information is often implicit, when it should be made explicit.

Tim is great at writing tutorials in the moodle wiki, and I second Pierre that such a Moodle GIT tutorial by Tim (helped by others), written not for geeks, hardcore moodle programers but for small, amateur programers, would be invaluable.

I hope I've been explicit enough ,

Joseph

Average of ratings: Useful (1)

Re: GIT help needed

by Howard Miller - Monday, 7 February 2011, 6:19 PM

TBH... I never fully understood the cvs workflow for Moodle (-kk ??), I just mindlessly followed the instructions in the docs.

I think the problem that Git introduces is its distributed nature. It is going to be hard to prescribe a way to work with it that suits everybody. However, a simple, default methodology is probably something to aim for.

Just to note.. if you have Git questions, I would ask here (and the git mailing list, altough geeky, is helpful). There are some very long threads of me saying "I don't understand, I don't understand......" and getting some very useful advice from lots of people.

Average of ratings: -

Re: GIT help needed

by Patrick Pollet - Monday, 7 February 2011, 7:26 PM

+1 to Joseph. see http://moodle.org/mod/forum/discuss.php?d=164653

Third party contributors have already an hard time maintaining two versions (for Moodle 1.9 and 2.0) of their plugins.

I am also myself quite discouraged about proposing bug fix patches for Moodle core files. As an example, it took a month to remove one line in lib/db/access.php to fix an obvious mistake in 2.0 : http://tracker.moodle.org/browse/MDL-25672 ...

Cheers.

Average of ratings: -

Re: GIT help needed

by Dan Marsden - Wednesday, 9 February 2011, 4:41 AM

time frame for fix on MDL-25672 looks fine to me - you reported it just before christmas (people do go on leave over that time) and it was confirmed as an issue and agreed that it needed to be fixed 3 days after it was reported.

Average of ratings: -

Re: GIT help needed

by Myles Carrick - Monday, 7 February 2011, 7:29 PM

Simple tutorials here are a great idea. I'm currently working with some new Moodle devs - moving from Java, Oracle and SVN to PHP, Postgres and Git - I'm definitely happy to describe our steps in MoodleDocs...

NB re your question about confusing clients and servers with Git - one of the wonderful things about Git is that all repositories are essentially equal / peers. If you have a clone of the repo that itself is a fully-fledged repository itself - awesomely liberating after working with a centralized repo (eg. when hacking on a flight or offline elsewhere you can still follow good practice and commit regularly).

Average of ratings: -

Re: GIT help needed

by Martin Dougiamas - Monday, 14 February 2011, 2:06 PM

There are a few around that I asked developers to write. Here is one: http://docs.moodle.org/en/Development:Quick_GIT_starting_guide_for_Moodle_development

Average of ratings: -

Re: GIT help needed

by Matteo Scaramuccia - Monday, 14 February 2011, 3:20 PM

Hi Martin,
TNX for the ref! It's definitely more complete than my table above .

Question 1: is there any need to keep the GitHub fork up to date? Since I've a free account I'd like to spend the disk space at my (few, maybe) contributions: what I expect to miss in my GitHub fork is the ability to have the big picture where my commits has been derived from, however I should have the complete picture in my local repo.

Question 2: is it meaningful to keep an eye to integration.git too, to look at the potentially very next commits?

Any feedback is really appreciated!

TIA,
Matteo

Average of ratings: -

Re: GIT help needed

by Jamie Pratt - Thursday, 23 June 2011, 12:49 PM

Hi Matteo,

I think GitHub is clever enough to only count commits that are your commits against your disk space limit. If you have forked another project then the commits from the other project are not counted against you. And when you push commits that Github has elsewhere then again the commits are not counted against your disk space.

Jamie

Average of ratings: -

Re: GIT help needed

by Matteo Scaramuccia - Thursday, 23 June 2011, 2:13 PM

Hi Jamie,
in the mean time I found some pointers which informally confirmed me what you've clearly described: Repo Deletion for Everyone and alternates.

TNX!
Matteo

Average of ratings: -