<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Sascha Silbe wrote:
<pre wrap="">Excerpts from Art Hunkins's message of Tue Dec 28 21:47:27 +0100 2010:
<pre wrap="">Please advise me on one point: once the local repo is established
(filemix.git), what's the simplest way to copy all my (revised) activity
files (including subdirectory) to filemix.git?
First of all, like James already mentioned, the easiest (and in fact
most common) way is to always work from within a git working tree. You
don't have to copy any file around. Git keeps track of which files
are "part" of your repository and which of them changed since your last
Running "git status" will show you which changes are already "scheduled"
for inclusion in the next commit (i.e. those you already ran "git add"
on), which changes to files that were part of the previous commit are
not yet scheduled for inclusion, but would be added when using
"git commit -a" and finally which files exist that were not part of the
previous commit (either because you don't want them in git or because they
are new and you haven't "git add"ed them yet).
== Cheat sheet ==
Setup (once per machine you're working on):
git clone git://git.sugarlabs.org/whatever/mainline.git whatever
[hack away and test your changes]
[review your changes, go back to hacking if you notice a mistake]
git add NameOfNewFile # if you created any file you want included
git commit -a
[describe your changes - by convention the first line is a summary and the remaining lines are long description]
[start again at hacking if you're offline]
git log origin/master..master # shows you all commits not pushed yet
git push # if/once you are online
Git offers a lot more commands and features that can make your life
easier, but it's best to start off small and use only those mentioned
above. It's very easy to get confused if you're unfamiliar with git.
Even if you use the more advanced features, git does a pretty good job at
allowing you to recover from your mistakes.
So if you ever mess up and don't know how to fix it yourself, please
stop (at least for me that's usually the hardest part ;) ), try to
recollect the exact sequence of actions (e.g. from shell history) and ask
If you'd like to understand git and have a solid technical background,
I recommend to try "Git from the bottom up" by John Wiegley (don't have
a URL handy, sorry). It helped me quite a lot.
<a class="moz-txt-link-freetext" href="http://www.newartisans.com/2008/04/git-from-the-bottom-up.html">http://www.newartisans.com/2008/04/git-from-the-bottom-up.html</a><br>
== Small, potentially unhelpful glossary ==
VCS: Version Control System. Keeps track of changes to a set of files.
git: a modern, distributed VCS
commit: set of changes to files tracked by a VCS, accompanied by metadata
(author, description, etc.)
diff/patch: (usually textual) representation of changes. Also the names
of specific tools to create resp. apply this representation.
repository: storage place for commits, usually of a certain piece of
gitorious: software for hosting git repositories, including a web
interface for administration
git.sugarlabs.org: server hosted by Sugar Labs running gitorious
<hr size="4" width="90%">
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugaremail@example.com">Sugarfirstname.lastname@example.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>