GitSuperRepoUnsorted - Revision history

Hinder at 05:46, 12 December 2012

2012-12-12T05:46:00Z

2011-12-13T18:16:05Z

2011-08-03T14:24:27Z

‎git module

2011-07-25T04:21:31Z

‎git module

2011-07-05T01:46:11Z

2011-06-28T07:14:35Z

‎git module

2011-06-28T07:14:05Z

‎git module

2011-06-28T07:10:35Z

‎git module

2011-06-28T07:07:23Z

2011-06-27T08:36:00Z

←Older revision		Revision as of 05:46, 12 December 2012
Line 64:		Line 64:
	* Create branches for components		* Create branches for components
	* Publish your local version of the code for others to see		* Publish your local version of the code for others to see
		+
		+	==Updating/pulling==
		+
		+	It is convenient to update some or all of the submodules in a super-repository at the same time. This means bringing in changes from their upstream repositories. Currently we have "git module update" which 1. fetches, 2. checks out the branch listed in the 'revision' entry of .gitmodules, and 2. pulls the checked out branch with the --ff-only option. This is a very safe setup and can never lead to any conflicts which need to be resolved.
		+
		+	===Use cases===
		+
		+	====Tracking an upstream superrepository with no local-only branches====
		+
		+	====Private super-repository====
		+
		+	====Project super-repository shared with collaborators====
		+
		+	====Project super-repository derived from a public super-repository====

←Older revision		Revision as of 18:16, 13 December 2011
Line 47:		Line 47:
	** With the above, we can do a dry-run to see what we would get, then do a non-dry-run to actually do the update.		** With the above, we can do a dry-run to see what we would get, then do a non-dry-run to actually do the update.
	** Optionally, we could also print out at the beginning the commit we started from, in case we want to go back to it		** Optionally, we could also print out at the beginning the commit we started from, in case we want to go back to it
		+
		+	==Workflow==
		+
		+	The following tasks are things that users should be able to do with our system:
		+
		+	* Download the code
		+	* Update to the "current" version of the code
		+	* Undo an update
		+	* Add components
		+	* Remove components
		+	* Go back to an old version
		+	* See differences between versions
		+	* Make a change to a component
		+	* Commit component changes
		+	* Create patches for components
		+	* Create branches for components
		+	* Publish your local version of the code for others to see

@@ Line 30: / Line 30: @@
 * checkout <submodule>|--all
 ** Checks out the local version of the named branch (from .gitmodules) for this submodule
 * config
 * fetch <submodule>|--all

@@ Line 34: / Line 34: @@
 ** Fetches new commits into the given submodules.  Does not merge.  Does not update anything in super-repo.
 * init-upstream
 * ls
 * mv

←Older revision		Revision as of 01:46, 5 July 2011
Line 10:		Line 10:

	* We should also provide a public example of such a repository, containing e.g. the Einstein Toolkit. This could then be used in our ET demonstration.		* We should also provide a public example of such a repository, containing e.g. the Einstein Toolkit. This could then be used in our ET demonstration.
		+
		+	==Ideas/To-do==
		+
		+	* Make it possible for the server to advance certain super-repo branches automatically. There could be some syntax in the .gitmodules file for a branch which said "auto-advance = true" or similar. This would make it possible for users to push their own branches of the super-repo and not have to worry about running the update etc themselves.

	==Current setup==		==Current setup==

←Older revision		Revision as of 07:14, 28 June 2011
Line 36:		Line 36:
	* update: git module update <submodule>\|--all		* update: git module update <submodule>\|--all
	** Performs a fetch followed by a checkout		** Performs a fetch followed by a checkout
		+	** Following the checkout, this should do a merge --no-ff.
		+	** It would be convenient to have a verbose option (maybe on by default) which prints all the commits which are being added during the merge.
		+	** In addition, we could have a --dry-run\|-n option which prints all the same things, but does not do the actual merge.
		+	** With the above, we can do a dry-run to see what we would get, then do a non-dry-run to actually do the update.
		+	** Optionally, we could also print out at the beginning the commit we started from, in case we want to go back to it

←Older revision		Revision as of 07:07, 28 June 2011
Line 20:		Line 20:
	* All mirrors (git-svn, git-hg and git) are automatically kept up to date with an hourly cron job, as is the 'submodules' branch of the super-repository.		* All mirrors (git-svn, git-hg and git) are automatically kept up to date with an hourly cron job, as is the 'submodules' branch of the super-repository.
	* Commiting back upstream works for git, svn and hg.		* Commiting back upstream works for git, svn and hg.
		+
		+	==git module==
		+
		+	* add
		+	* checkout
		+	* config
		+	* fetch: git module fetch <submodule>\|--all
		+	Fetches new commits into the given submodules. Does not merge. Does not update anything in super-repo.
		+
		+	* init-upstream
		+	* ls
		+	* mv
		+	* rm
		+	* setup
		+	* update

←Older revision		Revision as of 08:36, 27 June 2011
Line 1:		Line 1:
		+	[[Category:GitSuperRepo]]
		+
	''This is a list of things that would be useful to include in the documentation somewhere''		''This is a list of things that would be useful to include in the documentation somewhere''