Use the new "git var GIT_EDITOR" feature to decide what editor to
use, instead of duplicating its logic elsewhere. This should make
the behavior of commands in edge cases (e.g., editor names with
spaces) a little more consistent.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Expose the command found by setup_pager() for scripts to use.
Scripts can use this to avoid repeating the logic to look for a
proper pager in each command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Expose the command used by launch_editor() for scripts to use.
This should allow one to avoid searching for a proper editor
separately in each command.
git_editor(void) uses the logic to decide which editor to use
that used to live in launch_editor(). The function returns NULL
if there is no suitable editor; the caller is expected to issue
an error message when appropriate.
launch_editor() uses git_editor() and gives the error message the
same way as before when EDITOR is not set.
"git var GIT_EDITOR" gives the editor name, or an error message
when there is no appropriate one.
"git var -l" gives GIT_EDITOR=name only if there is an
appropriate editor.
Originally-submitted-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For scripts using "git var -l" to read all logical variables at
once, not all per-variable warnings will be relevant. So suppress
them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass the editor name to the shell if it contains any susv3 shell
special character (globs, redirections, variable substitutions,
escapes, etc). This way, the meaning of some characters will not
meaninglessly change when others are added, and git commands
implemented in C and in shell scripts will interpret editor names
in the same way.
This does not make the GIT_EDITOR setting any more expressive,
since one could always use single quotes to force the editor to
be passed to the shell.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
help -a: do not unnecessarily look for a repository
Do not try to remove directories when removing old links
rebase -i: more graceful handling of invalid commands
help -i: properly error out if no info viewer can be found
'git commit -s' will insert a blank line before the Signed-off-by
line at the end of the message, unless this last line is a
Signed-off-by line itself. Common use has other trailing lines
at the ends of commit text, in the style of RFC2822 headers.
Be more generous in considering lines to be part of this footer.
If the last paragraph of the commit message reasonably resembles
RFC-2822 formatted lines, don't insert that blank line.
The new Signed-off-by line is still only suppressed when the
author's existing Signed-off-by is the last line of the message.
Signed-off-by: David Brown <davidb@quicinc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So complete refs, files after the double-dash and some diff options that
make sense for difftool.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although 'git help -a' actually doesn't need to be run inside a git
repository and uses no repository-specific information, it looks for a git
directory. On 'git <TAB><TAB>' the bash completion runs 'git help -a' and
unnecessary searching for a git directory can be annoying in auto-mount
environments. With this commit, 'git help' no longer searches for a
repository when run with the -a option.
Reported by Vincent Danjean through http://bugs.debian.org/539273
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Complete all long options for 'git rebase' except --no-verify
(probably used very seldom) and the long options corresponding
to -v, -q, and -f.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When building Git with MSVC on Windows, directories named after the Git alias
are created for the output files, e.g. there is a "git-merge-index" directory
next to the "git-merge-index.exe" executable in the build root. Previously,
"make all" just checked if "git-merge-index" and "git-merge-index.exe" are the
same file, and if not, tried to remove "git-merge-index". This fails in the
case of "git-merge-index" being a directory, which is why this is checked now.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when there is an invalid command, the rest of the line is
still treated as if the command had been valid, i.e. rebase -i attempts
to produce a patch, using the next argument as a SHA1 name. If there is
no next argument or an invalid one, very confusing error messages
appear (the line was '.'; path to git-rebase-todo substituted):
Unknown command: .
fatal: ambiguous argument 'Please fix this in the file $somefile.':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name Please fix this in the file $somefile.
fatal: bad revision 'Please fix this in the file $somefile.'
Instead, verify the validity of the remaining line and error out earlier
if necessary.
Signed-off-by: Jan Krüger <jk@jk.gs>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this commit, git help -i <cmd> prints an error message and exits
non-zero instead of being silent and exit code 0.
Reported by Trent W. Buck through
http://bugs.debian.org/537664
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
git-svn: add test data for SVN 1.5+ merge, with script.
git-svn: convert SVK merge tickets to extra parents
git-svn: allow test setup script to support PERL env. var
git-svn: add test data for SVK merge, with script.
git svn: fix fetch where glob is on the top-level URL
* git://repo.or.cz/git-gui:
git-gui: adjust the minimum height of diff pane for shorter screen height
git-gui: fix use of uninitialized variable
git-gui: store wm state and fix wm geometry
git-gui: Ensure submodule path is quoted properly
git-gui: fix diff for partially staged submodule changes
git-gui: Update russian translation
git-gui: Limit display to a maximum number of files
git-gui: remove warning when deleting correctly merged remote branch
git-gui: Added Greek translation & glossary
git-gui: display summary when showing diff of a submodule
When the main window is maximized, if the screen height is shorter (e.g.
Netbook screen 1024x600), both the partial commit pane and the status bar
are hidden. The diff pane is resizable, so that it can use less vertical
height, allowing the overall window to be shorter and still display both
the entire commit pane and status bar.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This feature is long overdue; convert SVN's merge representation to git's
as revisions are imported. This works by converting the list of revisions
in each line of the svn:mergeinfo into git revision ranges, and then
checking the latest of each of these revision ranges for A) being new and
B) now being completely merged.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Dump generated with SVN 1.5.1 (on lenny amd64). This test
should hopefully cover all but a few intermediate versions of
the svnmerge.py script.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
SVK is a simple case to start with, as its idea of merge parents
matches git's one. When a svk:merge ticket is encountered, check each
of the listed merged revisions to see if they are in the history of
this commit; if not, then we have encountered a merge - record it.
[ew: minor formatting cleanups]
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Possibly the 'perl' in the PATH is not the one to be used for the tests;
let PERL set in the environment select it.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Dump generated with SVK 2.0.2 and SVN 1.5.1 (on lenny amd64).
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14c.
Thanks to Daniel Cordero for the original bug report and
bisection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* jc/receive-pack-auto:
receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
gc --auto --quiet: make the notice a bit less verboase
GIT_DIFFTOOL_PROMPT doesn't have any effect if overridden with --prompt.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first argument of the tar command is interpreted as a bundle of
letters specifying the mode of operation and additional options, with
any option arguments taken from subsequent words on the command line
as needed. The implementation of tar in busybox treats this bundle
as if preceded by a dash and then parses it by getopt rules, which
mishandles 'tar xfo -'. Use 'tar xof -' instead to work this around.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes a regression introduce by d68dc34 (git-describe: Die early if
there are no possible descriptions, 2009-08-06).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The loop in get_size_from_delta() feeds a deflated delta data from the
pack stream _until_ we get inflated result of 20 bytes[*] or we reach the
end of stream.
Side note. This magic number 20 does not have anything to do with the
size of the hash we use, but comes from 1a3b55c (reduce delta head
inflated size, 2006-10-18).
The loop reads like this:
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
This git_inflate() can return:
- Z_STREAM_END, if use_pack() fed it enough input and the delta itself
was smaller than 20 bytes;
- Z_OK, when some progress has been made;
- Z_BUF_ERROR, if no progress is possible, because we either ran out of
input (due to corrupt pack), or we ran out of output before we saw the
end of the stream.
The fix b3118bd (sha1_file: Fix infinite loop when pack is corrupted,
2009-10-14) attempted was against a corruption that appears to be a valid
stream that produces a result larger than the output buffer, but we are
not even trying to read the stream to the end in this loop. If avail_out
becomes zero, total_out will be the same as sizeof(delta_head) so the loop
will terminate without the "fix". There is no fix from b3118bd needed for
this loop, in other words.
The loop in unpack_compressed_entry() is quite a different story. It
feeds a deflated stream (either delta or base) and allows the stream to
produce output up to what we expect but no more.
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR)
This _does_ risk falling into an endless interation, as we can exhaust
avail_out if the length we expect is smaller than what the stream wants to
produce (due to pack corruption). In such a case, avail_out will become
zero and inflate() will return Z_BUF_ERROR, while avail_in may (or may
not) be zero.
But this is not a right fix:
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
+ if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out)
+ break; /* wants more input??? */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR)
as Z_BUF_ERROR from inflate() may be telling us that avail_in has also run
out before reading the end of stream marker. In such a case, both avail_in
and avail_out would be zero, and the loop should iterate to allow the end
of stream marker to be seen by inflate from the input stream.
The right fix for this loop is likely to be to increment the initial
avail_out by one (we allocate one extra byte to terminate it with NUL
anyway, so there is no risk to overrun the buffer), and break out if we
see that avail_out has become zero, in order to detect that the stream
wants to produce more than what we expect. After the loop, we have a
check that exactly tests this condition:
if ((st != Z_STREAM_END) || stream.total_out != size) {
free(buffer);
return NULL;
}
So here is a patch (without my previous botched attempts) to fix this
issue. The first hunk reverts the corresponding hunk from b3118bd, and
the second hunk is the same fix proposed earlier.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the missing definite article ("the") in several places.
Change "note to..." to "note for...", since "note to" means that
that the note is addressed to someone (source: Google search).
Change "progressbar" to "progress bar" (source: Wikipedia).
Format git commands, options, and file names consistently using
back quotes (i.e. a fixed font in the resulting HTML document).
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
