Fixes since v1.5.4.4
--------------------
+ * "git fetch there" when the URL information came from the Cogito style
+ branches/there file did not update refs/heads/there (regression in
+ 1.5.4).
+
+ * Bogus refspec configuration such as "remote.there.fetch = =" were not
+ detected as errors (regressionin 1.5.4).
+
* You couldn't specify a custom editor whose path contains a whitespace
via GIT_EDITOR (and core.editor).
* "git rebase -m" triggered pre-commit verification, which made
"rebase --continue" impossible.
+As usual, it also comes with many documentation fixes and clarifications.
+
--
exec >/var/tmp/1
echo O=$(git describe maint)
-O=v1.5.4.4-25-ga6f7728
+O=v1.5.4.4-32-gb88605f
git shortlog --no-merges $O..maint
* "git-rebase --abort" did not go back to the right location if
"git-reset" was run during the "git-rebase" session.
+ * "git imap-send" without setting imap.host did not error out but
+ segfaulted.
+
---
exec >/var/tmp/1
-O=v1.5.5-rc1
+O=v1.5.5-rc1-21-g319a36a
echo O=`git describe refs/heads/master`
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
path in question, and its parent directories (the further the\r
directory that contains <tt>.gitattributes</tt> is from the path in\r
question, the lower its precedence).</p>\r
+<p>If you wish to affect only a single repository (i.e., to assign\r
+attributes to files that are particular to one user's workflow), then\r
+attributes should be placed in the <tt>$GIT_DIR/info/attributes</tt> file.\r
+Attributes which should be version-controlled and distributed to other\r
+repositories (i.e., attributes of interest to all users) should go into\r
+<tt>.gitattributes</tt> files.</p>\r
<p>Sometimes you would need to override an setting of an attribute\r
for a path to <tt>unspecified</tt> state. This can be done by listing\r
the name of the attribute prefixed with an exclamation point <tt>!</tt>.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 17-Feb-2008 03:50:09 UTC\r
+Last updated 27-Mar-2008 23:49:28 UTC\r
</div>\r
</div>\r
</body>\r
directory that contains `.gitattributes` is from the path in
question, the lower its precedence).
+If you wish to affect only a single repository (i.e., to assign
+attributes to files that are particular to one user's workflow), then
+attributes should be placed in the `$GIT_DIR/info/attributes` file.
+Attributes which should be version-controlled and distributed to other
+repositories (i.e., attributes of interest to all users) should go into
+`.gitattributes` files.
+
Sometimes you would need to override an setting of an attribute
for a path to `unspecified` state. This can be done by listing
the name of the attribute prefixed with an exclamation point `!`.
</p>\r
</li>\r
</ul>\r
+<p>Which file to place a pattern in depends on how the pattern is meant to\r
+be used. Patterns which should be version-controlled and distributed to\r
+other repositories via clone (i.e., files that all developers will want\r
+to ignore) should go into a <tt>.gitignore</tt> file. Patterns which are\r
+specific to a particular repository but which do not need to be shared\r
+with other related repositories (e.g., auxiliary files that live inside\r
+the repository but are specific to one user's workflow) should go into\r
+the <tt>$GIT_DIR/info/exclude</tt> file. Patterns which a user wants git to\r
+ignore in all situations (e.g., backup or temporary files generated by\r
+the user's editor of choice) generally go into a file specified by\r
+<tt>core.excludesfile</tt> in the user's <tt>~/.gitconfig</tt>.</p>\r
<p>The underlying git plumbing tools, such as\r
<a href="git-ls-files.html">git-ls-files(1)</a> and <a href="git-read-tree.html">git-read-tree(1)</a>, read\r
<tt>gitignore</tt> patterns specified by command-line options, or from\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 17-Feb-2008 03:50:09 UTC\r
+Last updated 27-Mar-2008 23:49:28 UTC\r
</div>\r
</div>\r
</body>\r
* Patterns read from the file specified by the configuration
variable 'core.excludesfile'.
+Which file to place a pattern in depends on how the pattern is meant to
+be used. Patterns which should be version-controlled and distributed to
+other repositories via clone (i.e., files that all developers will want
+to ignore) should go into a `.gitignore` file. Patterns which are
+specific to a particular repository but which do not need to be shared
+with other related repositories (e.g., auxiliary files that live inside
+the repository but are specific to one user's workflow) should go into
+the `$GIT_DIR/info/exclude` file. Patterns which a user wants git to
+ignore in all situations (e.g., backup or temporary files generated by
+the user's editor of choice) generally go into a file specified by
+`core.excludesfile` in the user's `~/.gitconfig`.
+
The underlying git plumbing tools, such as
linkgit:git-ls-files[1] and linkgit:git-read-tree[1], read
`gitignore` patterns specified by command-line options, or from