From: Junio C Hamano <junkio@cox.net>
Date: Sun, 11 Mar 2007 06:07:26 +0000 (-0800)
Subject: Merge branch 'maint'
X-Git-Tag: v1.5.1-rc1~67
X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/ed287ab7fa71528e8de288988d1662eebae64002?ds=inline;hp=-c

Merge branch 'maint'

* maint:
git.el: Retrieve commit log information from .dotest directory.
git.el: Avoid appending a signoff line that is already present.
setup_git_directory_gently: fix off-by-one error
user-manual: install user manual stylesheet with other web documents
user-manual: fix rendering of history diagrams
user-manual: fix missing colon in git-show example
user-manual: fix inconsistent use of pull and merge
user-manual: fix inconsistent example
glossary: fix overoptimistic automatic linking of defined terms
Documentation: s/seperator/separator/
Adjust reflog filemode in shared repository
---

ed287ab7fa71528e8de288988d1662eebae64002
diff --combined Documentation/git-fast-import.txt
index 7e3d2b1a96,a7d255d39f..eaba6fd4c1
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@@ -62,18 -62,7 +62,18 @@@ OPTION
  	Dumps the internal marks table to <file> when complete.
  	Marks are written one per line as `:markid SHA-1`.
  	Frontends can use this file to validate imports after they
 -	have been completed.
 +	have been completed, or to save the marks table across
 +	incremental runs.  As <file> is only opened and truncated
 +	at checkpoint (or completion) the same path can also be
 +	safely given to \--import-marks.
 +
 +--import-marks=<file>::
 +	Before processing any input, load the marks specified in
 +	<file>.  The input file must exist, must be readable, and
 +	must use the same format as produced by \--export-marks.
 +	Multiple options may be supplied to import more than one
 +	set of marks.  If a mark is defined to different values,
 +	the last file wins.
  
  --export-pack-edges=<file>::
  	After creating a packfile, print a line of data to
@@@ -462,7 -451,7 +462,7 @@@ in octal.  Git only supports the follow
  In both formats `<path>` is the complete path of the file to be added
  (if not already existing) or modified (if already existing).
  
- A `<path>` string must use UNIX-style directory seperators (forward
+ A `<path>` string must use UNIX-style directory separators (forward
  slash `/`), may contain any byte other than `LF`, and must not
  start with double quote (`"`).
  
@@@ -472,8 -461,8 +472,8 @@@ quoting should be used, e.g. `"path/wit
  The value of `<path>` must be in canoncial form. That is it must not:
  
  * contain an empty directory component (e.g. `foo//bar` is invalid),
- * end with a directory seperator (e.g. `foo/` is invalid),
- * start with a directory seperator (e.g. `/foo` is invalid),
+ * end with a directory separator (e.g. `foo/` is invalid),
+ * start with a directory separator (e.g. `/foo` is invalid),
  * contain the special component `.` or `..` (e.g. `foo/./bar` and
    `foo/../bar` are invalid).
  
diff --combined Documentation/user-manual.txt
index ffd673ec33,0919574fb4..d7b227e647
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@@ -437,11 -437,14 +437,14 @@@ We will sometimes represent git histor
  below.  Commits are shown as "o", and the links between them with
  lines drawn with - / and \.  Time goes left to right:
  
+ 
+ ................................................
           o--o--o <-- Branch A
          /
   o--o--o <-- master
          \
           o--o--o <-- Branch B
+ ................................................
  
  If we need to talk about a particular commit, the character "o" may
  be replaced with another letter or number.
@@@ -601,8 -604,8 +604,8 @@@ a new stanza
  $ cat .git/config
  ...
  [remote "linux-nfs"]
-         url = git://linux-nfs.org/~bfields/git.git
- 	fetch = +refs/heads/*:refs/remotes/linux-nfs-read/*
+ 	url = git://linux-nfs.org/pub/nfs-2.6.git
+ 	fetch = +refs/heads/*:refs/remotes/linux-nfs/*
  ...
  -------------------------------------------------
  
@@@ -1133,17 -1136,9 +1136,9 @@@ modified in two different ways in the r
  branch--then you are warned; the output may look something like this:
  
  -------------------------------------------------
- $ git pull . next
- Trying really trivial in-index merge...
- fatal: Merge requires file-level merging
- Nope.
- Merging HEAD with 77976da35a11db4580b80ae27e8d65caf5208086
- Merging:
- 15e2162 world
- 77976da goodbye
- found 1 common ancestor(s):
- d122ed4 initial
- Auto-merging file.txt
+ $ git merge next
+  100% (4/4) done
+ Auto-merged file.txt
  CONFLICT (content): Merge conflict in file.txt
  Automatic merge failed; fix conflicts and then commit the result.
  -------------------------------------------------
@@@ -1439,7 -1434,7 +1434,7 @@@ modifying the working directory, you ca
  gitlink:git-show[1]:
  
  -------------------------------------------------
- $ git show HEAD^ path/to/file
+ $ git show HEAD^:path/to/file
  -------------------------------------------------
  
  which will display the given version of the file.
@@@ -1936,25 -1931,29 +1931,29 @@@ $ git commi
  You have performed no merges into mywork, so it is just a simple linear
  sequence of patches on top of "origin":
  
- 
+ ................................................
   o--o--o <-- origin
          \
           o--o--o <-- mywork
+ ................................................
  
  Some more interesting work has been done in the upstream project, and
  "origin" has advanced:
  
+ ................................................
   o--o--O--o--o--o <-- origin
          \
           a--b--c <-- mywork
+ ................................................
  
  At this point, you could use "pull" to merge your changes back in;
  the result would create a new merge commit, like this:
  
- 
+ ................................................
   o--o--O--o--o--o <-- origin
          \        \
           a--b--c--m <-- mywork
+ ................................................
   
  However, if you prefer to keep the history in mywork a simple series of
  commits without any merges, you may instead choose to use
@@@ -1971,9 -1970,11 +1970,11 @@@ point at the latest version of origin, 
  patches to the new mywork.  The result will look like:
  
  
+ ................................................
   o--o--O--o--o--o <-- origin
  		 \
  		  a'--b'--c' <-- mywork
+ ................................................
  
  In the process, it may discover conflicts.  In that case it will stop
  and allow you to fix the conflicts; after fixing conflicts, use "git
@@@ -2081,24 -2082,30 +2082,30 @@@ The primary problem with rewriting the 
  with merging.  Suppose somebody fetches your branch and merges it into
  their branch, with a result something like this:
  
+ ................................................
   o--o--O--o--o--o <-- origin
          \        \
           t--t--t--m <-- their branch:
+ ................................................
  
  Then suppose you modify the last three commits:
  
+ ................................................
  	 o--o--o <-- new head of origin
  	/
   o--o--O--o--o--o <-- old head of origin
+ ................................................
  
  If we examined all this history together in one repository, it will
  look like:
  
+ ................................................
  	 o--o--o <-- new head of origin
  	/
   o--o--O--o--o--o <-- old head of origin
          \        \
           t--t--t--m <-- their branch:
+ ................................................
  
  Git has no way of knowing that the new head is an updated version of
  the old head; it treats this situation exactly the same as it would if
@@@ -2159,9 -2166,11 +2166,11 @@@ commit.  Git calls this process a "fas
  
  A fast forward looks something like this:
  
+ ................................................
   o--o--o--o <-- old head of the branch
             \
              o--o--o <-- new head of the branch
+ ................................................
  
  
  In some cases it is possible that the new head will *not* actually be
@@@ -2169,11 -2178,11 +2178,11 @@@ a descendant of the old head.  For exam
  realized she made a serious mistake, and decided to backtrack,
  resulting in a situation like:
  
+ ................................................
   o--o--o--o--a--b <-- old head of the branch
             \
              o--o--o <-- new head of the branch
- 
- 
+ ................................................
  
  In this case, "git fetch" will fail, and print out a warning.
  
@@@ -2861,7 -2870,7 +2870,7 @@@ stages to temporary files and calls a "
  $ git-merge-index git-merge-one-file hello.c
  -------------------------------------------------
  
 -and that is what higher level `git resolve` is implemented with.
 +and that is what higher level `git merge -s resolve` is implemented with.
  
  How git stores objects efficiently: pack files
  ----------------------------------------------
diff --combined refs.c
index 76c08d0360,131e870149..9f1fb68d04
--- a/refs.c
+++ b/refs.c
@@@ -828,8 -828,8 +828,8 @@@ int rename_ref(const char *oldref, cons
  		goto rollback;
  	}
  
 -	if (!strncmp(oldref, "refs/heads/", 11) &&
 -			!strncmp(newref, "refs/heads/", 11)) {
 +	if (!prefixcmp(oldref, "refs/heads/") &&
 +			!prefixcmp(newref, "refs/heads/")) {
  		char oldsection[1024], newsection[1024];
  
  		snprintf(oldsection, 1024, "branch.%s", oldref + 11);
@@@ -894,8 -894,8 +894,8 @@@ static int log_ref_write(const char *re
  	log_file = git_path("logs/%s", ref_name);
  
  	if (log_all_ref_updates &&
 -	    (!strncmp(ref_name, "refs/heads/", 11) ||
 -	     !strncmp(ref_name, "refs/remotes/", 13) ||
 +	    (!prefixcmp(ref_name, "refs/heads/") ||
 +	     !prefixcmp(ref_name, "refs/remotes/") ||
  	     !strcmp(ref_name, "HEAD"))) {
  		if (safe_create_leading_directories(log_file) < 0)
  			return error("unable to create directory for %s",
@@@ -921,6 -921,8 +921,8 @@@
  				     log_file, strerror(errno));
  	}
  
+ 	adjust_shared_perm(log_file);
+ 
  	msglen = 0;
  	if (msg) {
  		/* clean up the message and make sure it is a single line */
@@@ -1075,7 -1077,6 +1077,7 @@@ int read_ref_at(const char *ref, unsign
  	unsigned long date;
  	unsigned char logged_sha1[20];
  	void *log_mapped;
 +	size_t mapsz;
  
  	logfile = git_path("logs/%s", ref);
  	logfd = open(logfile, O_RDONLY, 0);
@@@ -1084,8 -1085,7 +1086,8 @@@
  	fstat(logfd, &st);
  	if (!st.st_size)
  		die("Log %s is empty.", logfile);
 -	log_mapped = xmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, logfd, 0);
 +	mapsz = xsize_t(st.st_size);
 +	log_mapped = xmmap(NULL, mapsz, PROT_READ, MAP_PRIVATE, logfd, 0);
  	logdata = log_mapped;
  	close(logfd);
  
@@@ -1138,7 -1138,7 +1140,7 @@@
  						logfile, show_rfc2822_date(date, tz));
  				}
  			}
 -			munmap(log_mapped, st.st_size);
 +			munmap(log_mapped, mapsz);
  			return 0;
  		}
  		lastrec = rec;
@@@ -1157,7 -1157,7 +1159,7 @@@
  		die("Log %s is corrupt.", logfile);
  	if (msg)
  		*msg = ref_msg(logdata, logend);
 -	munmap(log_mapped, st.st_size);
 +	munmap(log_mapped, mapsz);
  
  	if (cutoff_time)
  		*cutoff_time = date;
diff --combined setup.c
index dda67d268d,76e5e693cc..a45ea8309a
--- a/setup.c
+++ b/setup.c
@@@ -216,7 -216,7 +216,7 @@@ const char *setup_git_directory_gently(
  		die("Not a git repository: '%s'", gitdirenv);
  	}
  
- 	if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
+ 	if (!getcwd(cwd, sizeof(cwd)-1) || cwd[0] != '/')
  		die("Unable to read current working directory");
  
  	offset = len = strlen(cwd);
@@@ -251,7 -251,7 +251,7 @@@
  	offset++;
  	cwd[len++] = '/';
  	cwd[len] = 0;
 -	inside_git_dir = !strncmp(cwd + offset, ".git/", 5);
 +	inside_git_dir = !prefixcmp(cwd + offset, ".git/");
  	return cwd + offset;
  }