Junio asked that we don't force the user to have a valid X11 server
configured in $DISPLAY just to obtain the output of `git gui version`.
This makes sense, the user may be an automated tool that is running
without an X server available to it, such as a build script or other
sort of package management system. Or it might just be a user working
in a non-GUI environment and wondering "what version of git-gui do I
have installed?".
Tcl has a lot of warts, but one of its better ones is that a comment
can be continued to the next line by escaping the LF that would have
ended the comment using a backslash-LF sequence. In the past we have
used this trick to escape away the 'exec wish' that is actually a Bourne
shell script and keep Tcl from executing it.
I'm using that feature here to comment out the Bourne shell script and
hide it from the Tcl engine. Except now our Bourne shell script is a
few lines long and checks to see if it should print the version, or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Alex Riesen wanted a quieter installation process for git and its
contained git-gui. His earlier patch to do this failed to work
properly when V=1, and didn't really give a great indication of
what the installation was doing.
These rules are a little bit on the messy side, as each of our
install actions is composed of at least two variables, but in the
V=1 case the text is identical to what we had before, while in the
non-V=1 case we use some more complex rules to show the interesting
details, and hide the less interesting bits.
We now can also set QUIET= (nothing) to see the rules that are used
when V= (nothing), so we can debug those too if we have to. This is
actually a side-effect of how we insert the @ into the rules we use
for the "lists of things", like our builtins or our library files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin
to /usr/bin can cause problems with the automatic guessing of our
library location. The problem is that installation to /usr/bin
means we actually have:
/usr/bin = c:\cygwin\bin
/usr/share = c:\cygwin\usr\share
So git-gui guesses that its library should be found within the
c:\cygwin\share directory, as that is where it should be relative
to the script itself in c:\cygwin\bin.
In my first version of this patch I tried to use `cygpath` to resolve
/usr/bin and /usr/share to test that they were in the same relative
locations, but that didn't work out correctly as we were actually
testing /usr/share against itself, so it always was equal, and we
always used relative paths. So my original solution was quite wrong.
Mark suggested we just always disable relative behavior on Cygwin,
because of the complexity of the mount mapping problem, so that's
all I'm doing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
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>
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>
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>
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>
This reverts commit c289f6fa1f.
Junio pointed out that Alex's change breaks in some cases, like
when V=1, and is more verbose than it should be even if that worked.
I'm backing it out and redoing it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
Johannes Sixt asked me to try to avoid embedding the runtime location
of git-gui's library directory in the executable script. Not embedding
it helps the MinGW to be relocatable to another directory should a user
wish to install the programs in a directory other than the location the
packager wanted them to be installed into.
Most of this is a hack. We try to determine if the path of our master
git-gui script will be able to locate the lib by ../share/git-gui/lib.
This should be true if $(gitexecdir) and $(libdir) have the same prefix.
If they do then we defer the assignment of $(libdir) until runtime, and
we get it from $argv0 rather than embedding it into the script itself.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
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>
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>
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>
As most of the git-gui interface is based upon "meta-widgets"
that need to carry around a good deal of state (e.g. console
windows, browser windows, blame viewer) we have a good deal
of messy code that tries to store this meta-widget state in
global arrays, where keys into the array are formed from a
union of a unique "object instance id" and the field name.
This is a simple class system for Tcl that allows us to
hide much of that mess by making Tcl do what it does best;
process strings to manipulate its own code during startup.
Each object instance is placed into its own namespace. The
namespace is created when the object instance is created and
the namespace is destroyed when the object instance is removed
from the system. Within that namespace we place variables for
each field within the class; these variables can themselves be
scalar values or full-blown Tcl arrays.
A simple class might be defined as:
class map {
field data
field size 0
constructor {} {
return $this
}
method set {name value} {
set data($name) $value
incr size
}
method size {} {
return $size
} ifdeleted { return 0 }
}
All fields must be declared before any constructors or methods. This
allows our class to generate a list of the fields so it can properly
alter the definition of the constructor and method bodies prior to
passing them off to Tcl for definition with proc. A field may optionally
be given a default/initial value. This can only be done for non-array
type fields.
Constructors are given full access to all fields of the class, so they
can initialize the data values. The default values of fields (if any)
are set before the constructor runs, and the implicit local variable
$this is initialized to the instance identifier.
Methods are given access to fields they actually use in their body.
Every method has an implicit "this" argument inserted as its first
parameter; callers of methods must be sure they supply this value.
Some basic optimization tricks are performed (but not much). We
try to only upvar (locally bind) fields that are accessed within a
method, but we err on the side of caution and may upvar more than
we need to. If a variable is accessed only once within a method
and that access is by $foo (read) we avoid the upvar and instead
use [set foo] to obtain the value. This is slightly faster as Tcl
does not need to lookup the variable twice.
We also offer some small syntatic sugar for interacting with Tk and
the fileevent callback system in Tcl. If a field (say "foo") is used
as "@foo" we insert instead the true global variable name of that
variable into the body of the constructor or method. This allows easy
binding to Tk textvariable options, e.g.:
label $w.title -textvariable @title
Proper namespace callbacks can also be setup with the special cb proc
that is defined in each namespace. [cb _foo a] will invoke the method
_foo in the current namespace, passing it $this as the first (implied)
parameter and a as the second parameter. This makes it very simple to
connect an object instance to a -command option for a Tk widget or to
a fileevent readable or writable for a file channel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
Include a generalized fixup_pack_header_footer() in this new file.
Needed by git-repack --max-pack-size feature in a later patchset.
[sp: Moved close(pack_fd) to callers, to support index-pack, and
changed name to better indicate it is for packfiles.]
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like core-Git we now track the values that we embed into our shell
script wrapper, and we "recompile" that wrapper if they are changed.
This concept was lifted from git.git's Makefile, where a similar
thing was done by Eygene Ryabinkin. Too bad it wasn't just done
here in git-gui from the beginning, as the git.git Makefile support
for GIT-GUI-VARS was really just because git-gui doesn't do it on
its own.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This splits out a few functions to deal with mailmap from
shortlog and makes it a bit more usable from other programs.
Most notably, it does not clobber input e-mail address anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
ETC_GITCONFIG defaults to $(prefix)/etc/gitconfig, so if you just set
prefix=/usr, you end up with a git that looks in /usr/etc/gitconfig, rather
than /etc/gitconfig as specified by the FHS. Furthermore, setting
ETC_GITCONFIG does not fix the paths to any future system-wide configuration
files.
Factor out the path to the system-wide configuration directory into a variable
sysconfdir, normally set to $(prefix)/etc, but set to /etc when prefix=/usr .
This fixes the prefix=/usr problem for ETC_GITCONFIG, and allows centralized
configuration of any future system-wide configuration files without requiring
further action from package maintainers or other people building and
installing git.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of having this code duplicated in multiple places, let's have
a common interface for progress display. If someday someone wishes to
display a cheezy progress bar instead then only one file will have to
be changed.
Note: I left merge-recursive.c out since it has a strange notion of
progress as it apparently increase the expected total number as it goes.
Someone with more intimate knowledge of what that is supposed to mean
might look at converting it to the common progress interface.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mimick what we do for gitk. Since you do have a source file,
git-gui.sh, which is separate from the target, it should be much
easier in git-gui's Makefile.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit e2a1bc67d3.
Junio rightly pointed out this patch doesn't handle the
`make install` target very well:
Junio C Hamano <junkio@cox.net> writes:
> You should never generate new files in the source tree from
> 'install' target. Otherwise, the usual pattern of "make" as
> yourself and then "make install" as root would not work from a
> "root-to-nobody-squashing" NFS mounted source tree to local
> filesystem. You should know better than accepting such a patch.
This allows you to add an arbitrary "decoration" of your choice to any
object. It's a space- and time-efficient way to add information to
arbitrary objects, especially if most objects probably do not have the
decoration.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I lost it by mistake while shuffling the gitattributes series which
originally was on top of the subproject topic onto the master branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the basic infrastructure to assign attributes to
paths, in a way similar to what the exclusion mechanism does
based on $GIT_DIR/info/exclude and .gitignore files.
An attribute is just a simple string that does not contain any
whitespace. They can be specified in $GIT_DIR/info/attributes
file, and .gitattributes file in each directory.
Each line in these files defines a pattern matching rule.
Similar to the exclusion mechanism, a later match overrides an
earlier match in the same file, and entries from .gitattributes
file in the same directory takes precedence over the ones from
parent directories. Lines in $GIT_DIR/info/attributes file are
used as the lowest precedence default rules.
A line is either a comment (an empty line, or a line that begins
with a '#'), or a rule, which is a whitespace separated list of
tokens. The first token on the line is a shell glob pattern.
The rest are names of attributes, each of which can optionally
be prefixed with '!'. Such a line means "if a path matches this
glob, this attribute is set (or unset -- if the attribute name
is prefixed with '!'). For glob matching, the same "if the
pattern does not have a slash in it, the basename of the path is
matched with fnmatch(3) against the pattern, otherwise, the path
is matched with the pattern with FNM_PATHNAME" rule as the
exclusion mechanism is used.
This does not define what an attribute means. Tying an
attribute to various effects it has on git operation for paths
that have it will be specified separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
By default we are pretty quiet about the actual commands that
we are running. So we should continue to be quiet about the new
merge-subtree hardlink to merge-recursive. Technically this is not
a builtin, but it is close because subtree is actually builtin to
a non-builtin. So lets just make things easy and call it a builtin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This implements the patch-id computation and recording library,
patch-ids.c, and rewrites the get_patch_ids() function used in
cherry and format-patch to use it, so that they do not pollute
the object namespace. Earlier code threw non-objects into the
in-core object database, and hoped for not getting bitten by
SHA-1 collisions. While it may be practically Ok, it still was
an ugly hack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reliance on /dev/urandom produces test vectors that are, well, random.
This can cause problems impossible to track down when the data is
different from one test invokation to another.
The goal is not to have random data to test, but rather to have a
convenient way to create sets of large files with non compressible and
non deltifiable data in a reproducible way.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This merge strategy largely piggy-backs on git-merge-recursive.
When merging trees A and B, if B corresponds to a subtree of A,
B is first adjusted to match the tree structure of A, instead of
reading the trees at the same level. This adjustment is also
done to the common ancestor tree.
If you are pulling updates from git-gui repository into git.git
repository, the root level of the former corresponds to git-gui/
subdirectory of the latter. The tree object of git-gui's toplevel
is wrapped in a fake tree object, whose sole entry has name 'git-gui'
and records object name of the true tree, before being used by
the 3-way merge code.
If you are merging the other way, only the git-gui/ subtree of
git.git is extracted and merged into git-gui's toplevel.
The detection of corresponding subtree is done by comparing the
pathnames and types in the toplevel of the tree.
Heuristics galore! That's the git way ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
The libiconv on Darwin uses the old iconv() interface (2nd argument is a
const char **, instead of a char **). Add OLD_ICONV to the Darwin
variable definitions to handle this.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Acked-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
GNU make does not include environment variables by default
in its namespace. Just pass them in make command line.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Makefile got one external option:
- TCLTK_PATH: the path to the Tcl/Tk interpreter.
Users (or build wrappers) may set this variable to the
location of the wish executable.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
--with-tcltk=/path/to/wish sets the TCLTK_PATH variable that is
used to substitute the location of the wish interpreter in the
Tcl/Tk programs.
New tracking file, GIT-GUI-VARS, was introduced: it tracks the
location of the Tcl/Tk interpreter and activates the GUI tools
rebuild if the interpreter path was changed. The separate tracker
is better than the GIT-CFLAGS: there is no need to rebuild the whole
git if the interpreter path was changed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
--with-tcltk enables the search of the Tcl/Tk interpreter. If no
interpreter is found then Tcl/Tk dependend parts are disabled.
--without-tcltk unconditionally disables Tcl/Tk dependent parts.
The original behaviour is not changed: bare './configure' just
installs the Tcl/Tk part doing no checks for the interpreter.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Shawn O. Pearce