Just for consistency, use the spelling URL everywhere.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If I'm handed a file, then it typically lives outside the
working directory. git-log only operates on in-tree files,
so the first 'filename' should be an in-tree one, or it should
look at all files. This patch does the latter, so it would
also find renamed files. However, it is also slower.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Make the definition of push in the glossary readable.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
em dashes were used inconsistently in the manual.
This changes them to the way they are used in US English.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The default behaviour of git-push is potentially confusing
for new users, since it will push changes that are not on
the current branch. Publishing patches that were still
cooking on a development branch is hard to undo.
It would also be nice to be able to verify the expansion
of refspecs if you've edited them, so that you know
what branches matched on the server.
Adding a --dry-run flag allows the user to experiment
safely and learn how to use git-push properly. Originally
suggested by Steffen Prohaska.
Signed-off-by: Brian Ewins <brian.ewins@gmail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Implement support for --dry-run, so that it can be used
in calls from git-push. With this flag set, git-send-pack
will not send any updates to the server.
Signed-off-by: Brian Ewins <brian.ewins@gmail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There were a few places which did not cope well without curl. This
fixes all of them. We still need to link against the walker.o part
of the library as some parts of transport.o still call into there
even though we don't have HTTP support enabled.
If compiled with NO_CURL=1 we now get the following useful error
message:
$ git-fetch http://www.example.com/git
error: git was compiled without libcurl support.
fatal: Don't know how to fetch from http://www.example.com/git
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* crlf_to_git and ident_to_git:
Don't grow the buffer if there is enough space in the first place.
As a side effect, when the editing is done "in place", we don't grow, so
the buffer pointer doesn't changes, and `src' isn't invalidated anymore.
Thanks to Bernt Hansen for the bug report.
* apply_filter:
Fix memory leak due to fake in-place editing that didn't collected the
old buffer when the filter succeeds. Also a cosmetic fix.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
running the webrick server with git requires Ruby and Ruby's YAML and
Webrick libraries (both of which come standard with Ruby). nice for
single-user standalone invocations.
the --httpd=webrick option generates a ruby script on the fly to read
httpd.conf options and invoke the web server via library call. this
script is placed in the .git/gitweb directory. it also generates a
shell script in a feeble attempt to invoke ruby in a portable manner,
which assumes that 'ruby' is in the user's $PATH.
Signed-off-by: Mike Dalessio <mike@csa.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
this patch allows scripts that reside in $fqgitdir/gitweb to be used
for firing up an instaweb server. this lays the groundwork for
extending instaweb support to non-standard web servers, which may
require a script for proper invocation.
Signed-off-by: Mike Dalessio <mike@csa.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Given that git uses 'commit', git-p4's 'sumbit' was a bit confusing at times;
often making me do 'git submit' and 'git-p4 commit' instead.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Acked-By: Simon Hausmann <simon@lst.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Parameters 'store-passwords' and 'store-auth-creds' from Subversion's
configuration (~/.subversion/config) were not respected. This was
fixed: the default values for these parameters are set to 'yes' to
follow Subversion behaviour.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Added support for gtksourceview2 module (pygtksourceview 1.90.x) in
gitview. Also refactored code that creates the source buffer and view.
Signed-off-by: Frederick Akalin <akalin@akalin.cx>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Have the error message for missing recipients actually report the
missing config variable and not a fictional one.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This adds cvs support to the git-shell; You can now give new users
a restricted git-shell and they still can commit via git's cvs
emulator.
Note that either the gecos information must be accurate, or you must
provide a $HOME/.gitconfig with the appropriate user credentials.
Since the git-shell is too restricted to allow the user to do it
(on purpose!), it is up to the administrator to take care of that.
Based on an idea by Jan Wielemaker.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When diff drivers are installed, calling "git diff <tree1>..<tree2>"
calls those drivers. This borks the patch generation of rebase -i.
So use "git diff-tree -p" instead, which does not call diff drivers.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Before this patch the clean target has removed the
configure script that comes with Git tar file.
That made compiling Git for different architectures
inconvenient.
This patch excludes configure from the files to be
deleted by 'make clean' and adds new target 'distclean'
to preserve old functionality.
Signed-off-by: Mathias Megyei <mathias@mnet-mail.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The current makefile supports ctags but not cscope. Some people prefer
cscope (I do), so this patch adds a cscope target.
I've also added cscope* to the .gitignore file. For some reason tags
and TAGS weren't in there either so I've added them too.
Signed-off-by: Kristof Provost <Kristof@provost-engineering.be>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When calling git-config not from the top level directory of a repository,
it changes directory before trying to open the config file specified
through the --file option, which then fails if the config file was
specified by a relative pathname. This patch adjusts the pathname to
the config file if applicable.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Before this patch, clear_commit_marks() recursed for each parent. This
could be potentially very expensive in terms of stack space. Probably
the only reason that this did not lead to problems is the fact that we
typically call clear_commit_marks() after marking a relatively small set
of commits.
Use (sort of) a tail recursion instead: first recurse on the parents
other than the first one, and then continue the loop with the first
parent.
Noticed by Shawn Pearce.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The unified diff format allows one-line ranges to be abbreviated
by omiting the size. The hunk header "@@ -10,1 +10,1 @@" can be
expressed as "@@ -10 +10 @@", but this wasn't properly parsed in
all cases.
Such abbreviated hunk headers are generated when a one-line change
(add, remove or modify) appears without context; for example
because the file is a one-liner itself or because GIT_DIFF_OPTS
was set to '-u0'. If the user then runs 'git add -i' and enters
the 'patch' command for that file, perl complains about undefined
variables.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Error out if someone gives options after --list since that is
not a valid syntax.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since "-a" is removed from the base repack command line,
we can simplify how we add additional options to this
command line when using --auto.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This makes use of repack's new "-A" option which does not drop packed
unreachable objects. This makes git-gc safe to call at any time,
particularly when a repository is referenced as an alternate by
another repository.
git-gc --prune will use the "-a" option to repack instead of "-A", so
that packed unreachable objects will be removed.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When a user runs "git fetch -t", git crashes when it doesn't find any
tags on the remote repository.
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Originally-by: Väinö Järvelä <v@pp.inet.fi>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If multiple refspecs matched the same ref, the update would be
processed multiple times. Now having the same destination for the same
source has no additional effect, and having the same destination for
different sources is an error.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This fixes an unnecessary empty line that we add to the log message when
we generate diffs, but don't actually end up printing any due to having
DIFF_FORMAT_NO_OUTPUT set.
This can happen with pickaxe or with rename following. The reason is that
we normally add an empty line between the commit and the diff, but we do
that even for the case where we've then suppressed the actual printing of
the diff.
This also updates a couple of tests that assumed the extraneous empty
line would exist at the end of output.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It turns out that I completely broke "git log --follow" with my recent
patch to revision.c ("Fix revision log diff setup, avoid unnecessary diff
generation", commit b7bb760d5e).
Why? Because --follow obviously requires the diff machinery to function,
exactly the same way pickaxe does.
So everybody is away right now, but considering that nobody even noticed
this bug, I don't think it matters. But for the record, here's the trivial
one-liner fix (well, two, since I also fixed the comment).
Because of the nature of the bug, if you ask for patches when following
(which is one of the things I normally do), the bug is hidden, because
then the request for diff output will automatically also enable the diffs
themselves.
So while "git log --follow <filename>" didn't work, adding a "-p"
magically made it work again even without this fix.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I keep forgetting to include TCLTK_PATH when I build git-gui on some
systems. Placing that rule (among others) into a config.mak makes it
easier to compile the application the same way every time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently native Tcl/Tk on Windows is using \ as the return value
from [file separator] but [file normalize] on that same system is
using / rather than \ to represent a directory separator. I really
think that is nuts, but its what is happening.
So we can actually just hardcode our separator to / as all systems
we support (Windows, Mac OS X, UNIX) use /.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user tries to clone a Git repository that is actually a
workdir of another repository (by way of contrib git-new-workdir)
then the contents of .git is a series of Windows .lnk files which
Tcl can't read if this is a native Tcl process. To read the real
objects directory we need to resolve the link to that location.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows its better to use a shortcut (.lnk file) over a batch
script (.bat) as we can specify the icon file for the .lnk and
thus have these git specific objects appear on the desktop with
that git specific icon file.
Unfortunately the authors of Tcl did not bless us with the APIs
needed to create shortcuts from within Tcl. But Microsoft did
give us Windows Scripting Host which allows us to execute some
JavaScript that calls some sort of COM object that can operate
on a .lnk file.
We now build both Cygwin and non-Cygwin "desktop icons" as proper
Windows .lnk files, using the "Start in" property of these files
to indicate the working directory of the repository the user wants
to launch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows using the native Tcl/Tk the copyright header is
being read from the script using the system encoding, which
may not be utf-8. This causes the multi-byte copyright symbol
(which is actually encoded as utf-8) to read as two characters
and not as a proper copyright symbol. Explicitly asking Tcl
to read this sequence of bytes as utf-8 corrects the issue.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows we need to actually setup binds for the accelerator
keys, otherwise the OS doesn't respond to them when the user
presses the key combinations. Apparently we automatically get
these on Mac OS X when we configure the menu commands, but not
on Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Although we are using a text widget here we really do not
want the end-user to be able to modify the text it displays.
So we need to disable it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We need to remove any variable traces we may have installed
when the panel is destroyed as the trace may attempt to use
a widget that no longer exists on this panel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we show the repository chooser as the primary toplevel (".") we
now offer the major choices not just on the window as hyperlinks but
they also now are shown in the Repository menu, including the recent
repository list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Making a user click twice to select which action they want to perform
when starting git-gui is just wasting their time. Clicking once on a
radio button and then clicking again on the "Next >" button is quite
unnecessary.
Since the recent repository list is shown as a list of hyperlinks we
now offer the 3 basic startup actions as hyperlinks. Clicking on a
link will immediately jump to the next UI panel, saving the user time
as they don't need to click an additional button.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-gui is started outside a work tree the repository chooser
will offer a list of recently opened repositories. Clicking on
any list entry directly opens the repository.
The list of recently opened repositories is stored in the config
as the multi-valued option gui.recentrepo. If the list grows beyond
10 entries it will be truncated by removing one of the older entries.
Only repositories that are opened through the repository chooser
will get added to the recent list. Repositories opened from the
shell will not yet be added to the recent list, as users are likely
to have a way to easily return to the same directory via their shell.
[sp: This is actually a combined work from both Steffen and myself.
Most of the ideas are Steffen's, as is the basic outline of
the code, but any outstanding bugs are entirely my fault.]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Using the new --null option added to git-config in git 1.5.3 we
can safely accept LFs that are embedded in configuration options.
This does require a completely different configuration file parser
then the pre 1.5.3 version as we are splitting on very different
values.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The parsing for the output of `git config --list` is the same for
both the global options and the current repository's options so we
can really just use the same parser between them.
I'm currently just refactoring the parser so we can use a different
one depending on the version of git available to us at runtime. My
next change will add support for 1.5.3's --null option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To better handle configuration options that contain LFs in their
values we want to use the new -z option available in git-config
version 1.5.3 and later. To configure load_config based upon the
git version we need to move thos below the git-version computation.
No logic changes yet, just a minor reordering of the code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
