GitSuperRepoUsersGuide - Revision history

Hinder at 17:25, 13 December 2011

2011-12-13T17:25:54Z

46.7.100.170: /* Mercurial */

2011-12-13T17:17:10Z

‎Mercurial

46.7.100.170: /* Checking out a specific branch */

2011-12-13T17:14:06Z

‎Checking out a specific branch

46.7.100.170: /* Changing to a new version */

2011-12-13T17:13:41Z

‎Changing to a new version

Hinder at 17:12, 13 December 2011

2011-12-13T17:12:52Z

Hinder at 17:03, 13 December 2011

2011-12-13T17:03:36Z

46.7.100.170: /* Checking out */

2011-12-13T17:01:59Z

‎Checking out

46.7.100.170: /* Checking out */

2011-12-13T17:01:25Z

‎Checking out

46.7.100.170: /* Checking out */

2011-12-13T17:01:01Z

‎Checking out

Hinder: /* Checking out */

2011-12-13T17:00:31Z

‎Checking out

@@ Line 40: / Line 40: @@
 ===What's new?===
-To see the commits that are available on the server, use
+Get all current information from the remote repositories (this does not change anything in your working tree):
-   git module summary
+   git fetch
-<span style="background:yellow">Is this actually correct?  I think this actually shows the current state of the remote repositories, rather than the commits you would get if you pulled the super-repository.  Can we have a command to do the latter?</span>
+Find out what commits you would get if you updated:
-Commits that you would get by updating are listed in green, and those that you have made locally that you probably want to push are listed in red.
+  git log --reverse --oneline -p --submodule master..origin/master $(git submodule|awk '{print $2}')
-<span style="background:yellow">What happens in a terminal without colour?  Should we prefix each line with "push" and "pull" to make it clear?</span>
+<span style="background:yellow">We should have a git-module command for this, preferably in the format of git-module summary.  It should not make assumptions about branch names like I did above.</span>
 ===Viewing local modifications===

@@ Line 117: / Line 117: @@
 ===Mercurial===
-<span style="background:yellow">This is not working yet due to issues with the Carpet repository.  Barry: what would the syntax be if it was working?</span>
+<span style="background:yellow">This is not working yet due to issues with the Carpet repository.</span>
-For Mercurial upstream repositories, it is more complicated, as there is no git-hg (equivalent to git-svn). In this case, you make commits locally to your submodule as if it were a regular git repository. Then, when you want to push upstream:
+For Mercurial upstream repositories, make sure [http://offbytwo.com/git-hg/ git-hg] is installed. You make commits locally to your submodule as if it were a regular git repository. Then, when you want to push upstream:
-   cd <submodule-path>.hg
+   git hg push

@@ Line 89: / Line 89: @@
 You can see a list of available super-repository branches using
-   git branch
+   git branch -a
 ==Committing==

@@ Line 83: / Line 83: @@
    git checkout ET_2011_06
-   git module checkout --all
+   git submodule update
 The tree will be very quickly updated to match the release.  All changed files will have updated datestamps, so you should be able to trust the Cactus make system to recompile only what is necessary.  However, it might be safer to delete any configurations and build them again.

←Older revision		Revision as of 17:12, 13 December 2011
Line 43:		Line 43:

	git module summary		git module summary
		+
		+	<span style="background:yellow">Is this actually correct? I think this actually shows the current state of the remote repositories, rather than the commits you would get if you pulled the super-repository. Can we have a command to do the latter?</span>

	Commits that you would get by updating are listed in green, and those that you have made locally that you probably want to push are listed in red.		Commits that you would get by updating are listed in green, and those that you have made locally that you probably want to push are listed in red.

@@ Line 36: / Line 36: @@
 You will need to configure simfactory as usual either by using "sim setup" or by creating a simfactory/etc/defs.local.ini file by hand.
-==What's new?==
+==Status==
 To see the commits that are available on the server, use
@@ Line 46: / Line 48: @@
 <span style="background:yellow">What happens in a terminal without colour?  Should we prefix each line with "push" and "pull" to make it clear?</span>
-==Viewing local modifications==
+===Viewing local modifications===
 You can see at a glance which of the submodules have local changes using
@@ Line 54: / Line 56: @@
 You can then go into each submodule and see those changes using git status or git diff.
-==Viewing history==
+===Viewing history===
 In addition to the super repository being a git repository, each sub-repository is also a separate fully-fledged Git repository, so you can go into each one and type "git status", "git log", etc.  This works for repositories which are SVN or Mercurial upstream, because we use git-svn and hg-git to convert the repositories to Git on the server.  You can also use the usual graphical tools (we recommend [http://gitx.laullon.com/ GitX] for Mac OS, and git-gui/gitk for Linux) on each subrepository to visualise the log messages and patches, see which files have local changes, and interactively commit parts of files.
-==Updating==
+==Changing to a new version==
 If you want to pull all changes from the server (those listed in green in "git module summary"), use
@@ Line 72: / Line 76: @@
    git submodule update
-==Checking out a specific branch==
+===Checking out a specific branch===
 If you want to use a particular Einstein Toolkit release, perhaps because the current development version is unstable, use

@@ Line 32: / Line 32: @@
    source ~/.profile
-Note that this currently only works if your shell is Bash. If you use another shell, skip the setup and just add '.../Cactus/bin' to your path. You will need to configure simfactory as usual either by using "sim setup" or by creating a simfactory/etc/defs.local.ini file by hand.
+Note that this currently only works if your shell is Bash. If you use another shell, skip the setup and just add '.../Cactus/bin' to your path.
 ==What's new?==

@@ Line 28: / Line 28: @@
    ./bin/git-module setup
-This edits your Bash startup file (assumed to be ~/.profile), adding git-module to your PATH and enabling bash completion for the git-module package.  You now reload your startup file to have access to git-module on your PATH:
+This edits your Bash startup file (assumed to be ~/.profile), adding git-module to your PATH and enabling bash completion for the git-module package.  You should now reload your startup file to have access to git-module on your PATH:
    source ~/.profile

@@ Line 23: / Line 23: @@
    git clone --recursive git://git.barrywardell.net/EinsteinToolkit Cactus
-This takes about 10 minutes and will create a directory called Cactus containing the entire Einstein Toolkit and all its version history. When it is done, setup the git-module package which provides convenience functionality:
+This takes about 10 minutes and will create a directory called Cactus containing the entire Einstein Toolkit and all its version history. When it is done, you need to set up the git-module package which provides convenience functionality:
    cd Cactus