GitControl
X
M
–
status
X
console
X
wip
X
log
X
doc
X
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with will be those from your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can push the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go to your browser's Javascript console and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer would be to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparation to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by Git, go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
Basic info about committing changes using the Lively GitControl
X
M
–
All Lively installations, such as you might have on localhost, or such as the lively-kernel.org/core installation, are separate instances of the master installation on Git. The GitControl tool makes it easy to update an installation and to commit changes made in that installation up to the master on Git. General commit and update workflow As a general rule, prior to making a bunch of changes, it is good to use the GitControl to do a "pull", bringing your installation up to date so that the only changes you will have to deal with be those involved in your project. Suppose you have changed a method in Widgets.js. When you open the GitControl, this file will appear as an "unstaged change", or you may have several files listed there that you have changed. You can us the "diff" button to see the changes that will be committed. [this does not work for me but it should for you. The alternative is to go tot the console window and type "git diff" or "git diff " followed by the pathname of a specific file] Maybe we need some discussion about what to do if things appear in the diff that you do not want. The simplest answer here would go to go fix the file. In preparation to commit, you need all your local changes to be either "staged" (in preparatin to commit), "stashed" (set aside from the commit but not forgotten. perhaps as you have more to do before committing), or forgotten (the X), meaning the changes will be lost, though you may still have that file around. So do one of these three things to all your unstaged changes. Now you are ready to commit your (now) staged changes, and this is done by pressing the "commit" button. Here you will be asked for a short comment about what these changes are. This will appear in the log which can be seen under the "log" tab. Next you should press "pull". This may take a little while and should then print a few lines ending with a pair of version numbers on the master. [for some reason my system asks me for my name and password at this point which can be entered in the terminal window] The final step is to do a "push" which makes your changes visible on Git, and everyone who updates will see those changes. This should also display a few lines with version numbers, and you should then be able to see your change at the top of the log window. Adding new files The file or directory that you want to add should already exist (create it. e.g. with the System Code Browser). In order to add new files to be controlled by git go into the "status" tab. Your file / directory will appear in the "Untracked files" category. Hover over the line representing the file / directory and hit the "add" button. The file / directory will now be listed as a "staged change" that can now be committed.
edit .git/config
edit .gitignore
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Git Console
X
M
–
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
save world
⟳
Some Text
Workspace
X
M
–
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
PRETTY FORMATS
If the commit is a merge, and if the pretty-format is not oneline,
email or raw, an additional line is inserted before the Author: line.
This line begins with "Merge: " and the sha1s of ancestral commits are
printed, separated by spaces. Note that the listed commits may not
necessarily be the list of the direct parent commits if you have
limited your view of history: for example, if you are only interested
in changes related to a certain directory or file.
There are several built-in formats, and you can define additional
formats by setting a pretty.<name> config option to either another
format name, or a format: string, as described below (see git-
config(1)). Here are the details of the built-in formats:
o    oneline
       <sha1> <title line>
   This is designed to be as compact as possible.
o    short
       commit <sha1>
       Author: <author>
       <title line>
o    medium
       commit <sha1>
       Author: <author>
       Date:   <author date>
       <title line>
       <full commit message>
o    full
       commit <sha1>
       Author: <author>
       Commit: <committer>
       <title line>
       <full commit message>
o    fuller
       commit <sha1>
       Author:     <author>
       AuthorDate: <author date>
       Commit:     <committer>
       CommitDate: <committer date>
       <title line>
       <full commit message>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


+
implement command line
X
display branch stuff
X
display stash
X
display untracked/unstaged/staged stuff
X
show log
X
support rebase?
X
show conflicted
X
resolve conflicted?
X
commit changes
X
fetch
X
pull
X
stage patches
X
stage files
X
create branch
X
show log
X
diff log
X
cherry pick log item
X
apply/show/remove stash
X
change branch
X
TodoList
X
M
–
quick publish
Workspace
X
M
–
1
2
3
4
5
6
7
8
that.setPosition(pt(0,0))
this.owner.owner.addMorph(that)
this.owner.owner.getTabContainer().getTabBar().rearrangeTabs()
t = this.owner.owner.getTabContainer().getTabBar().tabs.pop()
t2 = this.owner.owner.getTabContainer().getTabBar().tabs.pop()
this.owner.owner.getTabContainer().getTabBar().getTabs
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX