Please pull from the maint branch at

	git://linux-nfs.org/~bfields/git.git maint

This is mainly revisions of the patches posted a few days ago, which
were uncontraversial, so I won't resend them.  (They did need more
proofreading than usual, though--thanks to everyone who helped!)

One final patch wasn't included before, so I'll follow up with that.

--b.

 Documentation/glossary.txt                       |  228 +++--
 Documentation/howto/dangling-objects.txt         |  109 --
 Documentation/howto/isolate-bugs-with-bisect.txt |   65 --
 Documentation/howto/make-dist.txt                |   52 -
 Documentation/howto/using-topic-branches.txt     |  296 ------
 Documentation/user-manual.txt                    | 1192 +++++++++++++++++-----
 6 files changed, 1046 insertions(+), 896 deletions(-)
-

[ message continues ]

Helping a couple people set up public repos recently, I wanted to point
them at this piece of the user manual, but found it wasn't as helpful as
it could be:

	- It starts with a big explanation of why you'd want a public
	  repository, not necessary in their case since they already knew
	  why they wanted that.  So, separate that out.
	- It skimps on some of the git-daemon details, and puts the http
	  export information first.  Fix that.

Also group all the public repo subsections into a single section, and do
some miscellaneous related editing.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
 Documentation/user-manual.txt |   90 +++++++++++++++++++++++------------------
 1 files changed, 50 insertions(+), 40 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 735fea1..f4843f4 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1674,31 +1674,30 @@ The final result will be a series of commits, one for each patch in
 the original mailbox, with authorship and commit log message each
 taken from the message containing each patch.
 
-[[setting-up-a-public-repository]]
-Setting up a public repository
-------------------------------
+[[public-repositories]]
+Public git repositories
+-----------------------
 
-Another way to submit changes to a project is to simply tell the
-maintainer of that project to pull from your repository, exactly as
-you did in the section "<<getting-updates-with-git-pull, Getting
-updates with git pull>>".
+Another way to submit changes to a project is to tell the maintainer of
+that project to pull the changes from your repository using git-pull[1].
+In the section "<<getting-updates-with-git-pull, Getting updates with
+git pull>>" we described this as a way to get updates from the "main"
+repository, but it works just as well in the other direction.
 
-If you and maintainer both have accounts on the same machine, then
-then you can just pull changes from ...
[ message continues ]

Hi,


  BTW, there is this nice git-request-pull tool which will prepare this
mail for you and additionally include the list of commits included in
that repository, which is somewhat more friendly to the readers (I
myself wondered). ;-)

  Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett
-

[ message continues ]

OK!  I'll start including the shortlog.  Appended, if anyone's still
curious about this one.--b.

J. Bruce Fields (10):
      user-manual: revise birdseye-view chapter
      glossary: expand and clarify some definitions, prune cross-references
      user-manual: move quick-start to an appendix
      Documentation: remove howto's now incorporated into manual
      user-manual: move howto/make-dist.txt into user manual
      user-manual: move howto/using-topic-branches into manual
      user-manual: add a "counting commits" example
      user-manual: introduce git
      user-manual: listing commits reachable from some refs not others
      user-manual: reorganize public git repo discussion

Johannes Schindelin (1):
      Add a birdview-on-the-source-code section to the user manual
-

[ message continues ]

request-pull also does nice things like include the fetch URL, and
the branch name, and in a nice format that makes it very easy to
copy and paste into a "git pull" (or "git fetch") command line[*1*],
so its slightly more than just the shortlog.  ;-)


[*1*] By popular demand from Git's creator.

-- 
Shawn.
-

[ message continues ]

I know, but that's not hard to do by hand.  Which doesn't, of course,
mean I won't screw it up....

But, actually, I tried it just now and it only gave the url:

	The following changes since commit 164b19893ab5bc66b531a26480149a0dff082969:
	  Michael Hendricks (1):
		Document core.excludesfile for git-add

	are found in the git repository at:

		git://linux-nfs.org/~bfields/git.git

How's it supposed to figure out the branch name?  (And I'm not sure
about that "change since commit..." stuff--that seems like slight
overkill.)

--b.
-

[ message continues ]

It connects to the remote URL, lists the refs found there, and
finds any that has the commit you passed in as the 3rd argument
(defaults to HEAD).  If none match it prints ..BRANCH.NOT.VERIFIED..
as the branch name, to signal no branch points at the given commit,
which means it cannot be (easily) pulled.

Not getting that means you have too old of a Git to have my branch
improvements.  It was in ff06c743dc, which is in master and hence

Yea, it can be a little overkill sometimes.  But the maintainer
knows where you started from.  If that commit is horribly old he
might wonder what is going on.  ;-)

-- 
Shawn.
-

[ message continues ]

Is that really helpful in practice?  Well, what would I know.

--b.
-

[ message continues ]