Merge branch 'js/portable'

* js/portable: Support Irix Optionally support old diffs Fix cpio call SubmittingPatches: note on whitespaces Add a README for gitview Add contrib/README. git-tag: -l to list tags (usability).
2006-02-17 17:34:51 -08:00 · 2006-02-17 17:34:51 -08:00 · 9b1320a99e
commit 9b1320a99e
parent 0f4aa3993d 289c4b36e3
8 changed files with 148 additions and 14 deletions
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@ -4,8 +4,8 @@ it for the core GIT to make sure people understand what they are
 doing when they write "Signed-off-by" line.

 But the patch submission requirements are a lot more relaxed
-here, because the core GIT is thousand times smaller ;-).  So
-here is only the relevant bits.
+here on the technical/contents front, because the core GIT is
+thousand times smaller ;-).  So here is only the relevant bits.


 (1) Make separate commits for logically separate changes.
@ -18,13 +18,19 @@ repository.  It is a good discipline.

 Describe the technical detail of the change(s).

-If your description starts to get long, that's a sign that you
+If your description starts to get too long, that's a sign that you
 probably need to split up your commit to finer grained pieces.

+Oh, another thing.  I am picky about whitespaces.  Make sure your
+changes do not trigger errors with the sample pre-commit hook shipped
+in templates/hooks--pre-commit.

-(2) Generate your patch using git/cogito out of your commits.

-git diff tools generate unidiff which is the preferred format.
+(2) Generate your patch using git tools out of your commits.
+
+git based diff tools (git, Cogito, and StGIT included) generate
+unidiff which is the preferred format.
+
 You do not have to be afraid to use -M option to "git diff" or
 "git format-patch", if your patch involves file renames.  The
 receiving end can handle them just fine.
@ -33,20 +39,22 @@ Please make sure your patch does not include any extra files
 which do not belong in a patch submission.  Make sure to review
 your patch after generating it, to ensure accuracy.  Before
 sending out, please make sure it cleanly applies to the "master"
-branch head.
+branch head.  If you are preparing a work based on "next" branch,
+that is fine, but please mark it as such.


 (3) Sending your patches.

-People on the git mailing list needs to be able to read and
+People on the git mailing list need to be able to read and
 comment on the changes you are submitting.  It is important for
 a developer to be able to "quote" your changes, using standard
 e-mail tools, so that they may comment on specific portions of
-your code.  For this reason, all patches should be submitting
-e-mail "inline".  WARNING: Be wary of your MUAs word-wrap
-corrupting your patch.  Do not cut-n-paste your patch.
+your code.  For this reason, all patches should be submited
+"inline".  WARNING: Be wary of your MUAs word-wrap
+corrupting your patch.  Do not cut-n-paste your patch; you can
+lose tabs that way if you are not careful.

-It is common convention to prefix your subject line with
+It is a common convention to prefix your subject line with
 [PATCH].  This lets people easily distinguish patches from other
 e-mail discussions.

--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@ -8,11 +8,13 @@ git-tag -  Create a tag object signed with GPG

 SYNOPSIS
 --------
+[verse]
 'git-tag' [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <name> [<head>]
+'git-tag' -l [<pattern>]

 DESCRIPTION
 -----------
-Adds a 'tag' reference in .git/refs/tags/
+Adds a 'tag' reference in `.git/refs/tags/`

 Unless `-f` is given, the tag must not yet exist in
 `.git/refs/tags/` directory.
@ -32,6 +34,9 @@ GnuPG key for signing.

 `-d <tag>` deletes the tag.

+`-l <pattern>` lists tags that match the given pattern (or all
+if no pattern is given).
+
 OPTIONS
 -------
 -a::
@ -49,6 +54,9 @@ OPTIONS
 -d::
 	Delete an existing tag with the given name

+-l <pattern>::
+	List tags that match the given pattern (or all if no pattern is given).
+
 -m <msg>::
 	Use the given tag message (instead of prompting)

--- a/16
+++ b/16
@ -55,6 +55,9 @@ all:
 #
 # Define NO_ICONV if your libc does not properly support iconv.
 #
+# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
+# a missing newline at the end of the file.
+#
 # Define COLLISION_CHECK below if you believe that SHA1's
 # 1461501637330902918203684832716283019655932542976 hashes do not give you
 # sufficient guarantee that no collisions between objects will ever happen.
@ -273,6 +276,16 @@ ifeq ($(uname_S),AIX)
 	NO_STRCASESTR=YesPlease
 	NEEDS_LIBICONV=YesPlease
 endif
+ifeq ($(uname_S),IRIX64)
+	NO_IPV6=YesPlease
+	NO_SETENV=YesPlease
+	NO_STRCASESTR=YesPlease
+	NO_SOCKADDR_STORAGE=YesPlease
+	SHELL_PATH=/usr/gnu/bin/bash
+	ALL_CFLAGS += -DPATH_MAX=1024
+	# for now, build 32-bit version
+	ALL_LDFLAGS += -L/usr/lib32
+endif
 ifneq (,$(findstring arm,$(uname_M)))
 	ARM_SHA1 = YesPlease
 endif
@ -403,6 +416,9 @@ else
 endif
 endif
 endif
+ifdef NO_ACCURATE_DIFF
+	ALL_CFLAGS += -DNO_ACCURATE_DIFF
+endif

 ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER)) $(COMPAT_CFLAGS)
 LIB_OBJS += $(COMPAT_OBJS)
--- a/apply.c
+++ b/apply.c
@ -1142,6 +1142,14 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag)
 		size -= len;
 	}

+#ifdef NO_ACCURATE_DIFF
+	if (oldsize > 0 && old[oldsize - 1] == '\n' &&
+			newsize > 0 && new[newsize - 1] == '\n') {
+		oldsize--;
+		newsize--;
+	}
+#endif
+			
 	offset = find_offset(buf, desc->size, old, oldsize, frag->newpos);
 	if (offset >= 0) {
 		int diff = newsize - oldsize;
--- a/contrib/README
+++ b/contrib/README
@ -0,0 +1,44 @@
+Contributed Software
+
+Although these pieces are available as part of the official git
+source tree, they are in somewhat different status.  The
+intention is to keep interesting tools around git here, maybe
+even experimental ones, to give users an easier access to them,
+and to give tools wider exposure, so that they can be improved
+faster.
+
+I am not expecting to touch these myself that much.  As far as
+my day-to-day operation is concerned, these subdirectories are
+owned by their respective primary authors.  I am willing to help
+if users of these components and the contrib/ subtree "owners"
+have technical/design issues to resolve, but the initiative to
+fix and/or enhance things _must_ be on the side of the subtree
+owners.  IOW, I won't be actively looking for bugs and rooms for
+enhancements in them as the git maintainer -- I may only do so
+just as one of the users when I want to scratch my own itch.  If
+you have patches to things in contrib/ area, the patch should be
+first sent to the primary author, and then the primary author
+should ack and forward it to me (git pull request is nicer).
+This is the same way as how I have been treating gitk, and to a
+lesser degree various foreign SCM interfaces, so you know the
+drill.
+
+I expect that things that start their life in the contrib/ area
+to graduate out of contrib/ once they mature, either by becoming
+projects on their own, or moving to the toplevel directory.  On
+the other hand, I expect I'll be proposing removal of disused
+and inactive ones from time to time.
+
+If you have new things to add to this area, please first propose
+it on the git mailing list, and after a list discussion proves
+there are some general interests (it does not have to be a
+list-wide consensus for a tool targeted to a relatively narrow
+audience -- for example I do not work with projects whose
+upstream is svn, so I have no use for git-svn myself, but it is
+of general interest for people who need to interoperate with SVN
+repositories in a way git-svn works better than git-svnimport),
+submit a patch to create a subdirectory of contrib/ and put your
+stuff there.
+
+-jc
+
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@ -0,0 +1,38 @@
+gitview(1)
+==========
+
+NAME
+----
+gitview - A GTK based repository browser for git
+
+SYNOPSIS
+--------
+'gitview'  [options] [args]
+
+DESCRIPTION
+---------
+
+Dependencies
+
+* Python 2.4
+* PyGTK 2.8 or later
+* PyCairo 1.0 or later
+
+OPTIONS
+------
+	--without-diff
+		If the user doesn't want to list the commit diffs in the main window. This may speed up the repository browsing.
+
+	<args>
+		All the valid option for git-rev-list(1)
+
+EXAMPLES
+------
+	gitview v2.6.12.. include/scsi drivers/scsi
+	  Show as the changes since version v2.6.12 that changed any file in the include/scsi
+	  or drivers/scsi subdirectories
+
+	gitk --since=2.weeks.ago
+	  Show the changes during the last two weeks 
+
+	
--- a/git-clone.sh
+++ b/git-clone.sh
@ -154,7 +154,7 @@ yes,yes)
 	    fi &&
 	    rm -f "$GIT_DIR/objects/sample" &&
 	    cd "$repo" &&
-	    find objects -depth -print | cpio -puamd$l "$GIT_DIR/" || exit 1
+	    find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
 	    ;;
 	yes)
 	    mkdir -p "$GIT_DIR/objects/info"
--- a/git-tag.sh
+++ b/git-tag.sh
@ -1,7 +1,7 @@
 #!/bin/sh
 # Copyright (c) 2005 Linus Torvalds

-USAGE='[-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <tagname> [<head>]'
+USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <tagname> [<head>]'
 SUBDIRECTORY_OK='Yes'
 . git-sh-setup

@ -10,6 +10,7 @@ signed=
 force=
 message=
 username=
+list=
 while case "$#" in 0) break ;; esac
 do
    case "$1" in
@ -23,6 +24,17 @@ do
    -f)
 	force=1
 	;;
+    -l)
+        cd "$GIT_DIR/refs" &&
+	case "$#" in
+	1)
+		find tags -type f -print ;;
+	*)
+		shift
+		find tags -type f -print | grep "$@" ;;
+	esac
+	exit $?
+	;;
    -m)
    	annotate=1
 	shift