Working with git - Revision history

Rhaas: add instructions on how to have git cache credentials

2014-11-02T11:08:37Z

add instructions on how to have git cache credentials

Rhaas: revert last change

2014-11-02T11:08:07Z

revert last change

Show changes

Rhaas: describe how to get git to cache credentials

2014-11-02T11:06:31Z

describe how to get git to cache credentials

Show changes

Hinder: /* SVN style */

2012-08-17T14:13:44Z

‎SVN style

92.225.33.67: /* SVN style */

2012-04-19T03:49:47Z

‎SVN style

194.94.224.254: /* Git style */

2011-11-30T11:48:43Z

‎Git style

194.94.224.254: /* Git style */

2011-11-30T11:38:30Z

‎Git style

194.94.224.254: /* Git style */

2011-11-30T11:34:48Z

‎Git style

194.94.224.254: /* Workflows */

2011-11-30T11:11:04Z

‎Workflows

194.94.224.254: /* Workflows */

2011-11-30T11:07:58Z

‎Workflows

@@ Line 190: / Line 190: @@
    git checkout -f HEAD
 This will throw away all local changes and will bring your repository back to the state it would be in if you freshly checked it out (with the exception of files which aren't under version control).
 =Workflows=

@@ Line 196: / Line 196: @@
 ==SVN style==
 Clone the repository (like "svn checkout")
@@ Line 201: / Line 203: @@
    git clone <url>
-Work on your new feature or bug fix.  If you need to add a new file to the repository, use
+Work on your new feature or bug fix.
-  git add -N <filename>
+===Updating===
-(like svn add) for the file you have created. (The -N stops the content of the file being added to the "staging area", which would make "git diff" give confusing results. Don't worry about this.)  If you need to remove a file, use
+Every so often, you will want to make sure you are working against the latest version of the code.  This is accomplished by
-   git rm <filename>
+   git pull
-Every so often, you will want to make sure you are working against the latest version of the code.  This is accomplished by
+If you get an error about a file not being "up to date", this means that you have made changes to a file which has also been changed in the remote repository.  You need to "stash" your changes away in a safe place, then do the update, then apply your changes to the new version:
    git stash
@@ Line 217: / Line 217: @@
    git stash pop
-This is equivalent to "svn update".  When you do the "git stash pop", you may have conflicts between the upstream changes and your own.  These will be marked with conflict markers in the source files just like with SVN.  You will need to fix these conflicts.  Once you have fixed all the conflicts, use "git add <filename>" on the files that had conflicts, and then do "git reset".
+This is equivalent to "svn update".  If all is well, your changes will be applied to the working copy and dropped from the stash.  If there are conflicts, these will be marked with conflict markers in the source files just like with SVN.  Your changes will also be kept in the stash for safe keeping, rather than being dropped.  You will need to fix these conflicts.  Once you have fixed all the conflicts, use "git reset" to tell git that you have fixed the conflicts.  To be tidy, you can now drop your changes from the stash with "git stash drop".
 To see what changes you have made in your local copy, use
    git diff HEAD
 If you want to revert one or more files to its clean state before you started editing it, use
    git checkout <file1> <file2> ...
 If you want to see what files have been modified, added or removed, use
    git status
 Eventually you will have your working directory in the state that you would like to commit.  Ensure that you are up-to-date as described above.  The next stage depends on whether you want to push your commit directly to the repository (if you have commit rights) or if you want to send your work as a patch.
-===Direct commit===
+====Direct commit====
 Make a local commit:
@@ Line 247: / Line 267: @@
 Your work is now in the central repository, and you are done.
-===Submitting a patch file===
+====Submitting a patch file====
 Sometimes you don't have commit access to the repository, or you want to have your work reviewed by someone else before you commit it.  You can package up your changes into a "patch file" with

@@ Line 217: / Line 217: @@
    git stash pop
-This is equivalent to "svn update".  When you do the "git stash pop", you may have conflicts between the upstream changes and your own.  These will be marked with conflict markers in the source files just like with SVN.  You will need to fix these conflicts.
+This is equivalent to "svn update".  When you do the "git stash pop", you may have conflicts between the upstream changes and your own.  These will be marked with conflict markers in the source files just like with SVN.  You will need to fix these conflicts.  Once you have fixed all the conflicts, use "git add <filename>" on the files that had conflicts, and then do "git reset".
 To see what changes you have made in your local copy, use
@@ Line 251: / Line 251: @@
 Sometimes you don't have commit access to the repository, or you want to have your work reviewed by someone else before you commit it.  You can package up your changes into a "patch file" with
-   git diff > ~/patches/MyWork.patch
+   git diff > ~/Uploads/MyWork.patch
 This file can be emailed or added to an issue-tracker.

@@ Line 360: / Line 360: @@
 Your work is now in the central repository, and you are done.
-===Submitting a patch file===
+===Submitting a series of patches ===
-Sometimes you don't have commit access to the repository, or you want to have your work reviewed by someone else before you commit it.  You can package up your changes into a "patch file" with
+Sometimes you don't have commit access to the repository, or you want to have your work reviewed by someone else before you commit it.  You can package up all your local commits which don't exist in the remote repository (refered to as "origin") with
-   git diff > ~/patches/MyWork.patch
+   git format-patch -o ~/patches origin
-This file can be emailed or added to an issue-tracker.
+This will make a series of numbered patch files named after the subject of each commit (the first line in the commit message) in the ~/patches directory.  These files can be emailed or added to an issue-tracker.
-Suppose you need to modify your work.  Edit the working-copy files to incorporate the modifications, and then generate a new patch file as above.  Repeat until the patch is final.
+===Editing your commits===
-If you are responsible for committing the accepted patch, you can use the procedure in "Direct commit" above.  If someone else has committed it, you don't need your local changes any more, and you can erase them using
+Suppose you have several local commits, but you decide you need to make changes before pushing or making patches.  One option is to make the changes you need and then make new commits with these changes.  You can then either push the entire set of commits or make new patch files with "git format-patch" as above.
-  git checkout
+Git allows you to modify your existing local commits.  If you only need to modify the last commit, you can just make your changes to your files and use
-You can then update from the remote repository with
+  git commit --amend <file1> <file2> ...
-  git pull
+This will modify the last commit to incorporate your new changes.
-and you are done.
+If you have to edit a commit which is not the last one, you can use

@@ Line 348: / Line 348: @@
 ===Direct commit===
-Make a local commit:
+If you want to push the patches directly to the repository, you can use
-   git commit -a
+   git push
-This will prompt you for a commit message.  The "-a" means "all registered files".  This will make a local commit in your repository.  Push this commit to the central repository:
+This will push all your local unpushed commits to the repository that you cloned from.  If you need to push to a different repository (for example if you cloned from a read-only git:// repository and you need to push to an ssh git@server:/repo style repository), you can add the URL of the repository:
-   git push
+   git push <url>
-These two commands together are equivalent to "svn commit".
+If you get an error about a "non-fastforward" push, this means that you were not up-to-date when you tried to push.  Use the "git pull --rebase" command as described above to make yourself up-to-date and try again.
 Your work is now in the central repository, and you are done.

@@ Line 300: / Line 300: @@
 This will ask you, for each individual change in each file, whether you want to stage that "hunk" or not.   You can answer "yes", "no", "all" or "done" by entering the first letter of each.  Type "?" for help on the other options.  Quitting the interactive "git add" will leave all the hunks you have staged staged.  If you want to unstage a hunk, you can use
    git reset -p <file1> <file2> ...
-This gives you the same interface as "git add -p", but lets you unstage rather than stage each hunk.
+to select hunks to unstage.  This gives you the same interface as "git add -p", but lets you unstage rather than stage each hunk.
 You can see all the hunks which are currently staged using
@@ Line 313: / Line 317: @@
    git commit
-You will be prompted for a commit message.
+You will be prompted for a commit message.  Once your changes are committed, you can see them using "git log".
 Every so often, you will want to make sure you are working against the latest version of the code.  This is accomplished by
    git stash
-   git pull
+   git pull --rebase
    git stash pop
-This is equivalent to "svn update".  When you do the "git stash pop", you may have conflicts between the upstream changes and your own.  These will be marked with conflict markers in the source files just like with SVN.  You will need to fix these conflicts.
+The "git pull --rebase" will unapply all your local commits, update your local repository with commits from the remote repository, and then attempt to re-apply your commits.  This process might generate conflicts.  These will be indicated in the output of "git pull --rebase".  You can edit the files to fix the conflicts.  When you have finished fixing the conflict, you need to mark the files as fixed using
-Eventually you will have your working directory in the state that you would like to commit.  Ensure that you are up-to-date as described above.  The next stage depends on whether you want to push your commit directly to the repository (if you have commit rights) or if you want to send your work as a patch.
+Eventually you will have a set of commits at the end of your history (at the beginning of the output of "git log") that you would like to push.  Ensure that you are up-to-date as described above.  The next stage depends on whether you want to push your commits directly to the repository (if you have commit rights) or if you want to send your work as a series of patches.
 ===Direct commit===

@@ Line 193: / Line 193: @@
 =Workflows=
-These workflows are designed to be self-contained.  git is a complicated program, and the documentation can be confusing.  The aim of these sections is that if you stick to the commands and techniques used here, you should not get into a mess or need to consult any other git documentation.
+These workflows are designed to be self-contained.  git is a complicated program, and the documentation can be confusing.  The aim of these sections is that if you stick to the commands and techniques used in each workflow, you should not get into a mess or need to consult any other git documentation.
 ==SVN style==