summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2007-09-12Define NO_MEMMEM of FreeBSD as it lacks the functionLibravatar Robert Boone1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-10Merge branch 'rs/archive'Libravatar Junio C Hamano1-0/+12
* rs/archive: archive - leakfix for format_subst() Define NO_MEMMEM on Darwin as it lacks the function archive: rename attribute specfile to export-subst archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2) add memmem() Remove unused function convert_sha1_file() archive: specfile support (--pretty=format: in archive files) Export format_commit_message()
2007-09-09Define NO_MEMMEM on Darwin as it lacks the functionLibravatar Shawn O. Pearce1-0/+1
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06add memmem()Libravatar René Scharfe1-0/+11
memmem() is a nice GNU extension for searching a length limited string in another one. This compat version is based on the version found in glibc 2.2 (GPL 2); I only removed the optimization of checking the first char by hand, and generally tried to keep the code simple. We can add it back if memcmp shows up high in a profile, but for now I prefer to keep it (almost trivially) simple. Since I don't really know which platforms beside those with a glibc have their own memmem(), I used a heuristic: if NO_STRCASESTR is set, then NO_MEMMEM is set, too. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05Makefile: Add cache-tree.h to the headers listLibravatar Dmitry V. Levin1-1/+1
The dependency was missing. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-30Makefile: do not allow gnu make to remove test-*.o filesLibravatar Junio C Hamano1-0/+2
It appears parallel build (-j) gets confused. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-10Merge branch 'cr/tag'Libravatar Junio C Hamano1-1/+2
* cr/tag: Teach "git stripspace" the --strip-comments option Make verify-tag a builtin. builtin-tag.c: Fix two memory leaks and minor notation changes. launch_editor(): Heed GIT_EDITOR and core.editor settings Make git tag a builtin.
2007-08-10Add support for an info version of the user manualLibravatar David Kastrup1-0/+6
These patches use docbook2x in order to create an info version of the git user manual. No existing Makefile targets (including "all") are touched, so you need to explicitly say make info sudo make install-info to get git.info created and installed. If the info target directory does not already contain a "dir" file, no directory entry is created. This facilitates $(DESTDIR)-based installations. The same could be achieved with sudo make INSTALL_INFO=: install-info explicitly. perl is used for patching up sub-par file and directory information in the Texinfo file. It would be cleaner to place the respective info straight into user-manual.txt or the conversion configurations, but I find myself unable to find out how to do this with Asciidoc/Texinfo. Signed-off-by: David Kastrup <dak@gnu.org>
2007-08-02Support building on GNU/HurdLibravatar Thomas Schwinge1-0/+4
GNU/Hurd systems don't have strlcpy. Signed-off-by: Thomas Schwinge <tschwinge@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01Add is_absolute_path() and make_absolute_path()Libravatar Johannes Schindelin1-1/+1
This patch adds convenience functions to work with absolute paths. The function is_absolute_path() should help the efforts to integrate the MinGW fork. Note that make_absolute_path() returns a pointer to a static buffer. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-31make the name of the library directory a config optionLibravatar Robert Schiele1-5/+6
Introduce new makefile variable lib to hold the name of the lib directory ("lib" by default). Also introduce a switch for configure to specify this name with --with-lib=ARG. This is useful for systems that use a different name than "lib" (like "lib64" on some 64 bit Linux architectures). Signed-off-by: Robert Schiele <rschiele@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-31add option to find zlib in custom pathLibravatar Robert Schiele1-1/+7
Some systems do not provide zlib development headers and libraries in default search path of the compiler. For these systems we should allow specifying the location by --with-zlib=PATH or by setting ZLIB_PATH in the makefile. Signed-off-by: Robert Schiele <rschiele@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-29Makefile: use $(FIND) instead of findLibravatar David Kastrup1-2/+3
Some people might prefer to be able to specify the find utility to use. Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-26Make verify-tag a builtin.Libravatar Carlos Rica1-1/+1
This replaces "git-verify-tag.sh" with "builtin-verify-tag.c". Testing relies on the "git tag -v" tests calling this command. A temporary file is needed when calling to gpg, because git is already creating detached signatures (gpg option -b) to sign tags (instead of leaving gpg to add the signature to the file by itself), and those signatures need to be supplied in a separate file to be verified by gpg. The program uses git_mkstemp to create that temporary file needed by gpg, instead of the previously used "$GIT_DIR/.tmp-vtag", in order to allow the command to be used in read-only repositories, and also prevent other instances of git to read or remove the same file. Signal SIGPIPE is ignored because the program sometimes was terminated because that signal when writing the input for gpg. The command now can receive many tag names to be verified. Documentation is also updated here to reflect this new behaviour. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-20Make git tag a builtin.Libravatar Carlos Rica1-1/+2
This replaces the script "git-tag.sh" with "builtin-tag.c". The existing test suite for "git tag" guarantees the compatibility with the features provided by the script version. There are some minor changes in the behaviour of "git tag" here: "git tag -v" now can get more than one tag to verify, like "git tag -d" does, "git tag" with no arguments prints all tags, more like "git branch" does, and "git tag -n" also prints all tags with annotations (without needing -l). Tests and documentation were also updated to reflect these changes. The program is currently calling the script "git verify-tag" for verify. This can be changed porting it to C and calling its functions directly from builtin-tag.c. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-15Remove "WITH_P4IMPORT" knob from the MakefileLibravatar Sean1-26/+0
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-14Use $(RM) in Makefiles instead of 'rm -f'Libravatar Emil Medve1-33/+34
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-09Makefile: rebuild git.o on version change, clean up git$X flagsLibravatar Matt McCutchen1-3/+2
Commit 334d28ae factored out git.o as an intermediate stage between git.c and git$X. However: - It left some no-longer-relevant flags in the rule for git$X. - It failed to replace git$X with git.o in the list of files that record GIT_VERSION. This broke incorporation of a changed GIT_VERSION into git$X because, when GIT_VERSION changes, git.o isn't remade and git$X is relinked from the git.o that still contains the old GIT_VERSION. This patch removes the irrelevant flags and fixes incorporation of a changed GIT_VERSION into git$X. Signed-off-by: Matt McCutchen <hashproduct@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Start deprecating "git-command" in favor of "git command"Libravatar Linus Torvalds1-1/+2
I realize that a lot of people use the "git-xyzzy" format, and we have various historical reasons for it, but I also think that most people have long since started thinking of the git command as a single command with various subcommands, and we've long had the documentation talk about it that way. Slowly migrating away from the git-xyzzy format would allow us to eventually no longer install hundreds of binaries (even if most of them are symlinks or hardlinks) in users $PATH, and the _original_ reasons for it (implementation issues and bash completion) are really long long gone. Using "git xyzzy" also has some fundamental advantages, like the ability to specify things like paging ("git -p xyzzy") and making the whole notion of aliases act like other git commands (which they already do, but they do *not* have a "git-xyzzy" form!) Anyway, while actually removing the "git-xyzzy" things is not practical right now, we can certainly start slowly to deprecate it internally inside git itself - in the shell scripts we use, and the test vectors. This patch adds a "remove-dashes" makefile target, which does that. It isn't particularly efficient or smart, but it *does* successfully rewrite a lot of our shell scripts to use the "git xyzzy" form for all built-in commands. (For non-builtins, the "git xyzzy" format implies an extra execve(), so this script leaves those alone). So apply this patch, and then run make remove-dashes make test git commit -a to generate a much larger patch that actually starts this transformation. (The only half-way subtle thing about this is that it also fixes up git-filter-branch.sh for the new world order by adding quoting around the use of "git-commit-tree" as an argument. It doesn't need it in that format, but when changed into "git commit-tree" it is no longer a single word, and the quoting maintains the old behaviour). NOTE! This does not yet mean that you can actually stop installing the "git-xyzzy" binaries for the builtins. There are some remaining places that want to use the old form, this just removes the most obvious ones that can easily be done automatically. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Merge branch 'ns/stash'Libravatar Junio C Hamano1-1/+2
* ns/stash: Documentation: quote {non-attributes} for asciidoc git-stash: don't complain when listing in a repo with no stash git-stash: fix "can't shift that many" with no arguments git-stash: fix "no arguments" case in documentation git-stash: require "save" to be explicit and update documentation Document git-stash Add git-stash script
2007-07-02Merge branch 'js/rebase'Libravatar Junio C Hamano1-1/+1
* js/rebase: Teach rebase -i about --preserve-merges rebase -i: provide reasonable reflog for the rebased branch rebase -i: several cleanups ignore git-rebase--interactive Teach rebase an interactive mode Move the pick_author code to git-sh-setup
2007-06-30Add git-stash scriptLibravatar しらいしななこ1-1/+2
When my boss has something to show me and I have to update, for some reason I am always in the middle of doing something else, and git pull command refuses to work in such a case. I wrote this little script to save the changes I made, perform the update, and then come back to where I was, but on top of the updated commit. This is how you would use the script: $ git stash $ git pull $ git stash apply [jc: with a few fixlets from the list] Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-30Merge branch 'maint'Libravatar Junio C Hamano1-3/+3
* maint: Correct the name of NO_R_TO_GCC_LINKER in the comment describing it. git-remote: document -n repack: improve documentation on -a option
2007-06-30Correct the name of NO_R_TO_GCC_LINKER in the comment describing it.Libravatar Matt Kraai1-3/+3
Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-24Teach rebase an interactive modeLibravatar Johannes Schindelin1-1/+1
Don't you just hate the fact sometimes, that git-rebase just applies the patches, without any possibility to edit them, or rearrange them? With "--interactive", git-rebase now lets you edit the list of patches, so that you can reorder, edit and delete patches. Such a list will typically look like this: pick deadbee The oneline of this commit pick fa1afe1 The oneline of the next commit ... By replacing the command "pick" with the command "edit", you can amend that patch and/or its commit message, and by replacing it with "squash" you can tell rebase to fold that patch into the patch before that. It is derived from the script sent to the list in <Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-24make dist: include configure script in tarballLibravatar Matthias Lederhofer1-2/+3
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-22Merge branch 'js/filter'Libravatar Junio C Hamano1-1/+2
* js/filter: filter-branch: subdirectory filter needs --full-history filter-branch: Simplify parent computation. Teach filter-branch about subdirectory filtering filter-branch: also don't fail in map() if a commit cannot be mapped filter-branch: Use rev-list arguments to specify revision ranges. filter-branch: fix behaviour of '-k' filter-branch: use $(($i+1)) instead of $((i+1)) chmod +x git-filter-branch.sh filter-branch: prevent filters from reading from stdin t7003: make test repeatable Add git-filter-branch
2007-06-16Merge branch 'maint' to sync with GIT 1.5.2.2Libravatar Junio C Hamano1-0/+11
2007-06-16Documentation: adjust to AsciiDoc 8Libravatar Junio C Hamano1-0/+6
It turns out that the attribute definition we have had for a long time to hide "^" character from AsciiDoc 7 was not honored by AsciiDoc 8 even under "-a asciidoc7compatible" mode. There is a similar breakage with the "compatible" mode with + characters. The double colon at the end of definition list term needs to be attached to the term, without a whitespace. After this minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with compatibility mode seems to produce reasonably good results. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-15Add a local implementation of hstrerror for the system which do not have itLibravatar Alex Riesen1-0/+5
The function converts the value of h_errno (last error of name resolver library, see netdb.h). One of systems which supposedly do not have the function is SunOS. POSIX does not mandate its presence. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-13Makefile: allow generating git.o for debugging purposesLibravatar Junio C Hamano1-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-13Makefile: common-cmds.h depends on generate-cmdlist.sh scriptLibravatar Junio C Hamano1-0/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-12Remove trailing slash from $(template_dir).Libravatar Johannes Sixt1-1/+1
All the other directory location variables do not have the trailing slash. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-12Avoid double-slash in path names that depend on $(sharedir).Libravatar Johannes Sixt1-1/+1
Recent git-gui has the ability to determine the location of its library files relative to the --exec-dir. Its Makefile enables this capability depending on the install paths that are specified. However, without this fix there is an extra slash in a path specification, so that the Makefile does not recognize the equivalence of two paths that it compares. A side-effect is that all "standard" builds (which do not set $(sharedir) explicitly) now exploit above mentioned gut-gui feature. Another side-effect is that an ugly compiled-in double-slash in $(template_dir) is avoided. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-10Makefile: add an explicit rule for building assembly outputLibravatar Linus Torvalds1-0/+2
In the kernel we have a rule for *.c -> *.s files exactly because it's nice to be able to easily say "ok, what does that generate". Here's a patch to add such a rule to git too, in case anybody is interested. It makes it much simpler to just do make sha1_file.s and look at the compiler-generated output that way, rather than having to fire up gdb on the resulting binary. (Add -fverbose-asm or something if you want to, it can make the result even more readable) [jc: add *.s to .gitignore] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06Makefile: Remove git-merge-base from PROGRAMS.Libravatar Johannes Sixt1-1/+0
git-merge-base is a builtin. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06make clean should remove all the test programs tooLibravatar Matthias Lederhofer1-1/+2
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-02Add git-filter-branchLibravatar Johannes Schindelin1-1/+2
This script is derived from Pasky's cg-admin-rewritehist. In fact, it _is_ the same script, minimally adapted to work without cogito. It _should_ be able to perform the same tasks, even if only relying on core-git programs. All the work is Pasky's, just the adaption is mine. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Hopefully-signed-off-by: Petr "cogito master" Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-06-02Merge branches 'lh/submodules' and 'pb/am'Libravatar Junio C Hamano1-2/+2
* lh/submodules: Add basic test-script for git-submodule Add git-submodule command * pb/am: Remove git-applypatch git-applymbox: Remove command
2007-05-30Makefile: Use generic rule to build test programsLibravatar Julian Phillips1-19/+5
Use a generic make rule to build all the test programs, rather than specifically mentioning each one. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-29Merge branch 'db/remote'Libravatar Junio C Hamano1-2/+3
* db/remote: Move refspec pattern matching to match_refs(). Update local tracking refs when pushing Add handlers for fetch-side configuration of remotes. Move refspec parser from connect.c and cache.h to remote.{c,h} Move remote parsing into a library file out of builtin-push.
2007-05-28Makefile: Remove git-fsck and git-verify-pack from PROGRAMSLibravatar Nguyen Thai Ngoc Duy1-2/+2
Those are builtins. Remove them from PROGRAMS variable Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-26Add git-submodule commandLibravatar Lars Hjemli1-1/+1
This command can be used to initialize, update and inspect submodules. It uses a .gitmodules file, readable by git-config, in the top level directory of the 'superproject' to specify a mapping between submodule paths and repository url. Example .gitmodules layout: [module "git"] url = git://git.kernel.org/pub/scm/git/git.git With this entry in .gitmodules (and a commit reference in the index entry for the path "git"), the command 'git submodule init' will clone the repository at kernel.org into the directory "git". Known issues ============ There is currently no way to override the url found in the .gitmodules file, except by manually creating the subproject repository. The place to fix this in the script has a rather long comment about a possible plan. Funny paths will be quoted in the output from git-ls-files, but git-submodule does not attempt to unquote (or even detect the presence of) such paths. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24Remove git-applypatchLibravatar Junio C Hamano1-1/+1
The previous one removed git-applymbox, which was the sole user of this tool. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24git-applymbox: Remove commandLibravatar Petr Baudis1-1/+1
I believe noone uses git-applymbox, and noone definitely should, since it is supposed to be completely superseded and everything by its younger cousin git-am. The only known person in the universe to use it was Linus and he declared some time ago that he will try to use git-am instead in his famous dotest script. The trouble is that git-applymbox existence creates confusing UI. I'm a bit like a recycled newbie to the git porcelain and *I* was confused by git-applymbox primitiveness until I've realized a while later that I'm of course using the wrong command. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Move remote parsing into a library file out of builtin-push.Libravatar Daniel Barkalow1-2/+3
The new parser is different from the one in builtin-push in two ways: the default is to use the current branch's remote, if there is one, before "origin"; and config is used in preference to remotes. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-11apply: do not get confused by symlinks in the middleLibravatar Junio C Hamano1-1/+1
HPA noticed that git-rebase fails when changes involve symlinks in the middle of the hierarchy. Consider: * The tree state before the patch is applied has arch/x86_64/boot as a symlink pointing at ../i386/boot/ * The patch tries to remove arch/x86_64/boot symlink, and create bunch of files there: .gitignore, Makefile, etc. git-apply tries to be careful while applying patches; it never touches the working tree until it is convinced that the patch would apply cleanly. One of the check it does is that when it knows a path is going to be created by the patch, it runs lstat() on the path to make sure it does not exist. This leads to a false alarm. Because we do not touch the working tree before all the check passes, when we try to make sure that arch/x86_64/boot/.gitignore does not exist yet, we haven't removed the arch/x86_64/boot symlink. The lstat() check ends up seeing arch/i386/boot/.gitignore through the yet-to-be-removed symlink, and says "Hey, you already have a file there, but what you fed me is a patch to create a new file. I am not going to clobber what you have in the working tree." We have similar checks to see a file we are going to modify does exist and match the preimage of the diff, which is done by directly opening and reading the file. For a file we are going to delete, we make sure that it does exist and matches what is going to be removed (a removal patch records the full preimage, so we check what you have in your working tree matches it in full -- otherwise we would risk losing your local changes), which again is done by directly opening and reading the file. These checks need to be adjusted so that they are not fooled by symlinks in the middle. - To make sure something does not exist, first lstat(). If it does not exist, it does not, so be happy. If it _does_, we might be getting fooled by a symlink in the middle, so break leading paths and see if there are symlinks involved. When we are checking for a path a/b/c/d, if any of a, a/b, a/b/c is a symlink, then a/b/c/d does _NOT_ exist, for the purpose of our test. This would fix this particular case you saw, and would not add extra overhead in the usual case. - To make sure something already exists, first lstat(). If it does not exist, barf (up to this, we already do). Even if it does seem to exist, we might be getting fooled by a symlink in the middle, so make sure leading paths are not symlinks. This would make the normal codepath much more expensive for deep trees, which is a bit worrisome. This patch implements the first side of the check "making sure it does not exist". The latter "making sure it exists" check is not done yet, so applying the patch in reverse would still fail, but we have to start from somewhere. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-07Remove duplicate exports from MakefileLibravatar Shawn O. Pearce1-1/+1
We already export these variables earlier in the Makefile, right after they were 'declared'. There is no point in doing so again. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-07Merge branch 'master' of git://repo.or.cz/git-guiLibravatar Shawn O. Pearce1-4/+12
* 'master' of git://repo.or.cz/git-gui: git-gui: Use vi-like keys in merge dialog git-gui: Include commit id/subject in merge choices git-gui: Show all possible branches for merge git-gui: Move merge support into a namespace git-gui: Allow vi keys to scroll the diff/blame regions git-gui: Move console procs into their own namespace git-gui: Refactor into multiple files to save my sanity git-gui: Track our own embedded values and rebuild when they change git-gui: Refactor to use our git proc more often git-gui: Use option database defaults to set the font git-gui: Cleanup common font handling for font_ui git-gui: Correct line wrapping for too many branch message git-gui: Warn users before making an octopus merge git-gui: Include the subject in the status bar after commit Also perform an evil merge change to update Git's main Makefile to pass the proper options down into git-gui now that it depends on reasonable values for 'sharedir' and 'TCL_PATH'. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-07git-gui: Refactor into multiple files to save my sanityLibravatar Shawn O. Pearce1-2/+21
I'm finding it difficult to work with a 6,000+ line Tcl script and not go insane while looking for a particular block of code. Since most of the program is organized into different units of functionality and not all users will need all units immediately on startup we can improve things by splitting procs out into multiple files and let auto_load handle things for us. This should help not only to better organize the source, but it may also improve startup times for some users as the Tcl parser does not need to read as much script before it can show the UI. In many cases the user can avoid reading at least half of git-gui now. Unfortunately we now need a library directory in our runtime location. This is currently assumed to be $(sharedir)/git-gui/lib and its expected that the Makefile invoker will setup some sort of reasonable sharedir value for us, or let us assume its going to be $(gitexecdir)/../share. We now also require a tclsh (in TCL_PATH) to just run the Makefile, as we use tclsh to generate the tclIndex for our lib directory. I'm hoping this is not an unncessary burden on end-users who are building from source. I haven't really made any functionality changes here, this is just a huge migration of code from one file to many smaller files. All of the new changes are to setup the library path and install the library files. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>