{"thread":{"id":"1233","subject":"[PATCH] Documentation: packed GIT support commands.","startedAt":"2005-07-14T07:08:05Z","lastAt":"2005-07-18T17:29:36Z","messageCount":14,"participants":["Junio C Hamano","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"6117","messageId":"7vbr55kgq2.fsf@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":null,"subject":"[PATCH] Documentation: packed GIT support commands.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-14T07:08:05Z","receivedAt":"2005-07-14T07:08:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This adds documentation for creating packed archives, inspecting,\nvalidating them, and unpacking them.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/git-pack-objects.txt   |   80 ++++++++++++++++++++++++++++++++++\n Documentation/git-show-index.txt     |   36 +++++++++++++++\n Documentation/git-unpack-objects.txt |   33 ++++++++++++++\n Documentation/git-verify-pack.txt    |   13 +++++-\n 4 files changed, 161 insertions(+), 1 deletions(-)\n create mode 100644 Documentation/git-pack-objects.txt\n create mode 100644 Documentation/git-show-index.txt\n create mode 100644 Documentation/git-unpack-objects.txt\n\n32a772fa72da57fbbe9ea27d195e6b755c83cd22\ndiff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/git-pack-objects.txt\n@@ -0,0 +1,80 @@\n+git-pack-objects(1)\n+===================\n+v0.1, July 2005\n+\n+NAME\n+----\n+git-pack-objects - Create a packed archive of objects.\n+\n+\n+SYNOPSIS\n+--------\n+'git-pack-objects' [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list\n+\n+\n+DESCRIPTION\n+-----------\n+Reads list of objects from the standard input, and writes a packed\n+archive with specified base-name, or to the standard output.\n+\n+A packed archive is an efficient way to transfer set of objects\n+between two repositories, and also is an archival format which\n+is efficient to access.  The packed archive format (.pack) is\n+designed to be unpackable without having anything else, but for\n+random access, accompanied with the pack index file (.idx).\n+\n+'git-unpack-objects' command can read the packed archive and\n+expand the objects contained in the pack into \"one-file\n+one-object\" format; this is typically done by the smart-pull\n+commands when a pack is created on-the-fly for efficient network\n+transport by their peers.\n+\n+Placing both in pack subdirectory of $GIT_OBJECT_DIRECTORY (or\n+any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)\n+enables GIT to read from such an archive.\n+\n+\n+OPTIONS\n+-------\n+base-name::\n+\tWrite into a pair of files (.pack and .idx), using\n+\t<base-name> to determine the name of the created file.\n+\tWhen this option is used, the two files are written in\n+\t<base-name>-<SHA1>.{pack,idx} files.  <SHA1> is a hash\n+\tof object names (currently in random order so it does\n+\tnot have any useful meaning) to make the resulting\n+\tfilename reasonably unique, and written to the standard\n+\toutput of the command.\n+\n+--stdout::\n+\tWrite the pack contents (what would have been writtin to\n+\t.pack file) out to the standard output.\n+\n+--window and --depth::\n+\tThese two options affects how the objects contained in\n+\tthe pack are stored using delta compression.  The\n+\tobjects are first internally sorted by type, size and\n+\toptionally names and compared against the other objects\n+\twithin --window to see if using delta compression saves\n+\tspace.  --depth limits the maximum delta depth; making\n+\tit too deep affects the performance on the unpacker\n+\tside, because delta data needs to be applied that many\n+\ttimes to get to the necessary object.\n+\n+--incremental::\n+\tThis flag causes an object already in a pack ignored\n+\teven if it appears in the standard input.\n+\n+\n+Author\n+------\n+Written by Linus Torvalds <torvalds@osdl.org>\n+\n+Documentation\n+-------------\n+Documentation by Junio C Hamano\n+\n+GIT\n+---\n+Part of the link:git.html[git] suite\n+\ndiff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/git-show-index.txt\n@@ -0,0 +1,36 @@\n+git-show-index(1)\n+=================\n+v0.1, July 2005\n+\n+NAME\n+----\n+git-show-index - Show packed archive index\n+\n+\n+SYNOPSIS\n+--------\n+'git-show-index' < idx-file\n+\n+\n+DESCRIPTION\n+-----------\n+Reads given idx file for packed GIT archive created with\n+git-pack-objects command, and dumps its contents.\n+\n+The information it outputs is subset of what you can get from\n+'git-verify-pack -v'; this command only shows the packfile\n+offset and SHA1 of each object.\n+\n+\n+Author\n+------\n+Written by Linus Torvalds <torvalds@osdl.org>\n+\n+Documentation\n+--------------\n+Documentation by Junio C Hamano\n+\n+GIT\n+---\n+Part of the link:git.html[git] suite\n+\ndiff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/git-unpack-objects.txt\n@@ -0,0 +1,33 @@\n+git-unpack-objects(1)\n+=====================\n+v0.1, July 2005\n+\n+NAME\n+----\n+git-unpack-objects - Create a packed archive of objects.\n+\n+\n+SYNOPSIS\n+--------\n+'git-unpack-objects' < pack-file\n+\n+\n+DESCRIPTION\n+-----------\n+Reads a packed archive (.pack) from the standard input, and\n+expands the objects contained in the pack into \"one-file\n+one-object\" format in $GIT_OBJECT_DIRECTORY.\n+\n+\n+Author\n+------\n+Written by Linus Torvalds <torvalds@osdl.org>\n+\n+Documentation\n+-------------\n+Documentation by Junio C Hamano\n+\n+GIT\n+---\n+Part of the link:git.html[git] suite\n+\ndiff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt\n--- a/Documentation/git-verify-pack.txt\n+++ b/Documentation/git-verify-pack.txt\n@@ -9,7 +9,7 @@ git-verify-pack - Validate packed GIT ar\n \n SYNOPSIS\n --------\n-'git-verify-pack' <pack>.idx ...\n+'git-verify-pack' [-v] <pack>.idx ...\n \n \n DESCRIPTION\n@@ -23,6 +23,17 @@ OPTIONS\n <pack>.idx ...::\n \tThe idx files to verify.\n \n+-v::\n+\tAfter verifying the pack, show list of objects contained\n+\tin the pack.  The format used is:\n+\n+\t\tSHA1 type size offset-in-packfile\n+\n+\tfor objects that are not deltified in the pack, and\n+\n+\t\tSHA1 type size offset-in-packfile depth base-SHA1\n+\n+\tfor objects that are deltified.\n \n Author\n ------\n"},{"id":"6173","messageId":"7vzmsots7t.fsf@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"7vbr55kgq2.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Documentation: update tutorial to talk about push.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-15T07:59:34Z","receivedAt":"2005-07-15T07:59:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Talk about publishing to a public repository.  Also fixes a\ncouple of typos.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n*** To be consistent with the rest of the text, I said \"I\" push\n*** to master.kernel.org, but obviously I am lying there ;-).  I\n*** do not know if your changes enters the public repo starting\n*** at master.kernel.org, nor you would particularly want to\n*** publicize how it actually works in the documentation.  I\n*** just tried giving readers realistic enough feel, but I\n*** welcome editorial fixes.\n\n Documentation/tutorial.txt |   87 ++++++++++++++++++++++++++++++++++++++++----\n 1 files changed, 80 insertions(+), 7 deletions(-)\n\n37a26024be1ec6b5ea04ecf109fd149fb6984fe8\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -480,9 +480,10 @@ This has two implications: \n    history outside of the project you created.\n \n  - if you want to move or duplicate a git archive, you can do so. There\n-   is no \"git clone\" command: if you want to create a copy of your\n-   archive (with all the full history that went along with it), you can\n-   do so with a regular \"cp -a git-tutorial new-git-tutorial\".\n+   is \"git clone\" command, but if all you want to do is just to\n+   create a copy of your archive (with all the full history that\n+   went along with it), you can do so with a regular\n+   \"cp -a git-tutorial new-git-tutorial\".\n \n    Note that when you've moved or copied a git archive, your git index\n    file (which caches various information, notably some of the \"stat\"\n@@ -534,7 +535,7 @@ create your own copy of the git reposito\n \n \tmkdir my-git\n \tcd my-git\n-\trsync -rL rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ .git\n+\trsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git .git\n \n followed by \n \n@@ -549,14 +550,14 @@ those, you'd check them out with\n \n where the \"-u\" flag means that you want the checkout to keep the index\n up-to-date (so that you don't have to refresh it afterward), and the\n-\"-a\" file means \"check out all files\" (if you have a stale copy or an\n+\"-a\" flag means \"check out all files\" (if you have a stale copy or an\n older version of a checked out tree you may also need to add the \"-f\"\n-file first, to tell git-checkout-cache to _force_ overwriting of any old\n+flag first, to tell git-checkout-cache to _force_ overwriting of any old\n files). \n \n Again, this can all be simplified with\n \n-\tgit clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ my-git\n+\tgit clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git\n \tcd my-git\n \tgit checkout\n \n@@ -770,3 +771,75 @@ point, just create a private tag for it,\n name for the state at that point.\n \n [ to be continued.. cvsimports, pushing and pulling ]\n+\n+\n+\tPublishing your work\n+\t--------------------\n+\n+We already talked about using somebody else's work from a remote\n+repository, in the \"merging external work\" section.  It involved\n+fetching the work from a remote repository; but how would _you_\n+prepare a repository so that other people can fetch from it?\n+\n+Your real work happens in your working directory with your\n+primary repository hanging under it as its \".git\" subdirectory.\n+You _could_ make it accessible remotely and ask people to pull\n+from it, but in practice that is not the way things are usually\n+done.  A recommended way is to have a public repository, make it\n+reachable by other people, and when the changes you made in your\n+primary working directory are in good shape, update the public\n+repository with it.\n+\n+[ Side note: this public repository could further be mirrored,\n+  and that is how kernel.org git repositories are done.  ]\n+\n+Publishing the changes from your private repository to your\n+public repository requires you to have write privilege on the\n+machine that hosts your public repository, and it is internally\n+done via an SSH connection.\n+\n+First, you need to create an empty repository to push to on the\n+machine that houses your public repository.  This needs to be\n+done only once.\n+\n+Your private repository's GIT directory is usually .git, but\n+often your public repository is named \"<projectname>.git\".\n+Let's create such a public repository for project \"my-git\".\n+After logging into the remote machine, create an empty\n+directory:\n+\n+\tmkdir my-git.git\n+\n+Then, initialize that directory with git-init-db, but this time,\n+since it's name is not usual \".git\", we do things a bit\n+differently:\n+\n+\tGIT_DIR=my-git.git git-init-db\n+\n+Make sure this directory is available for others you want your\n+changes to be pulled by.  Also make sure that you have the\n+'git-receive-pack' program on the $PATH.\n+\n+[ Side note: many installations of sshd does not invoke your\n+  shell as the login shell when you directly run programs; what\n+  this means is that if your login shell is bash, only .bashrc\n+  is read bypassing .bash_profile.  As a workaround, make sure\n+  .bashrc sets up $PATH so that 'git-receive-pack' program can\n+  be run.  ]\n+\n+Your 'public repository' is ready to accept your changes.  Now,\n+come back to the machine you have your private repository.  From\n+there, run this command:\n+\n+\tgit push <public-host>:/path/to/my-git.git master\n+\n+This synchronizes your public repository to match the named\n+branch head (i.e. refs/heads/master in this case) and objects\n+reachable from them in your current repository.\n+\n+As a real example, this is how I update my public git\n+repository.  Kernel.org mirror network takes care of the\n+propagation to other publically visible machines:\n+\n+\tgit push master.kernel.org:/pub/scm/git/git.git/ \n+\n"},{"id":"6176","messageId":"7vzmsnrjyf.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"7vzmsots7t.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Documentation: pull, push, packing repository and working with others.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-15T18:40:56Z","receivedAt":"2005-07-15T18:40:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Describe where you can pull from with a bit more detail.\nClarify description of pushing.\n\nAdd a section on packing repositories.\n\nAdd a section on recommended workflow for the project lead,\nsubsystem maintainers and individual developers.\n\nMove \"Tag\" section around to make the flow of example simpler to\nfollow.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/tutorial.txt |  371 ++++++++++++++++++++++++++++++++++----------\n 1 files changed, 290 insertions(+), 81 deletions(-)\n\n9ad5d377ecf29ab6d7044db128bee98bf9690bbe\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -453,6 +453,55 @@ With that, you should now be having some\n can explore on your own.\n \n \n+[ Side note: most likely, you are not directly using the core\n+  git Plumbing commands, but using Porcelain like Cogito on top\n+  of it.  Cogito works a bit differently and you usually do not\n+  have to run \"git-update-cache\" yourself for changed files (you\n+  do tell underlying git about additions and removals via\n+  \"cg-add\" and \"cg-rm\" commands).  Just before you make a commit\n+  with \"cg-commit\", Cogito figures out which files you modified,\n+  and runs \"git-update-cache\" on them for you.  ]\n+\n+\n+\tTagging a version\n+\t-----------------\n+\n+In git, there's two kinds of tags, a \"light\" one, and a \"signed tag\".\n+\n+A \"light\" tag is technically nothing more than a branch, except we put\n+it in the \".git/refs/tags/\" subdirectory instead of calling it a \"head\".\n+So the simplest form of tag involves nothing more than\n+\n+\tcat .git/HEAD > .git/refs/tags/my-first-tag\n+\n+after which point you can use this symbolic name for that particular\n+state. You can, for example, do\n+\n+\tgit diff my-first-tag\n+\n+to diff your current state against that tag (which at this point will\n+obviously be an empty diff, but if you continue to develop and commit\n+stuff, you can use your tag as a \"anchor-point\" to see what has changed\n+since you tagged it.\n+\n+A \"signed tag\" is actually a real git object, and contains not only a\n+pointer to the state you want to tag, but also a small tag name and\n+message, along with a PGP signature that says that yes, you really did\n+that tag. You create these signed tags with\n+\n+\tgit tag <tagname>\n+\n+which will sign the current HEAD (but you can also give it another\n+argument that specifies the thing to tag, ie you could have tagged the\n+current \"mybranch\" point by using \"git tag <tagname> mybranch\").\n+\n+You normally only do signed tags for major releases or things\n+like that, while the light-weight tags are useful for any marking you\n+want to do - any time you decide that you want to remember a certain\n+point, just create a private tag for it, and you have a nice symbolic\n+name for the state at that point.\n+\n+\n \tCopying archives\n \t-----------------\n \n@@ -729,117 +778,277 @@ simply do\n and optionally give a branch-name for the remote end as a second\n argument.\n \n-[ Todo: fill in real examples ]\n-\n-\n-\tTagging a version\n-\t-----------------\n-\n-In git, there's two kinds of tags, a \"light\" one, and a \"signed tag\".\n-\n-A \"light\" tag is technically nothing more than a branch, except we put\n-it in the \".git/refs/tags/\" subdirectory instead of calling it a \"head\".\n-So the simplest form of tag involves nothing more than\n-\n-\tcat .git/HEAD > .git/refs/tags/my-first-tag\n-\n-after which point you can use this symbolic name for that particular\n-state. You can, for example, do\n-\n-\tgit diff my-first-tag\n-\n-to diff your current state against that tag (which at this point will\n-obviously be an empty diff, but if you continue to develop and commit\n-stuff, you can use your tag as a \"anchor-point\" to see what has changed\n-since you tagged it.\n-\n-A \"signed tag\" is actually a real git object, and contains not only a\n-pointer to the state you want to tag, but also a small tag name and\n-message, along with a PGP signature that says that yes, you really did\n-that tag. You create these signed tags with\n-\n-\tgit tag <tagname>\n-\n-which will sign the current HEAD (but you can also give it another\n-argument that specifies the thing to tag, ie you could have tagged the\n-current \"mybranch\" point by using \"git tag <tagname> mybranch\").\n-\n-You normally only do signed tags for major releases or things\n-like that, while the light-weight tags are useful for any marking you\n-want to do - any time you decide that you want to remember a certain\n-point, just create a private tag for it, and you have a nice symbolic\n-name for the state at that point.\n-\n-[ to be continued.. cvsimports, pushing and pulling ]\n+The \"remote\" repository can even be on the same machine.  One of\n+the following notations can be used to name the repository to\n+pull from:\n+\n+\tRsync URL\n+\t\trsync://remote.machine/path/to/repo.git/\n+\n+\tHTTP(s) URL\n+\t\thttp://remote.machine/path/to/repo.git/\n+\n+\tGIT URL\n+\t\tgit://remote.machine/path/to/repo.git/\n+\t\tremote.machine:/path/to/repo.git/\n+\n+\tLocal directory\n+\t\t/path/to/repo.git/\n+\n+[ Side Note: currently, HTTP transport is slightly broken in\n+  that when the remote repository is \"packed\" they do not always\n+  work.  But we have not talked about packing repository yet, so\n+  let's not worry too much about it for now.  ]\n+\n+[ Digression: you could do without using any branches at all, by\n+  keeping as many local repositories as you would like to have\n+  branches, and merging between them with \"git pull\", just like\n+  you merge between branches.  The advantage of this approach is\n+  that it lets you keep set of files for each \"branch\" checked\n+  out and you may find it easier to switch back and forth if you\n+  juggle multiple lines of development simultaneously.  Of\n+  course, you will pay the price of more disk usage to hold\n+  multiple working trees, but disk space is cheap these days.  ]\n \n \n \tPublishing your work\n \t--------------------\n \n-We already talked about using somebody else's work from a remote\n-repository, in the \"merging external work\" section.  It involved\n-fetching the work from a remote repository; but how would _you_\n-prepare a repository so that other people can fetch from it?\n+So we can use somebody else's work from a remote repository; but\n+how can _you_ prepare a repository to let other people pull from\n+it?\n \n-Your real work happens in your working directory with your\n+Your do your real work in your working directory that has your\n primary repository hanging under it as its \".git\" subdirectory.\n-You _could_ make it accessible remotely and ask people to pull\n-from it, but in practice that is not the way things are usually\n-done.  A recommended way is to have a public repository, make it\n-reachable by other people, and when the changes you made in your\n-primary working directory are in good shape, update the public\n-repository with it.\n+You _could_ make that repository accessible remotely and ask\n+people to pull from it, but in practice that is not the way\n+things are usually done.  A recommended way is to have a public\n+repository, make it reachable by other people, and when the\n+changes you made in your primary working directory are in good\n+shape, update the public repository from it.  This is often\n+called \"pushing\".\n \n [ Side note: this public repository could further be mirrored,\n   and that is how kernel.org git repositories are done.  ]\n \n-Publishing the changes from your private repository to your\n-public repository requires you to have write privilege on the\n-machine that hosts your public repository, and it is internally\n-done via an SSH connection.\n-\n-First, you need to create an empty repository to push to on the\n-machine that houses your public repository.  This needs to be\n+Publishing the changes from your local (private) repository to\n+your remote (public) repository requires a write privilege on\n+the remote machine.  You need to have an SSH account there to\n+run a single command, \"git-receive-pack\".\n+\n+First, you need to create an empty repository on the remote\n+machine that will house your public repository.  This empty\n+repository will be populated and be kept up-to-date by pushing\n+into it later.  Obviously, this repository creation needs to be\n done only once.\n \n+[ Digression: \"git push\" uses a pair of programs,\n+  \"git-send-pack\" on your local machine, and \"git-receive-pack\"\n+  on the remote machine.  The communication between the two over\n+  the network internally uses an SSH connection.  ]\n+\n Your private repository's GIT directory is usually .git, but\n-often your public repository is named \"<projectname>.git\".\n-Let's create such a public repository for project \"my-git\".\n-After logging into the remote machine, create an empty\n-directory:\n+your public repository is often named after the project name,\n+i.e. \"<project>.git\".  Let's create such a public repository for\n+project \"my-git\".  After logging into the remote machine, create\n+an empty directory:\n \n \tmkdir my-git.git\n \n-Then, initialize that directory with git-init-db, but this time,\n-since it's name is not usual \".git\", we do things a bit\n-differently:\n+Then, make that directory into a GIT repository by running\n+git-init-db, but this time, since it's name is not the usual\n+\".git\", we do things slightly differently:\n \n \tGIT_DIR=my-git.git git-init-db\n \n Make sure this directory is available for others you want your\n-changes to be pulled by.  Also make sure that you have the\n-'git-receive-pack' program on the $PATH.\n-\n-[ Side note: many installations of sshd does not invoke your\n-  shell as the login shell when you directly run programs; what\n-  this means is that if your login shell is bash, only .bashrc\n-  is read bypassing .bash_profile.  As a workaround, make sure\n-  .bashrc sets up $PATH so that 'git-receive-pack' program can\n-  be run.  ]\n+changes to be pulled by via the transport of your choice.  Also\n+you need to make sure that you have the \"git-receive-pack\"\n+program on the $PATH.\n+\n+[ Side note: many installations of sshd do not invoke your shell\n+  as the login shell when you directly run programs; what this\n+  means is that if your login shell is bash, only .bashrc is\n+  read and not .bash_profile.  As a workaround, make sure\n+  .bashrc sets up $PATH so that you can run 'git-receive-pack'\n+  program.  ]\n \n-Your 'public repository' is ready to accept your changes.  Now,\n-come back to the machine you have your private repository.  From\n+Your \"public repository\" is now ready to accept your changes.\n+Come back to the machine you have your private repository.  From\n there, run this command:\n \n \tgit push <public-host>:/path/to/my-git.git master\n \n This synchronizes your public repository to match the named\n-branch head (i.e. refs/heads/master in this case) and objects\n-reachable from them in your current repository.\n+branch head (i.e. \"master\" in this case) and objects reachable\n+from them in your current repository.\n \n As a real example, this is how I update my public git\n repository.  Kernel.org mirror network takes care of the\n-propagation to other publically visible machines:\n+propagation to other publicly visible machines:\n \n \tgit push master.kernel.org:pub/scm/git/git.git/ \n \n+\n+[ Digression: your GIT \"public\" repository people can pull from\n+  is different from a public CVS repository that lets read-write\n+  access to multiple developers.  It is a copy of _your_ primary\n+  repository published for others to use, and you should not\n+  push into it from more than one repository (this means, not\n+  just disallowing other developers to push into it, but also\n+  you should push into it from a single repository of yours).\n+  Sharing the result of work done by multiple people are always\n+  done by pulling (i.e. fetching and merging) from public\n+  repositories of those people.  Typically this is done by the\n+  \"project lead\" person, and the resulting repository is\n+  published as the public repository of the \"project lead\" for\n+  everybody to base further changes on.  ]\n+\n+\n+\tPacking your repository\n+\t-----------------------\n+\n+Earlier, we saw that one file under .git/objects/??/ directory\n+is stored for each git object you create.  This representation\n+is convenient and efficient to create atomically and safely, but\n+not so to transport over the network.  Since git objects are\n+immutable once they are created, there is a way to optimize the\n+storage by \"packing them together\".  The command\n+\n+\tgit repack\n+\n+will do it for you.  If you followed the tutorial examples, you\n+would have accumulated about 17 objects in .git/objects/??/\n+directories by now.  \"git repack\" tells you how many objects it\n+packed, and stores the packed file in .git/objects/pack\n+directory.\n+\n+[ Side Note: you will see two files, pack-*.pack and pack-*.idx,\n+  in .git/objects/pack directory.  They are closely related to\n+  each other, and if you ever copy them by hand to a different\n+  repository for whatever reason, you should make sure you copy\n+  them together.  The former holds all the data from the objects\n+  in the pack, and the latter holds the index for random\n+  access.  ]\n+\n+If you are paranoid, running \"git-verify-pack\" command would\n+detect if you have a corrupt pack, but do not worry too much.\n+Our programs are always perfect ;-).\n+\n+Once you have packed objects, you do not need to leave the\n+unpacked objects that are contained in the pack file anymore.\n+\n+\tgit prune-packed\n+\n+would remove them for you.\n+\n+You can try running \"find .git/objects -type f\" before and after\n+you run \"git prune-packed\" if you are curious.\n+\n+[ Side Note: as we already mentioned, \"git pull\" is broken for\n+  some transports dealing with packed repositories right now, so\n+  do not run \"git prune-packed\" if you plan to give \"git pull\"\n+  access via HTTP transport for now.  ]\n+\n+If you run \"git repack\" again at this point, it will say\n+\"Nothing to pack\".  Once you continue your development and\n+accumulate the changes, running \"git repack\" again will create a\n+new pack, that contains objects created since you packed your\n+archive the last time.  We recommend that you pack your project\n+soon after the initial import (unless you are starting your\n+project from scratch), and then run \"git repack\" every once in a\n+while, depending on how active your project is.\n+\n+When a repository is synchronized via \"git push\" and \"git pull\",\n+objects packed in the source repository is usually stored\n+unpacked in the destination, unless rsync transport is used.\n+\n+\n+\tWorking with Others\n+\t-------------------\n+\n+A recommended work cycle for a \"project lead\" is like this:\n+\n+ (1) Prepare your primary repository on your local machine. Your\n+     work is done there.\n+\n+ (2) Prepare a public repository accessible to others.\n+\n+ (3) Push into the public repository from your primary\n+     repository.\n+\n+ (4) \"git repack\" the public repository.  This establishes a big\n+     pack that contains the initial set of objects.\n+\n+ (5) Keep working in your primary repository, and push your\n+     changes to the public repository.  Your changes include\n+     your own, patches you receive via e-mail, and merge resulting\n+     from pulling the \"public\" repositories of your \"subsystem\n+     maintainers\".\n+\n+     You can repack this private repository whenever you feel\n+     like.\n+\n+ (6) Every once in a while, \"git repack\" the public repository.\n+     Go back to step (5) and continue working.\n+\n+A recommended work cycle for a \"subsystem maintainer\" that\n+works on that project and has own \"public repository\" is like\n+this:\n+\n+ (1) Prepare your work repository, by \"git clone\" the public\n+     repository of the \"project lead\".\n+\n+ (2) Prepare a public repository accessible to others.\n+\n+ (3) Copy over the packed files from \"project lead\" public\n+     repository to your public repository by hand; this part is\n+     currently not automated.\n+\n+ (4) Push into the public repository from your primary\n+     repository.\n+\n+ (5) Keep working in your primary repository, and push your\n+     changes to your public repository, and ask your \"project\n+     lead\" to pull from it.  Your changes include your own,\n+     patches you receive via e-mail, and merge resulting from\n+     pulling the \"public\" repositories of your \"project lead\"\n+     and possibly your \"sub-subsystem maintainers\".\n+\n+     You can repack this private repository whenever you feel\n+     like.\n+\n+ (6) Every once in a while, \"git repack\" the public repository.\n+     Go back to step (5) and continue working.\n+\n+A recommended work cycle for an \"individual developer\" who does\n+not have a \"public\" repository is somewhat different.  It goes\n+like this:\n+\n+ (1) Prepare your work repositories, by \"git clone\" the public\n+     repository of the \"project lead\" (or \"subsystem\n+     maintainer\", if you work on a subsystem).\n+\n+ (2) Copy .git/refs/master to .git/refs/upstream.\n+\n+ (3) Do your work there.  Make commits.\n+\n+ (4) Run \"git fetch\" from the public repository of your upstream\n+     every once in a while.  This does only the first half of\n+     \"git pull\" but does not merge.  The head of the public\n+     repository is stored in .git/FETCH_HEAD.  Copy it in\n+     .git/refs/heads/upstream.\n+\n+ (5) Use \"git cherry\" to see which ones of your patches were\n+     accepted, and/or use \"git rebase\" to port your unmerged\n+     changes forward to the updated upstream.\n+\n+ (6) Use \"git format-patch upstream\" to prepare patches for\n+     e-mail submission to your upstream and send it out.\n+     Go back to step (3) and continue. \n+\n+[Side Note: I think Cogito calls this upstream \"origin\".\n+ Somebody care to confirm or deny?  ]\n+\n+\n+[ to be continued.. cvsimports ]\n"},{"id":"6177","messageId":"7voe93rbmu.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"7vzmsots7t.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] fetch/pull: support Cogito-style remote branch information.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-15T21:40:41Z","receivedAt":"2005-07-15T21:40:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Since pull and fetch are done often against the same remote\nrepository, keeping the URL to pull from along with the name of\nthe head in $GIT_DIR/branches/$name like Cogito does makes a lot\nof sense.  Adopt that and be compatible with Cogito for usability.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n*** Although I have tested it to see the change does what it\n*** advertises to do, I would like to hear comments from the\n*** list if things like this would be good to have in the\n*** barebone Porcelain.  I personally think this is a good\n*** usability enhancement without complicating it too much.\n\n Documentation/git-fetch-script.txt |   40 +++++++++++++++++++++++++++\n Documentation/git-pull-script.txt  |   20 +++++++++++--\n Documentation/git.txt              |    9 +++++-\n Documentation/tutorial.txt         |   13 +++++++++\n git-fetch-script                   |   44 +++++++++++++++++++++++------\n git-pull-script                    |   54 +++++++++++++++++++++++++++---------\n 6 files changed, 152 insertions(+), 28 deletions(-)\n create mode 100644 Documentation/git-fetch-script.txt\n\n804f1002c007106fb1aeade4b4549169e92042a2\ndiff --git a/Documentation/git-fetch-script.txt b/Documentation/git-fetch-script.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/git-fetch-script.txt\n@@ -0,0 +1,40 @@\n+git-fetch-script(1)\n+===================\n+v0.1, July 2005\n+\n+NAME\n+----\n+git-fetch-script - Download objects and a head from another repository.\n+\n+\n+SYNOPSIS\n+--------\n+'git-fetch-script' <repository> [ <head> | tag <tag> ]\n+\n+'git-fetch-script' -b <name>\n+\n+\n+DESCRIPTION\n+-----------\n+Fetches a named head or a tag from another repository, along\n+with the objects necessary to complete that head or tag.  The\n+head to pull defaults to HEAD if unspecified.\n+\n+When '-b' flag is specified to give a name, not an URL to the\n+repository, it reads from .git/branches/<name> to get the\n+repository URL, possibly immediately followed by '#' and the\n+name of the head or the tag.  The latter is meant to make this\n+command a bit more Cogito-user friendly.\n+\n+\n+Author\n+------\n+Written by Linus Torvalds <torvalds@osdl.org>\n+\n+Documentation\n+--------------\n+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.\n+\n+GIT\n+---\n+Part of the link:git.html[git] suite\ndiff --git a/Documentation/git-pull-script.txt b/Documentation/git-pull-script.txt\n--- a/Documentation/git-pull-script.txt\n+++ b/Documentation/git-pull-script.txt\n@@ -4,17 +4,29 @@ v0.1, May 2005\n \n NAME\n ----\n-git-pull-script - Script used by Linus to pull and merge a remote repository\n+git-pull-script - Pull and merge from another repository.\n \n \n SYNOPSIS\n --------\n-'git-pull-script'\n+'git-pull-script' <repository> [ <head> | tag <tag> ]\n+\n+'git-pull-script' -b <name>\n+\n \n DESCRIPTION\n -----------\n-This script is used by Linus to pull from a remote repository and perform\n-a merge.\n+Fetches a named head or a tag from another repository, along\n+with the objects necessary to complete that head or tag, and\n+merges it into the current repository by running\n+'git-resolve-script'.  The head to pull defaults to HEAD if\n+unspecified.\n+\n+When '-b' flag is specified to give a name, not an URL to the\n+repository, it reads from .git/branches/<name> to get the\n+repository URL, possibly immediately followed by '#' and the\n+name of the head or the tag.  The latter is meant to make this\n+command a bit more Cogito-user friendly.\n \n \n Author\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -121,6 +121,9 @@ The interrogate commands may create file\n touch the working file set - but in general they don't\n \n \n+Synching multiple repositories\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n link:git-clone-script.html[git-clone-script]::\n \tClones a repository into the current repository (user interface)\n \n@@ -128,10 +131,14 @@ link:git-clone-pack.html[git-clone-pack]\n \tClones a repository into the current repository (engine\n \tfor ssh and local transport)\n \n-link:git-pull-script.html[git-pull-script]::\n+link:git-fetch-script.html[git-pull-script]::\n \tPull from a repote repository via various protocols\n \t(user interface).\n \n+link:git-pull-script.html[git-pull-script]::\n+\tFetch from and merge with a repote repository via\n+\tvarious protocols (user interface).\n+\n link:git-http-pull.html[git-http-pull]::\n \tDownloads a remote GIT repository via HTTP\n \ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -810,6 +810,19 @@ pull from:\n   course, you will pay the price of more disk usage to hold\n   multiple working trees, but disk space is cheap these days.  ]\n \n+It is likely that you will be pulling from the same remote\n+repository from time to time.  As a short hand, you can store\n+the remote repository URL in a file under .git/branches/\n+directory, like this:\n+\n+\tmkdir -p .git/branches\n+\techo rsync://rsync.kernel.org/pub/scm/git/git.git/ \\\n+\t    >.git/branches/linus\n+\n+and give \"-b\" option to \"git pull\" to use that URL:\n+\n+\tgit pull -b linus\n+\n \n \tPublishing your work\n \t--------------------\ndiff --git a/git-fetch-script b/git-fetch-script\n--- a/git-fetch-script\n+++ b/git-fetch-script\n@@ -1,23 +1,47 @@\n #!/bin/sh\n #\n-destination=FETCH_HEAD\n-\n-merge_repo=$1\n-merge_name=${2:-HEAD}\n-if [ \"$2\" = \"tag\" ]; then\n-\tmerge_name=\"refs/tags/$3\"\n-\tdestination=\"$merge_name\"\n-fi\n \n . git-sh-setup-script || die \"Not a git archive\"\n \n+destination=FETCH_HEAD\n+\n+case \"$1\" in\n+-b)\n+\t# Using Cogito style remote branch information.\n+\t# The user did not call us via git-pull, but just wants to\n+\t# fetch from the remote head.\n+\tname=$2 &&\n+\tdestination=refs/heads/\"$name\" &&\n+\tremote_branch=$(cat \"$GIT_DIR/branches/$name\") ||\n+\tdie \"cannot read remote branch $name.\"\n+\tcase \"$remote_branch\" in\n+\t*'#'*)\n+\t\tmerge_repo=$(expr \"$remote_branch\" : '\\(.*\\)#') &&\n+\t\tmerge_name=$(expr \"$remote_branch\" : '.*#\\(.*\\)$')\n+\t\t;;\n+        *)\n+\t\tmerge_repo=\"$remote_branch\" &&\n+\t\tmerge_name=HEAD\n+\t\t;;\n+\tesac\n+\t;;\n+*)\n+\tmerge_repo=$1\n+\tmerge_name=${2:-HEAD}\n+\tif [ \"$2\" = \"tag\" ]; then\n+\t\tmerge_name=\"refs/tags/$3\"\n+\t\tdestination=\"$merge_name\"\n+\tfi\n+\t;;\n+esac\n+\n TMP_HEAD=\"$GIT_DIR/TMP_HEAD\"\n \n case \"$merge_repo\" in\n http://*)\n \thead=$(wget -q -O - \"$merge_repo/$merge_name\") || exit 1\n-\techo Fetching $head using http\n-\tgit-http-pull -v -a \"$head\" \"$merge_repo/\"\n+\techo Fetching $merge_name using http\n+\tgit-http-pull -v -a \"$merge_name\" \"$merge_repo/\"\n \t;;\n rsync://*)\n \trsync -L \"$merge_repo/$merge_name\" \"$TMP_HEAD\" || exit 1\ndiff --git a/git-pull-script b/git-pull-script\n--- a/git-pull-script\n+++ b/git-pull-script\n@@ -2,20 +2,48 @@\n #\n . git-sh-setup-script || die \"Not a git archive\"\n \n-merge_repo=$1\n+usage () {\n+    echo >&2 \"* git pull <repo> [ <head> | tag <tag> ]\"\n+    echo >&2 \"* git pull -b <name>\"\n+    exit 1\n+}\n \n-merge_name=$(echo \"$1\" | sed 's:\\.git/*$::')\n-merge_head=HEAD\n-type=head\n-if [ \"$2\" = \"tag\" ]; then\n-   type=tag\n-   shift\n-fi\n-if [ \"$2\" ]\n-then\n-   merge_name=\"$type '$2' of $merge_name\"\n-   merge_head=\"refs/${type}s/$2\"\n-fi\n+case \"$1\" in\n+-b)\n+\t# Use Cogito style remote branch information.\n+\tname=$2 &&\n+\tremote_branch=$(cat \"$GIT_DIR/branches/$name\") ||\n+\tdie \"cannot read remote branch $name.\"\n+\tcase \"$remote_branch\" in\n+\t*'#'*)\n+\t\tmerge_repo=$(expr \"$remote_branch\" : '\\(.*\\)#') &&\n+\t\tmerge_head=$(expr \"$remote_branch\" : '.*#\\(.*\\)$') &&\n+\t\tmerge_name=$(echo \"$merge_repo\" | sed 's:\\.git/*$::') &&\n+\t\tmerge_name=\"'$merge_head' of $merge_name\"\n+\t\t;;\n+        *)\n+\t\tmerge_head=HEAD &&\n+\t\tmerge_repo=\"$remote_branch\" &&\n+\t\tmerge_name=$(echo \"$merge_repo\" | sed 's:\\.git/*$::')\n+\t\t;;\n+\tesac\n+\t;;\n+*)\n+\tmerge_repo=$1\n+\tmerge_name=$(echo \"$merge_repo\" | sed 's:\\.git/*$::')\n+\tmerge_head=HEAD\n+\ttype=head\n+\tif [ \"$2\" = \"tag\" ]; then\n+\t\ttype=tag\n+\t\tshift\n+\tfi\n+\tif [ \"$2\" ]\n+\tthen\n+\t\tmerge_name=\"$type '$2' of $merge_name\"\n+\t\tmerge_head=\"refs/${type}s/$2\"\n+\tfi\n+\t;;\n+esac\n \n git-fetch-script \"$merge_repo\" \"$merge_head\" || exit 1\n \n"},{"id":"6178","messageId":"Pine.LNX.4.58.0507151529590.19183@g5.osdl.org","threadId":"1233","inReplyTo":"7voe93rbmu.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fetch/pull: support Cogito-style remote branch information.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-15T22:42:42Z","receivedAt":"2005-07-15T22:42:42Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nHmm..\n\nThis patch actually brings up two different issues\n\n - I actually prefer code and documentation to be separated. Finding the \n   actual changes to code in this patch is made much harder by the fact\n   that most of the changes are documentation updates. In many ways it \n   would have been nicer to separate the two out - first the actual \n   change, then the docs updates.\n\n   Maybe that's just me.\n\n - I'd much rather have a generic \"address rewriting layer\" than a \"-b\" \n   flag.\n\n   I don't mind the shorthand at all, but I don't think it should be that\n   special. It's not \"worthy\" of a flag - if you have a shorthand that \n   says \"linus == rsync://kernel.org/pub/scm/git/git.git\", then I think it \n   should just work, and \n\n\tgit pull linus\n\n   should end up not needing a \"-b\" flag. It's not like there is any \n   real ambiguity.\n\nNow, I'd like the address rewriting to actually be fairly capable, so it \nshould be a script of its own.\n\nAnd it's not necessarily just the branch handling, but more of a generic\nshorthand: I'd love to be able to mix something like\n\n\tgit pull jgarzik/misc-2.6 upstream\n\nand \"jgarzik\" would be expanded (through something like .git/branches) to \n\"master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/\"), resulting in the \n_full_ path being expanded to\n\n\tmaster.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 upstream\n\nwhich I have to write out in full (or, more commonly, cut-and-paste) right\nnow.\n\nHmm?\n\n\t\tLinus\n"},{"id":"6179","messageId":"7v64vbpsu4.fsf@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"Pine.LNX.4.58.0507151529590.19183@g5.osdl.org","subject":"Re: [PATCH] fetch/pull: support Cogito-style remote branch information.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-15T23:12:03Z","receivedAt":"2005-07-15T23:12:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n>  - I actually prefer code and documentation to be separated. ...\n>    first the actual change, then the docs updates.\n\nUnderstood.\n\n>  - I'd much rather have a generic \"address rewriting layer\" than a \"-b\" \n>    flag.\n>\n>    I don't mind the shorthand at all, but I don't think it should be that\n>    special. It's not \"worthy\" of a flag - if you have a shorthand that \n>    says \"linus == rsync://kernel.org/pub/scm/git/git.git\", then I think it \n>    should just work, and \n>\n> \tgit pull linus\n>\n>    should end up not needing a \"-b\" flag. It's not like there is any \n>    real ambiguity.\n\nThat makes sense.  Naturally,\n\n\tgit pull linus experimental\n        git pull linus tag v2.6.13\n\nshould expand to:\n\n       git pull rsync://kernel.org/pub/scm/git/git.git/ experimental\n       git pull rsync://kernel.org/pub/scm/git/git.git/ tag v2.6.13\n\nIf a user is usually interested in e100 driver work, we should\nallow:\n\n\techo rsync://kernel.org/pub/.../git/jgarzik/netdev-2.6.git#e100\n\t        >.git/branches/jgarzik-e100\n\nand \"git pull jgarzik-e100\" should expand to:\n\n\tgit pull rsync://kernel.org/pub/.../netdev-2.6.git/ e100\n\nIf the user says:\n\n\tgit fetch jgarzik-e100 ieee80211-wifi\n\nbecause the user wanted to peek his other branch just once, but\ndid not want to bother creating another remote reference\n(\"jgarzik-wifi\", perhaps) for this one-time use.  This should\nexpand to:\n\n\tgit fetch rsync://kernel.org/pub/.../netdev-2.6.git/ ieee80211-wifi\n\n> And it's not necessarily just the branch handling, but more of a generic\n> shorthand: I'd love to be able to mix something like\n>\n> \tgit pull jgarzik/misc-2.6 upstream\n>\n> and \"jgarzik\" would be expanded (through something like .git/branches) to \n> \"master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/\"), resulting in the \n> _full_ path being expanded to\n>\n> \tmaster.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 upstream\n\nNice, and sounds doable without too much ambiguities.  This last\none, however, needs to be coordinated with Pasky, if we want to\nuse .git/branches/$name convention.  I think Cogito would barf\nwith your partial URL that ends with \"...git/jgarzik/\".\n\nI'll code something up.\n"},{"id":"6182","messageId":"7vy887o17n.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"7voe93rbmu.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] Documentation: adjust cvsimport command line.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T03:54:04Z","receivedAt":"2005-07-16T03:54:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The cvsimport example in the cvs migration document was still\nusing the old syntax for target repository after new and\nimproved cvsimport-script was merged.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/cvs-migration.txt |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\nb29d86237da6af317cd0053aa9c8ebd72455c113\ndiff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt\n--- a/Documentation/cvs-migration.txt\n+++ b/Documentation/cvs-migration.txt\n@@ -63,7 +63,7 @@ Once you've gotten (and installed) cvsps\n any more familiar with it, but make sure it is in your path. After that,\n the magic command line is\n \n-\tgit cvsimport -v -d <cvsroot> <module> <destination>\n+\tgit cvsimport -v -d <cvsroot> -C <destination> <module>\n \n which will do exactly what you'd think it does: it will create a git\n archive of the named CVS module. The new archive will be created in the\n"},{"id":"6185","messageId":"7virzbnruf.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"Pine.LNX.4.58.0507151529590.19183@g5.osdl.org","subject":"[PATCH] fetch/pull: short-hand notation for remote repositories.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T07:16:24Z","receivedAt":"2005-07-16T07:16:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Since pull and fetch are done often against the same remote\nrepository repeatedly, keeping the URL to pull from along with\nthe name of the head to use in $GIT_DIR/branches/$name makes a\nlot of sense.  Adopt that convention from Cogito, and try to be\ncompatible when possible; storing a partial URL and completing\nit with a trailing path may not be understood by Cogito.\n\nWhile we are at it, fix pulling a tag.  Earlier, we updated only\nrefs/tags/$tag without updating FETCH_HEAD, and called\nresolve-script using a stale (or absent) FETCH_HEAD.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Makefile         |    2 +\n git-fetch-script |   36 ++++++++++++++-----------\n git-parse-remote |   79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++\n git-pull-script  |   19 ++-----------\n 4 files changed, 104 insertions(+), 32 deletions(-)\n create mode 100755 git-parse-remote\n\n431b72ee18b73aac44048ac6c4cb62e0618c6f6e\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -36,7 +36,7 @@ SCRIPTS=git git-apply-patch-script git-m\n \tgit-reset-script git-add-script git-checkout-script git-clone-script \\\n \tgitk git-cherry git-rebase-script git-relink-script git-repack-script \\\n \tgit-format-patch-script git-sh-setup-script git-push-script \\\n-\tgit-branch-script\n+\tgit-branch-script git-parse-remote\n \n PROG=   git-update-cache git-diff-files git-init-db git-write-tree \\\n \tgit-read-tree git-commit-tree git-cat-file git-fsck-cache \\\ndiff --git a/git-fetch-script b/git-fetch-script\n--- a/git-fetch-script\n+++ b/git-fetch-script\n@@ -1,33 +1,39 @@\n #!/bin/sh\n #\n-destination=FETCH_HEAD\n-\n-merge_repo=$1\n-merge_name=${2:-HEAD}\n-if [ \"$2\" = \"tag\" ]; then\n-\tmerge_name=\"refs/tags/$3\"\n-\tdestination=\"$merge_name\"\n-fi\n-\n . git-sh-setup-script || die \"Not a git archive\"\n+. git-parse-remote \"$@\"\n+merge_repo=\"$_remote_repo\"\n+merge_head=\"$_remote_head\"\n+merge_store=\"$_remote_store\"\n \n TMP_HEAD=\"$GIT_DIR/TMP_HEAD\"\n \n case \"$merge_repo\" in\n http://*)\n-\thead=$(wget -q -O - \"$merge_repo/$merge_name\") || exit 1\n-\techo Fetching $head using http\n-\tgit-http-pull -v -a \"$head\" \"$merge_repo/\"\n+\thead=$(wget -q -O - \"$merge_repo/$merge_head\") || exit 1\n+\techo Fetching \"$merge_head\" using http\n+\tgit-http-pull -v -a \"$merge_head\" \"$merge_repo/\"\n \t;;\n rsync://*)\n-\trsync -L \"$merge_repo/$merge_name\" \"$TMP_HEAD\" || exit 1\n+\trsync -L \"$merge_repo/$merge_head\" \"$TMP_HEAD\" || exit 1\n \thead=$(git-rev-parse TMP_HEAD)\n \trm -f \"$TMP_HEAD\"\n \trsync -avz --ignore-existing \"$merge_repo/objects/\" \"$GIT_OBJECT_DIRECTORY/\"\n \t;;\n *)\n-\thead=$(git-fetch-pack \"$merge_repo\" \"$merge_name\")\n+\thead=$(git-fetch-pack \"$merge_repo\" \"$merge_head\")\n \t;;\n esac || exit 1\n+\n git-rev-parse --verify \"$head\" > /dev/null || exit 1\n-echo \"$head\" > \"$GIT_DIR/$destination\"\n+\n+case \"$merge_store\" in\n+'')\n+\techo \"$head\" > \"$GIT_DIR/$merge_store\"\n+esac &&\n+\n+# FETCH_HEAD is fed to git-resolve-script which will eventually be\n+# passed to git-commit-tree as one of the parents.  Make sure we do\n+# not give a tag object ID.\n+\n+git-rev-parse \"$head^0\" >\"$GIT_DIR/FETCH_HEAD\"\ndiff --git a/git-parse-remote b/git-parse-remote\nnew file mode 100755\n--- /dev/null\n+++ b/git-parse-remote\n@@ -0,0 +1,79 @@\n+: To be included in git-pull and git-fetch scripts.\n+\n+# A remote repository can be specified on the command line\n+# in one of the following formats:\n+#\n+#\t<repo>\n+#\t<repo> <head>\n+#\t<repo> tag <tag>\n+#\n+# where <repo> could be one of:\n+#\n+#\ta URL (including absolute or local pathname)\n+#\ta short-hand\n+#\ta short-hand followed by a trailing path\n+#\n+# A short-hand <name> has a corresponding file $GIT_DIR/branches/<name>,\n+# whose contents is a URL, possibly followed by a URL fragment #<head>\n+# to name the default branch on the remote side to fetch from.\n+\n+_remote_repo= _remote_store= _remote_head= _remote_name=\n+\n+case \"$1\" in\n+*:* | /* | ../* | ./* )\n+\t_remote_repo=\"$1\"\n+\t;;\n+* )\n+\t# otherwise, it is a short hand.\n+\tcase \"$1\" in\n+\t*/*)\n+\t\t# a short-hand followed by a trailing path\n+\t\t_token=$(expr \"$1\" : '\\([^/]*\\)/')\n+\t\t_rest=$(expr \"$1\" : '[^/]*\\(/.*\\)$')\n+\t\t;;\n+\t*)\n+\t\t_token=\"$1\"\n+\t\t_rest=\n+\t\t_remote_store=\"refs/heads/$_token\"\n+\t\t;;\n+\tesac\n+\ttest -f \"$GIT_DIR/branches/$_token\" ||\n+\tdie \"No such remote branch: $_token\"\n+\n+\t_remote_repo=$(cat \"$GIT_DIR/branches/$_token\")\"$_rest\"\n+\t;;\n+esac\n+\n+case \"$_remote_repo\" in\n+*\"#\"*)\n+\t_remote_head=`expr \"$_remote_repo\" : '.*#\\(.*\\)$'`\n+\t_remote_repo=`expr \"$_remote_repo\" : '\\(.*\\)#'`\n+\t;;\n+esac\n+\n+_remote_name=$(echo \"$_remote_repo\" | sed 's|\\.git/*$||')\n+\n+case \"$2\" in\n+tag)\n+\t_remote_name=\"tag '$3' of $_remote_name\"\n+\t_remote_head=\"refs/tags/$3\"\n+\t_remote_store=\"$_remote_head\"\n+\t;;\n+?*)\n+\t# command line specified a head explicitly; do not\n+\t# store the fetched head as a branch head.\n+\t_remote_name=\"head '$2' of $_remote_name\"\n+\t_remote_head=\"refs/heads/$2\"\n+\t_remote_store=''\n+\t;;\n+'')\n+\tcase \"$_remote_head\" in\n+\t'')\n+\t\t_remote_head=HEAD ;;\n+\t*)\n+\t\t_remote_head=\"refs/heads/$_remote_head\"\n+\t\t_remote_name=\"head '$_remote_head' of $_remote_name\"\n+\t\t;;\n+\tesac\n+\t;;\n+esac\ndiff --git a/git-pull-script b/git-pull-script\n--- a/git-pull-script\n+++ b/git-pull-script\n@@ -1,23 +1,10 @@\n #!/bin/sh\n #\n . git-sh-setup-script || die \"Not a git archive\"\n+. git-parse-remote \"$@\"\n+merge_name=\"$_remote_name\"\n \n-merge_repo=$1\n-\n-merge_name=$(echo \"$1\" | sed 's:\\.git/*$::')\n-merge_head=HEAD\n-type=head\n-if [ \"$2\" = \"tag\" ]; then\n-   type=tag\n-   shift\n-fi\n-if [ \"$2\" ]\n-then\n-   merge_name=\"$type '$2' of $merge_name\"\n-   merge_head=\"refs/${type}s/$2\"\n-fi\n-\n-git-fetch-script \"$merge_repo\" \"$merge_head\" || exit 1\n+git-fetch-script \"$@\" || exit 1\n \n git-resolve-script \\\n \t\"$(cat \"$GIT_DIR\"/HEAD)\" \\\n"},{"id":"6186","messageId":"7vacknnrs9.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"Pine.LNX.4.58.0507151529590.19183@g5.osdl.org","subject":"[PATCH] Documentation: describe short-hand used in fetch/pull.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T07:17:42Z","receivedAt":"2005-07-16T07:17:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Describe short-hand for remote repository used in fetch/pull.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/git-fetch-script.txt |   47 ++++++++++++++++++++++++++++++++++++\n Documentation/git-pull-script.txt  |   16 ++++++++----\n Documentation/git.txt              |    9 ++++++-\n Documentation/pull-fetch-param.txt |   36 ++++++++++++++++++++++++++++\n Documentation/tutorial.txt         |   28 +++++++++++++++++++++\n 5 files changed, 130 insertions(+), 6 deletions(-)\n create mode 100644 Documentation/git-fetch-script.txt\n create mode 100644 Documentation/pull-fetch-param.txt\n\nd4d1afc8c8e8417b8a30ecfc8f5e32be2b47c956\ndiff --git a/Documentation/git-fetch-script.txt b/Documentation/git-fetch-script.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/git-fetch-script.txt\n@@ -0,0 +1,47 @@\n+git-fetch-script(1)\n+===================\n+v0.1, July 2005\n+\n+NAME\n+----\n+git-fetch-script - Download objects and a head from another repository.\n+\n+\n+SYNOPSIS\n+--------\n+'git-fetch-script' <repository> [ <head> | tag <tag> ]\n+\n+\n+DESCRIPTION\n+-----------\n+Fetches a named head or a tag from another repository, along\n+with the objects necessary to complete that head or tag.  The\n+head to pull defaults to HEAD if unspecified.  The head or tag\n+fetched from the remote repository is stored in\n+$GIT_DIR/FETCH_HEAD.\n+\n+When a <tag> is specified, the <tag> fetched from the remote is\n+also copied to the local $GIT_DIR/tags/<tag> file.  When no\n+<head> nor <tag> is specified, and <repository> was specified\n+with the short-hand notation (i.e. naming a file under the\n+$GIT_DIR/branches directory), the head fetched from the remote\n+repository is also copied to the local $GIT_DIR/heads/<repository>\n+file.\n+\n+\n+OPTIONS\n+-------\n+include::pull-fetch-param.txt[]\n+\n+\n+Author\n+------\n+Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>\n+\n+Documentation\n+--------------\n+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.\n+\n+GIT\n+---\n+Part of the link:git.html[git] suite\ndiff --git a/Documentation/git-pull-script.txt b/Documentation/git-pull-script.txt\n--- a/Documentation/git-pull-script.txt\n+++ b/Documentation/git-pull-script.txt\n@@ -4,22 +4,28 @@ v0.1, May 2005\n \n NAME\n ----\n-git-pull-script - Script used by Linus to pull and merge a remote repository\n+git-pull-script - Pull and merge from another repository.\n \n \n SYNOPSIS\n --------\n-'git-pull-script'\n+'git-pull-script' <repository> [ <head> | tag <tag> ]\n+\n \n DESCRIPTION\n -----------\n-This script is used by Linus to pull from a remote repository and perform\n-a merge.\n+Runs 'git-fetch-script' with the given parameters, then\n+'git-resolve-script' to merge the local HEAD and FETCH_HEAD.\n+\n+\n+OPTIONS\n+-------\n+include::pull-fetch-param.txt[]\n \n \n Author\n ------\n-Written by Linus Torvalds <torvalds@osdl.org>\n+Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>\n \n Documentation\n --------------\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -121,6 +121,9 @@ The interrogate commands may create file\n touch the working file set - but in general they don't\n \n \n+Synching repositories\n+~~~~~~~~~~~~~~~~~~~~~\n+\n link:git-clone-script.html[git-clone-script]::\n \tClones a repository into the current repository (user interface)\n \n@@ -128,10 +131,14 @@ link:git-clone-pack.html[git-clone-pack]\n \tClones a repository into the current repository (engine\n \tfor ssh and local transport)\n \n-link:git-pull-script.html[git-pull-script]::\n+link:git-fetch-script.html[git-pull-script]::\n \tPull from a repote repository via various protocols\n \t(user interface).\n \n+link:git-pull-script.html[git-pull-script]::\n+\tFetch from and merge with a repote repository via\n+\tvarious protocols (user interface).\n+\n link:git-http-pull.html[git-http-pull]::\n \tDownloads a remote GIT repository via HTTP\n \ndiff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/pull-fetch-param.txt\n@@ -0,0 +1,36 @@\n+<repository>::\n+\tThe \"remote\" repository to pull from.  One of the\n+\tfollowing notations can be used to name the repository\n+\tto pull from:\n+\n+\t\tRsync URL\n+\t\t\trsync://remote.machine/path/to/repo.git/\n+\n+\t\tHTTP(s) URL\n+\t\t\thttp://remote.machine/path/to/repo.git/\n+\n+\t\tGIT URL\n+\t\t\tgit://remote.machine/path/to/repo.git/\n+\t\t\tremote.machine:/path/to/repo.git/\n+\n+\t\tLocal directory\n+\t\t\t/path/to/repo.git/\n+\n+\tIn addition to that, as a short-hand, the name of a file\n+\tin $GIT_DIR/branches directory can be specified; the\n+\tnamed file should contain a single line, a URL in one of\n+\tthe above formats, optionally followed by a hash '#' and\n+\tthe name of remote head.\n+\n+<head>::\n+\tThe remote head name to fetch from.  That is, make the\n+\tobjects reachable from the commit recorded in\n+\t$GIT_DIR/refs/heads/<head> in the remote repository\n+\tavailable locally.\n+\n+tag <tag>::\n+\tThe remote head tag to fetch from.  That is, make the\n+\tobjects reachable from the commit recorded in\n+\t$GIT_DIR/refs/tags/<tag> in the remote repository\n+\tavailable locally.\n+\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -810,6 +810,34 @@ pull from:\n   course, you will pay the price of more disk usage to hold\n   multiple working trees, but disk space is cheap these days.  ]\n \n+It is likely that you will be pulling from the same remote\n+repository from time to time.  As a short hand, you can store\n+the remote repository URL in a file under .git/branches/\n+directory, like this:\n+\n+\tmkdir -p .git/branches\n+\techo rsync://kernel.org/pub/scm/git/git.git/ \\\n+\t    >.git/branches/linus\n+\n+and use the filenae to \"git pull\" instead of the full URL.\n+The contents of a file under .git/branches can even be a prefix\n+of a full URL, like this:\n+\n+\techo rsync://kernel.org/pub/.../jgarzik/\n+\t        >.git/branches/jgarzik\n+\n+Examples.\n+\n+\t(1) git pull linus\n+\t(2) git pull linus tag v0.99.1\n+\t(3) git pull jgarzik/netdev-2.6.git/ e100\n+\n+the above are equivalent to:\n+\n+\t(1) git pull rsync://kernel.org/pub/scm/git/git.git/ HEAD\n+\t(2) git pull rsync://kernel.org/pub/scm/git/git.git/ tag v0.99.1\n+\t(3) git pull rsync://kernel.org/pub/.../jgarzik/netdev-2.6.git e100\n+\n \n \tPublishing your work\n \t--------------------\n"},{"id":"6188","messageId":"7vek9yn1f5.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"7virzbnruf.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH-fix] fetch/pull: short-hand notation for remote repositories.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T16:47:10Z","receivedAt":"2005-07-16T16:47:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The logic to decide when to store fetched head/tag under\n$GIT_DIR/refs/, and http transport were broken in the previous\nround. \n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n*** I see you have already merged my broken one; sorry.\n\n*** Anything written under the influence should be tested as twice\n*** as hard than usual before being sent --- Don't drink and\n*** develop ;-).  *Blush*\n\ncd /opt/packrat/playpen/public/in-place/git/git.junio/\njit-diff 8:10\n# - 4: Documentation: describe short-hand used in fetch/pull.\n# + 6: git-fetch-script: fix thinko in http fetch.\ndiff --git a/git-fetch-script b/git-fetch-script\n--- a/git-fetch-script\n+++ b/git-fetch-script\n@@ -12,7 +12,7 @@ case \"$merge_repo\" in\n http://*)\n \thead=$(wget -q -O - \"$merge_repo/$merge_head\") || exit 1\n \techo Fetching \"$merge_head\" using http\n-\tgit-http-pull -v -a \"$merge_head\" \"$merge_repo/\"\n+\tgit-http-pull -v -a \"$head\" \"$merge_repo/\"\n \t;;\n rsync://*)\n \trsync -L \"$merge_repo/$merge_head\" \"$TMP_HEAD\" || exit 1\n@@ -27,10 +27,10 @@ esac || exit 1\n \n git-rev-parse --verify \"$head\" > /dev/null || exit 1\n \n-case \"$merge_store\" in\n-'')\n+if test \"$merge_store\"\n+then\n \techo \"$head\" > \"$GIT_DIR/$merge_store\"\n-esac &&\n+fi &&\n \n # FETCH_HEAD is fed to git-resolve-script which will eventually be\n # passed to git-commit-tree as one of the parents.  Make sure we do\n\nCompilation finished at Sat Jul 16 09:37:07\n"},{"id":"6190","messageId":"Pine.LNX.4.58.0507161032410.19183@g5.osdl.org","threadId":"1233","inReplyTo":"7vek9yn1f5.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH-fix] fetch/pull: short-hand notation for remote repositories.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-16T17:33:30Z","receivedAt":"2005-07-16T17:33:30Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 16 Jul 2005, Junio C Hamano wrote:\n> \n> *** I see you have already merged my broken one; sorry.\n\nI already noticed the breakage, and fixed that a bit differently.\n\nFeel free to send an updated patch if you prefer your version after my \ncommits have percolated out..\n\n\t\tLinus\n"},{"id":"6193","messageId":"7vr7dyhc50.fsf@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"Pine.LNX.4.58.0507161032410.19183@g5.osdl.org","subject":"Re: [PATCH-fix] fetch/pull: short-hand notation for remote repositories.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T17:52:11Z","receivedAt":"2005-07-16T17:52:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> I already noticed the breakage, and fixed that a bit differently.\n>\n> Feel free to send an updated patch if you prefer your version after my \n> commits have percolated out..\n\nAs an old timer, I always prefer \"case\" over \"test\", so the\nversion in your tree is actually better to me.  Thanks for the\nfix.\n"},{"id":"6251","messageId":"7v1x5wt44t.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"Pine.LNX.4.58.0507161032410.19183@g5.osdl.org","subject":"[PATCH] git-clone-script: store where we cloned from in .git/branches/origin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-18T17:28:50Z","receivedAt":"2005-07-18T17:28:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A bit more usability enhancement related to the recent URL\nshort-hand support in .git/branches, while retaining Cogito\ncompatibility.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n git-clone-script |   41 +++++++++++++++++++++++------------------\n 1 files changed, 23 insertions(+), 18 deletions(-)\n\ncb70e0d83c336e0fc3485b6c823b948c07d15a12\ndiff --git a/git-clone-script b/git-clone-script\n--- a/git-clone-script\n+++ b/git-clone-script\n@@ -20,12 +20,12 @@ upload_pack=\n while\n \tcase \"$#,$1\" in\n \t0,*) break ;;\n-        *,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;\n+\t*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;\n \t*,-q|*,--quiet) quiet=-q ;;\n-\t1,-u|*,--upload-pack) usage ;;\n+\t1,-u|1,--upload-pack) usage ;;\n \t*,-u|*,--upload-pack)\n \t\tshift\n-\t\tupload_pack=\"--exec=$2\" ;;\n+\t\tupload_pack=\"--exec=$1\" ;;\n \t*,-*) usage ;;\n \t*) break ;;\n \tesac\n@@ -81,23 +81,28 @@ yes,yes)\n \t\tHEAD=HEAD\n \tfi\n \ttar Ccf \"$repo\" - refs $HEAD | tar Cxf \"$D/.git\" - || exit 1\n-\texit 0\n-\t;;\n-esac\n-\n-case \"$repo\" in\n-rsync://*)\n-\trsync $quiet -avz --ignore-existing \"$repo/objects/\" \"$D/.git/objects/\" &&\n-\trsync $quiet -avz --ignore-existing \"$repo/refs/\" \"$D/.git/refs/\"\n-\t;;\n-http://*)\n-\techo \"Somebody should add http fetch\" >&2\n-\texit 1\n \t;;\n *)\n-\tcd \"$D\" && case \"$upload_pack\" in\n-\t'') git-clone-pack $quiet \"$repo\" ;;\n-\t*) git-clone-pack $quiet \"$upload_pack\" \"$repo\" ;;\n+\tcase \"$repo\" in\n+\trsync://*)\n+\t\trsync $quiet -avz --ignore-existing \"$repo/objects/\" \"$D/.git/objects/\" &&\n+\t\trsync $quiet -avz --ignore-existing \"$repo/refs/\" \"$D/.git/refs/\"\n+\t\t;;\n+\thttp://*)\n+\t\techo \"Somebody should add http fetch\" >&2\n+\t\texit 1\n+\t\t;;\n+\t*)\n+\t\tcd \"$D\" && case \"$upload_pack\" in\n+\t\t'') git-clone-pack $quiet \"$repo\" ;;\n+\t\t*) git-clone-pack $quiet \"$upload_pack\" \"$repo\" ;;\n+\t\tesac\n+\t\t;;\n \tesac\n \t;;\n esac\n+\n+# Update origin.\n+mkdir -p \"$D/.git/branches/\" &&\n+rm -f \"$D/.git/branches/origin\" &&\n+echo \"$repo\" >\"$D/.git/branches/origin\"\n"},{"id":"6252","messageId":"7vvf38rpj3.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1233","inReplyTo":"Pine.LNX.4.58.0507161032410.19183@g5.osdl.org","subject":"[PATCH] tutorial: mention \"git clone\" records .git/branches/origin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-18T17:29:36Z","receivedAt":"2005-07-18T17:29:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Update the recommended workflow for individual developers.\nWhile they are tracking the origin, refs/heads/origin is updated\nby \"git fetch\", so there is no need to manually copy FETCH_HEAD\nto refs/heads/ anywhere.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/tutorial.txt |   48 ++++++++++++++++++++------------------------\n 1 files changed, 22 insertions(+), 26 deletions(-)\n\n6af33a52163dd15beaaf610f6b7506b900189770\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -1042,7 +1042,8 @@ A recommended work cycle for a \"subsyste\n on that project and has own \"public repository\" goes like this:\n \n  (1) Prepare your work repository, by \"git clone\" the public\n-     repository of the \"project lead\".\n+     repository of the \"project lead\".  The URL used for the\n+     initial cloning is stored in .git/branches/origin.\n \n  (2) Prepare a public repository accessible to others.\n \n@@ -1051,7 +1052,7 @@ on that project and has own \"public repo\n      currently not automated.\n \n  (4) Push into the public repository from your primary\n-     repository.  Run \"git repack\" (and possibly \"git\n+     repository.  Run \"git repack\", and possibly \"git\n      prune-packed\" if the transport used for pulling from your\n      repository supports packed repositories.\n \n@@ -1076,30 +1077,25 @@ A recommended work cycle for an \"individ\n not have a \"public\" repository is somewhat different.  It goes\n like this:\n \n- (1) Prepare your work repositories, by \"git clone\" the public\n-     repository of the \"project lead\" (or \"subsystem\n-     maintainer\", if you work on a subsystem).\n-\n- (2) Copy .git/refs/master to .git/refs/upstream.\n-\n- (3) Do your work there.  Make commits.\n-\n- (4) Run \"git fetch\" from the public repository of your upstream\n-     every once in a while.  This does only the first half of\n-     \"git pull\" but does not merge.  The head of the public\n-     repository is stored in .git/FETCH_HEAD.  Copy it in\n-     .git/refs/heads/upstream.\n-\n- (5) Use \"git cherry\" to see which ones of your patches were\n-     accepted, and/or use \"git rebase\" to port your unmerged\n-     changes forward to the updated upstream.\n-\n- (6) Use \"git format-patch upstream\" to prepare patches for\n-     e-mail submission to your upstream and send it out.\n-     Go back to step (3) and continue. \n-\n-[Side Note: I think Cogito calls this upstream \"origin\".\n- Somebody care to confirm or deny?  ]\n+ (1) Prepare your work repository, by \"git clone\" the public\n+     repository of the \"project lead\" (or a \"subsystem\n+     maintainer\", if you work on a subsystem).  The URL used for\n+     the initial cloning is stored in .git/branches/origin.\n+\n+ (2) Do your work there.  Make commits.\n+\n+ (3) Run \"git fetch origin\" from the public repository of your\n+     upstream every once in a while.  This does only the first\n+     half of \"git pull\" but does not merge.  The head of the\n+     public repository is stored in .git/refs/heads/origin.\n+\n+ (4) Use \"git cherry origin\" to see which ones of your patches\n+     were accepted, and/or use \"git rebase origin\" to port your\n+     unmerged changes forward to the updated upstream.\n+\n+ (5) Use \"git format-patch origin\" to prepare patches for e-mail\n+     submission to your upstream and send it out.  Go back to\n+     step (2) and continue.\n \n \n [ to be continued.. cvsimports ]\n"}]}