Frequent git use cases - Revision history

Jerico.dev: Oups, used my personal aliases here

2010-04-21T04:33:25Z

Oups, used my personal aliases here

2010-04-21T04:28:06Z

Adding initial fetch command

2010-04-21T04:27:24Z

Added porting instructions

2010-04-19T21:30:25Z

Change config file editing to git-config call

2010-04-19T21:29:01Z

Added autosetuprebase config

2010-04-03T16:51:14Z

Added patch stack command

2010-04-03T16:39:20Z

Added bugzilla entry search.

2010-03-25T19:24:27Z

‎Configure your development branch

2010-03-25T18:18:30Z

When to commit lib/pkp

2010-03-24T21:55:42Z

‎Configure your development branch

@@ Line 353: / Line 353: @@
   git fetch official
-  git co master
+  git checkout master
   git pull
   for cherry in `git cherry master official/ojs_2_3_2_rc | sed -n '/^+/ s/^+ //p'`; do git cherry-pick -x $cherry; done
   gitk  # (optional) just to check if everything went alright
   git push

@@ Line 352: / Line 352: @@
 Use the following commands to port all changes from a maintenance branch to the development branch:
   git co master
   git pull

← Older revision		Revision as of 04:27, 21 April 2010
Line 347:		Line 347:

	git format-patch -N -o /path/to/outdir patchbase		git format-patch -N -o /path/to/outdir patchbase
		+
		+	= Porting Changes =
		+
		+	Use the following commands to port all changes from a maintenance branch to the development branch:
		+
		+	git co master
		+	git pull
		+	for cherry in `git cherry master official/ojs_2_3_2_rc \| sed -n '/^+/ s/^+ //p'`; do git cherry-pick -x $cherry; done
		+	gitk # (optional) just to check if everything went alright
		+	git push

@@ Line 51: / Line 51: @@
   git config --global branch.autosetuprebase remote
-You should also edit your ~/.gitconfig file, create a new [push] section and set the 'default' option therein to 'tracking':
+You should also execute
-  [push]
+  git config --global push.default tracking
-        default = tracking
 This will make sure that you automatically push to the branch that is configured as a tracking branch (in our case official/master). It will save you some typing when you push.

@@ Line 47: / Line 47: @@
 * It configures your development branch to track official/master.
 * It switches the pull command from "merge" to "rebase" mode so that we'll get a clean sequential commit history in the master branch.
 You should also edit your ~/.gitconfig file, create a new [push] section and set the 'default' option therein to 'tracking':

← Older revision		Revision as of 16:51, 3 April 2010
Line 339:		Line 339:

	If you don't have any local changes you leave out the stash commands.		If you don't have any local changes you leave out the stash commands.
		+
		+	== Create a patch stack to be sent to non-git developers ==
		+
		+	The following command assumes that you have tagged the commit preceding the first commit to be included in the patch stack with "patchbase":
		+
		+	git format-patch -N -o /path/to/outdir patchbase

@@ Line 1: / Line 1: @@
 = Understand where you are =
 To see all branches that are currently in your repository:
   git branch -a
@@ Line 13: / Line 14: @@
 Mac OS X users may try using [http://gitx.frim.nl/ "GitX"].  There are a variety of other software solutions on other operating systems that will help you visualize your Git branches.
 To see the changes that will be introduced by the next pull from the master repository
   git fetch official
@@ Line 25: / Line 27: @@
 NB: Note that '..' and '...' mean different things for 'git log' and 'git diff'. See 'man git-rev-parse' and 'man git-diff' for a full explanation.
 = Working on BugZilla Bugs =

@@ Line 50: / Line 50: @@
 Note: the "push" configuration is missing in git version 1.5.5.6 (and maybe others). In this case when pushing you can use:
-git push official dev:master
+ git push official dev:master
 == Start working on a BugZilla bug ==

← Older revision		Revision as of 18:18, 25 March 2010
Line 211:		Line 211:

	The big advantage of this system is that you can record for every commit you make in the base system the exact state of the submodule that goes with it. If you do this correctly you'll never have the problem again that the pkp library is out of sync with your base repository. You can reconstruct for every single commit in the base repository the exact state the code of the library was in at the time of the commit.		The big advantage of this system is that you can record for every commit you make in the base system the exact state of the submodule that goes with it. If you do this correctly you'll never have the problem again that the pkp library is out of sync with your base repository. You can reconstruct for every single commit in the base repository the exact state the code of the library was in at the time of the commit.
		+
		+	'''Whenever you commit changes to a base repository that depend on a certain version of the PKP library you should make sure that you commit the correct lib/pkp entry.'''

	=== Understand what's going on ===		=== Understand what's going on ===

← Older revision		Revision as of 21:55, 24 March 2010
Line 47:		Line 47:

	(For those who followed the previous "entry level" approach: this is exactly what we had documented as "advanced approach" in our Wiki so far.)		(For those who followed the previous "entry level" approach: this is exactly what we had documented as "advanced approach" in our Wiki so far.)
		+
		+	Note: the "push" configuration is missing in git version 1.5.5.6 (and maybe others). In this case when pushing you can use:
		+
		+	git push official dev:master

	== Start working on a BugZilla bug ==		== Start working on a BugZilla bug ==