Commit Graph

9859 Commits

Author SHA1 Message Date
Junio C Hamano
d6b3e3a33f Merge 1.5.1.5 in
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-18 17:27:08 -07:00
Junio C Hamano
6b68342edc GIT v1.5.1.5
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-18 17:21:43 -07:00
Junio C Hamano
cecb98a9c3 Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint
* 'maint' of git://linux-nfs.org/~bfields/git:
  user-manual: reorganize public git repo discussion
  user-manual: listing commits reachable from some refs not others
  user-manual: introduce git
  user-manual: add a "counting commits" example
  user-manual: move howto/using-topic-branches into manual
  user-manual: move howto/make-dist.txt into user manual
  Documentation: remove howto's now incorporated into manual
  user-manual: move quick-start to an appendix
  glossary: expand and clarify some definitions, prune cross-references
  user-manual: revise birdseye-view chapter
  Add a birdview-on-the-source-code section to the user manual
2007-05-18 17:13:47 -07:00
Petr Baudis
7f79b0173d gitweb: Remove redundant $searchtype setup
Sorry, this was inadverently introduced by my grep search patch. It causes
annoying "redefined" warnings.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-18 17:12:36 -07:00
Petr Baudis
a5c2d26a04 Documentation: git-rev-list's "patterns"
git-rev-list(1) talks about patterns as values for the
--grep, --committed etc. parameters, without going into detail.
This patch mentions that these patterns are actually regexps.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-18 17:12:10 -07:00
Andy Parkins
760f0c62ef Fix crlf attribute handling to match documentation
gitattributes.txt says, of the crlf attribute:

 Set::
    Setting the `crlf` attribute on a path is meant to mark
    the path as a "text" file.  'core.autocrlf' conversion
    takes place without guessing the content type by
    inspection.

That is to say that the crlf attribute does not force the file to have
CRLF line endings, instead it removes the autocrlf guesswork and forces
the file to be treated as text.  Then, whatever line ending is defined
by the autocrlf setting is applied.

However, that is not what convert.c was doing.  The conversion to CRLF
was being skipped in crlf_to_worktree() when the following condition was
true:

 action == CRLF_GUESS && auto_crlf <= 0

That is to say conversion took place when not in guess mode (crlf attribute
not specified) or core.autocrlf set to true.  This was wrong.  It meant
that the crlf attribute being on for a given file _forced_ CRLF
conversion, when actually it should force the file to be treated as
text, and converted accordingly.  The real test should simply be

 auto_crlf <= 0

That is to say, if core.autocrlf is falsei (or input), conversion from
LF to CRLF is never done.  When core.autocrlf is true, conversion from
LF to CRLF is done only when in CRLF_GUESS (and the guess is "text"), or
CRLF_TEXT mode.

Similarly for crlf_to_worktree(), if core.autocrlf is false, no conversion
should _ever_ take place.  In reality it was only not taking place if
core.autocrlf was false _and_ the crlf attribute was unspecified.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-18 17:02:47 -07:00
René Scharfe
5e6cfc80e2 git-archive: convert archive entries like checkouts do
As noted by Johan Herland, git-archive is a kind of checkout and needs
to apply any checkout filters that might be configured.

This patch adds the convenience function convert_sha1_file which returns
a buffer containing the object's contents, after converting, if necessary
(i.e. it's a combination of read_sha1_file and convert_to_working_tree).
Direct calls to read_sha1_file in git-archive are then replaced by calls
to convert_sha1_file.

Since convert_sha1_file expects its path argument to be NUL-terminated --
a convention it inherits from convert_to_working_tree -- the patch also
changes the path handling in archive-tar.c to always NUL-terminate the
string.  It used to solely rely on the len field of struct strbuf before.

archive-zip.c already NUL-terminates the path and thus needs no such
change.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-18 16:36:45 -07:00
J. Bruce Fields
eda6944919 user-manual: reorganize public git repo discussion
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>
2007-05-17 23:23:08 -04:00
J. Bruce Fields
629d9f785f user-manual: listing commits reachable from some refs not others
This is just an amusing example raised by someone in irc.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:58:53 -04:00
J. Bruce Fields
99eaefdd32 user-manual: introduce git
Well, we should say at least something about what git is.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:58:53 -04:00
J. Bruce Fields
46acd3fa32 user-manual: add a "counting commits" example
This is partly just an excuse to mention --pretty= and rev-list.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:58:51 -04:00
J. Bruce Fields
9e2163ea45 user-manual: move howto/using-topic-branches into manual
Move howto/using-topic-branches into the user manual as an example for
the "sharing development" chapter.  While we're at it, remove some
discussion that's covered in earlier chapters, modernize somewhat (use
separate-heads setup, remotes, replace "whatchanged" by "log", etc.),
and replace syntax we'd need to explain by syntax we've already covered
(e.g. old..new instead of new ^old).

The result may not really describe what Tony Luck does any more.... Hope
that's not annoying.

Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:20:10 -04:00
J. Bruce Fields
82c8bf28f8 user-manual: move howto/make-dist.txt into user manual
There seems to be a perception that the howto's are bit-rotting a
little.  The manual might be a more visible location for some of them,
and make-dist.txt seems like a good candidate to include as an example
in the manual.

For now, incorporate much of it verbatim.  Later we may want to update
the example a bit.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:08:02 -04:00
J. Bruce Fields
4db75b70d1 Documentation: remove howto's now incorporated into manual
These two howto's have both been copied into the manual.  I'd rather not
maintain both versions if possible, and I think the user-manual will be
more visible than the howto directory.  (Though I wouldn't mind some
duplication if people really like having them here.)

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:05:46 -04:00
J. Bruce Fields
2624d9a5aa user-manual: move quick-start to an appendix
The quick start interrupts the flow of the manual a bit.  Move it to
"appendix A" but add a reference to it in the preface.  Also rename the
todo chapter to "appendix B", and revise the preface a little.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:05:46 -04:00
J. Bruce Fields
343cad9217 glossary: expand and clarify some definitions, prune cross-references
Revise and expand some of the definitions in the glossary, based in part
on a recent thread started by a user looking for help with some of the
jargon.  I've borrowed some of the language from Linus's email on that
thread.  (I'm assuming standing permission to plagiarize Linus's
email....)

Also start making a few changes to mitigate the appearance of
"circularity" mentioned in that thread:
	- feel free to use somewhat longer definitions and to explain
	  some things more than once instead of relying purely on
	  cross-references
	- don't use cross-references when they're redundant: eliminate
	  self-references and repeated references to the same entry.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:03:59 -04:00
J. Bruce Fields
a5fc33b493 user-manual: revise birdseye-view chapter
Some revisions suggested by Junio along with some minor style fixes and
one compile fix (asterisks need escaping).

Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-05-17 21:02:35 -04:00
Petr Baudis
4229aa5141 gitweb: Allow arbitrary strings to be dug with pickaxe
Currently, there are rather draconian restrictions on the strings accepted
by the pickaxe search, which degrades its usefulness for digging in code
significantly. This patch remedies mentioned limitation.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-17 17:37:31 -07:00
Petr Baudis
e773855372 gitweb: Add support for grep searches
The 'grep' type of search greps the currently selected tree for given
regexp and shows the results in a fancy table with links into blob view.
The number of shown matches is limited to 1000 and the whole feature
can be turned off (grepping linux-2.6.git already makes repo.or.cz a bit
unhappy).

This second revision makes it in documentation explicit that grep accepts
regexps, and makes grep accept extended regexps instead of basic regexps.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-17 17:37:31 -07:00
Petr Baudis
d77b5673e9 gitweb: Normalize searchbar font size
Currently, searchbar font was as big as the page heading font, because
font-size was made relative - but to the parent element, which was for some
reason indeed page_header. Since that seems to be illogical to me, I just
moved the div.search outside of div.page_header. I'm no CSS/DOM expert but
no adverse effects were observed by me.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-17 17:37:30 -07:00
Junio C Hamano
8299886619 Merge branch 'maint'
* maint:
  Document core.excludesfile for git-add
  git-send-email: allow leading white space on mutt aliases
2007-05-17 17:36:57 -07:00
Michael Hendricks
164b19893a Document core.excludesfile for git-add
During the discussion of core.excludesfile in the user-manual, I realized
that the configuration wasn't mentioned in the man pages.

Signed-off-by: Michael Hendricks <michael@ndrix.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-17 17:36:38 -07:00
Jakub Narebski
5f85505265 gitweb: Fix error in git_patchset_body for deletion in merge commit
Checking if $diffinfo->{'status'} is equal 'D' is no longer the way to
check if the file was deleted in result.  For merge commits
$diffinfo->{'status'} is reference to array of statuses for each
parent.  Use the fact that $diffinfo->{'to_id'} is all zeros as sign
that file was deleted in result.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-17 17:35:33 -07:00
Junio C Hamano
e986e26a86 Merge branch 'master' of git://repo.or.cz/git-gui
* 'master' of git://repo.or.cz/git-gui:
  git-gui: Gracefully handle bad TCL_PATH at compile time
2007-05-17 16:52:45 -07:00
Shawn O. Pearce
b9e7efb8b5 git-gui: Gracefully handle bad TCL_PATH at compile time
Petr Baudis pointed out the main git.git repository's Makefile dies
now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not
set to a working tclsh program path.  This breaks people who may have
a working build configuration today and suddenly upgrade to the latest
git release.

The tclIndex is required for git-gui to load its associated lib files,
but using the Tcl auto_load procedure to source only the files we need
is a performance optimization.  We can emulate the auto_load by just
source'ing every file in that directory, assuming we source class.tcl
first to initialize our crude class system.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-17 18:10:26 -04:00
Michael Hendricks
504ceab6d2 git-send-email: allow leading white space on mutt aliases
mutt version 1.5.14 (perhaps earlier versions too) permits alias files to have
white space before the 'alias' keyword.

Signed-off-by: Michael Hendricks <michael@ndrix.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-16 22:33:04 -07:00
Junio C Hamano
2eb54efc6c gitweb: fix another use of undefined value
Pasky and Jakub competed fixing these and in the confusion this ended up
not being covered.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-16 21:04:16 -07:00
Johannes Schindelin
126640afbc Add a birdview-on-the-source-code section to the user manual
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.

J. Bruce Fields suggested that my reply should be included in the
user manual, and there was nothing of an outcry, so here it is,
not 2 months later.

It includes modifications as suggested by J. Bruce Fields, Karl
Hasselström and Daniel Barkalow.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2007-05-16 20:36:13 -04:00
Jakub Narebski
d26c4264e5 gitweb: Empty patch for merge means trivial merge, not no differences
Earlier commit 4280cde95f made gitweb
show "No differences found" message for empty diff, for the HTML
output. But for merge commits, either -c format we use or --cc format,
empty diff doesn't mean no differences, but trivial merge.

Show "Trivial merge" message instead of "No differences found" for
merges.

While at it reword conditional in the code for easier reading.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-16 16:13:42 -07:00
Junio C Hamano
fdcb769916 Merge branch 'maint'
* maint:
  format-patch: add MIME-Version header when we add content-type.
  Fixed link in user-manual
  import-tars: Use the "Link indicator" to identify directories
  git name-rev writes beyond the end of malloc() with large generations
  Documentation/branch: fix small typo in -D example
2007-05-16 12:43:05 -07:00
Jakub Narebski
7e431ef9ab gitweb: Separate search regexp from search text
Separate search text, which is saved in $searchtext global variable,
and is used in links, as default value for the textfield in search
form, and for pickaxe search, from search regexp, which is saved in
$search_regexp global variable, and is used as parameter to --grep,
--committer or --author options to git-rev-list, and for searching
commit body in gitweb.  For now $search_regexp is unconditionallt
equal to quotemeta($searchtext), meaning that we always search for
fixed string.

This fixes bug where 'next page' links for 'search' view didn't work
for searchtext containing quotable characters, like `@'.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-16 12:40:06 -07:00
Jakub Narebski
b211c320eb gitweb: Do not use absolute font sizes
David Kågedal proposed that gitweb should explicitely request
being somewhat smaller than normal, because it has good use for
long lines. However gitweb presents a table with several
columns, so having wider line is OK for it. Therefore explicit
'font-size: small' would make sense.  Apparently many people on
the list seem to agree with him.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-16 12:40:06 -07:00
Jeff King
0ab564be6e format-patch: add MIME-Version header when we add content-type.
When we add Content-Type: header, we should also add
MIME-Version: header as well.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-16 12:37:25 -07:00
Steffen Prohaska
61d7256431 Fixed link in user-manual
link to git-mergetool was broken.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-16 12:32:29 -07:00
Junio C Hamano
df9f91f873 Merge branch 'maint' of git://repo.or.cz/git/fastimport into maint
* 'maint' of git://repo.or.cz/git/fastimport:
  import-tars: Use the "Link indicator" to identify directories
2007-05-16 12:13:55 -07:00
Johannes Schindelin
df8cfac815 import-tars: Use the "Link indicator" to identify directories
Earlier, we used the mode to determine if a name was associated with
a directory. This fails, since some tar programs do not set the mode
correctly. However, the link indicator _has_ to be set correctly.

Noticed by Chris Riddoch.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-16 14:54:22 -04:00
Johan Herland
8a912bcb25 Ensure return value from xread() is always stored into an ssize_t
This patch fixes all calls to xread() where the return value is not
stored into an ssize_t. The patch should not have any effect whatsoever,
other than putting better/more appropriate type names on variables.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-15 21:16:03 -07:00
Johan Herland
2924415f4f Fix signedness on return value from xread()
The return value from xread() is ssize_t.
Paolo Teti <paolo.teti@gmail.com> pointed out that in this case, the
signed return value was assigned to an unsigned type (size_t). This patch
fixes that.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-15 21:15:54 -07:00
Andy Whitcroft
cf606e3ddd git name-rev writes beyond the end of malloc() with large generations
When using git name-rev on my kernel tree I triggered a malloc()
corruption warning from glibc.

apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin
*** glibc detected *** malloc(): memory corruption: 0x0bff8950 ***
Aborted

This comes from name_rev() which is building the name of the revision
in a malloc'd string, which it sprintf's into:

	char *new_name = xmalloc(len + 8);
	[...]
		sprintf(new_name, "%.*s~%d^%d", len, tip_name,
				generation, parent_number);

This allocation is only sufficient if the generation number is
less than 5 digits, in my case generation was 13432.  In reality
parent_number can be up to 16 so that also can require two digits,
reducing us to 3 digits before we are at risk of blowing this
allocation.

This patch introduces a decimal_length() which approximates the
number of digits a type may hold, it produces the following:

Type                 Longest Value          Len  Est
----                 -------------          ---  ---
unsigned char        256                      3    4
unsigned short       65536                    5    6
unsigned long        4294967296              10   11
unsigned long long   18446744073709551616    20   21
char                 -128                     4    4
short                -32768                   6    6
long                 -2147483648             11   11
long long            -9223372036854775808    20   21

This is then used to size the new_name.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-15 18:14:42 -07:00
Quy Tonthat
045fe3ccda Documentation/branch: fix small typo in -D example
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 20:17:00 -07:00
Andy Parkins
af9b54bb2c Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
$Id$ is present already in SVN and CVS; it would mean that people
converting their existing repositories won't have to make any changes to
the source files should they want to make use of the ident attribute.

Given that it's a feature that's meant to calm those very people, it
seems obtuse to make them edit every file just to make use of it.

I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
monotone has $Id$ on its wishlist.  I can't think of a good reason not
to stick with the de-facto standard and call ours $Id$ instead of
$ident$.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 19:03:32 -07:00
Junio C Hamano
3545193735 Merge branch 'maint'
* maint:
  Prepare for 1.5.1.5 Release Notes
  gitweb: Add a few comments about %feature hash
  git-am: Clean up the asciidoc documentation
  Documentation: format-patch has no --mbox option
  builtin-log.c: Fix typo in comment
  Fix git-clone buglet for remote case.
2007-05-14 18:50:01 -07:00
Junio C Hamano
52e7b744d3 Prepare for 1.5.1.5 Release Notes
Hopefully we will have 1.5.2 soonish, to contain all of these,
but we should summarize what we have done regardless.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 17:51:12 -07:00
Jakub Narebski
b4b20b2164 gitweb: Add a few comments about %feature hash
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 17:26:46 -07:00
Frank Lichtenheld
870e0d61d3 git-am: Clean up the asciidoc documentation
Add --keep to synopsis.

The synopsys used a mix of tabs and spaces, unify to use only
spaces.

Shuffle options around in synopsys and description for grouping
them logically.

Add more gitlink references to other commands.

Various grammatical fixes and improvements.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 17:25:02 -07:00
Frank Lichtenheld
7b1885d1e7 Documentation: format-patch has no --mbox option
git-applymbox and git-mailinfo refer to a --mbox option of
git-format-patch when talking about their -k options. But there
is no such option.  What -k does to the former two commands is
to keep the Subject: lines unmunged, meant to be used on output
generated with format-patch -k.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 17:23:52 -07:00
Frank Lichtenheld
2dc189a353 builtin-log.c: Fix typo in comment
s/fmt-patch/format-patch/

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 16:52:02 -07:00
Junio C Hamano
223fa32784 Fix git-clone buglet for remote case.
c2f599e09f introduced a buglet while
cloning from a remote URL; we forgot to squelch the unnecessary
error message when we try to cd to the given "remote" name,
in order to see if it is a local directory.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-14 14:24:02 -07:00
Frank Lichtenheld
460c6996e2 cvsserver: Don't send mixed messages to clients
After we send I HATE YOU we should probably exit and not happily
continue with I LOVE YOU and further communication.

Most clients will probably just exit and ignore everything we
send after the I HATE YOU and it is not a security problem
either because we don't really care about the user name anyway.

But it is still the right thing to do.

[jc: with a minor fixup to its exit code...]

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: "Martin Langhoff" <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-13 23:57:27 -07:00
Jeff King
dfaa61bd52 Documentation/git-add: clarify -u with path limiting
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-13 18:45:15 -07:00