This patch arose from a discussion started by Jim Meyering's patch
whose intention was to provide better diagnostics for failed writes.
Linus proposed a better way to do things, which also had the added
benefit that adding a fflush() to git-log-* operations and incremental
git-blame operations could improve interactive respose time feel, at
the cost of making things a bit slower when we aren't piping the
output to a downstream program.
This patch skips the fflush() calls when stdout is a regular file, or
if the environment variable GIT_FLUSH is set to "0". This latter can
speed up a command such as:
GIT_FLUSH=0 strace -c -f -e write time git-rev-list HEAD | wc -l
a tiny amount.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This switches the checks around upon the exit codepath of the
git wrapper, so that we may recover at least non-transient errors.
It's still not perfect. As I've been harping on, stdio simply isn't very
good for error reporting. For example, if an IO error happened, you'd want
to see EIO, wouldn't you? And yes, that's what the kernel would return.
However, with buffered stdio (and flushing outside of our control), what
would likely happen is that some intermediate error return _does_ return
EIO, but then the kernel might decide to re-mount the filesystem read-only
due to the error, and the actual *report* for us might be
"write failure on standard output: read-only filesystem"
which lost the EIO.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'show' and 'prune' commands accept an option '-n'; document what
it does.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some minor enhancements to the git-repack manual page.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This stop git-tag from emitting a "shift: can't shift that many"
error, when listing tags.
[jc: with further fixups from Sam Vilain merged in; it passes
the tests under dash now]
Signed-off-by: Alexandre Vassalotti <alexandre@peadrop.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both `git-tag -l` and `git tag -v` fail on Mac OS X due to their
non-standard uses of sed. Actually `git tag -v` fails because the
underlying git-tag-verify uses a non-standard sed command.
We now stick to only standard sed, which does make our sed scripts
slightly more complicated, but we can actually list tags with more
than 0 lines of additional context and we can verify signed tags
with gpg. These major Git functions are much more important than
saving two or three lines of a simple sed script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require $DISPLAY just to get --version
git-gui: Quiet our installation process
git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
git-gui: Correctly install to /usr/bin on Cygwin
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require $DISPLAY just to get --version
git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
git-gui: Correctly install to /usr/bin on Cygwin
It fixes the test on system where ActiveState Perl is used.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When creating a brand new git repository through git-cvsimport (not
incremental import), force a checkout of HEAD of master as working tree
after successful import using the -f switch to git checkout. Otherwise
the working tree is empty, and all files are reported as 'deleted' by
git status.
This was noticed and reported by Cameron Dale through
http://bugs.debian.org/430903
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests are useful to develop the C version for git-tag.sh,
ensuring that the future builtin-tag.c will not break previous
behaviour.
The tests are focused on listing, verifying, deleting and creating
tags, checking always that the correct status value is returned
and everything remains as expected.
In order to verify and create signed tags, a PGP key was also
added, being created this way: gpg --homedir t/t7004 --gen-key
Type DSA and Elgamal, size 2048 bits, no expiration date.
Name and email: C O Mitter <committer@example.com>
No password given, to enable non-interactive operation.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This defines xdup() and xfdopen() in git-compat-util.h to give
us error-catching variants of them without cluttering the code
too much.
Signed-off-by: Jim Meyering <jim@meyering.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change makes git-send-email's behavior easier to modify by adding config
equivalents for two more of git-send-email's flags.
The mapping of flag to config setting is:
--[no-]supress-from => sendemail.suppressfrom
--[no-]signed-off-cc => sendemail.signedoffcc
It renames the --threaded option to --thread/--no-thread; the
config variable is also called sendemail.thread.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Update selection background colorbar in prefs dialog
gitk: Use a spinbox for setting tabstop settings
The callback function was incorrectly set to update the background
colorbar when updated the selection background. This did not affect the
colors chosen or their use, just their presentation in the preferences
dialog box.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
The tabstop must be a smallish positive integer, and a spinbox is the
accepted UI control to accomplish this limiting rather than the text
entry box previously used.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
These tests check some features that git-stripspace already has
and those that it should manage well: Removing trailing spaces
from lines, removing blank lines at the beginning and end,
unifying multiple lines between paragraphs, doing the correct
when there is no newline at the last line, etc.
It seems that the implementation needs to save the whole line
in memory to be able to manage correctly long lines with
text and spaces conveniently distribuited on them.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --threaded option controls whether the In-Reply-To header will be set on
any emails sent. The current behavior is to always set this header, so this
option is most useful in its negated form, --no-threaded. This behavior can
also be controlled through the 'sendemail.threaded' config setting.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now the implementation gets more memory to store completely
each line before removing trailing spaces, and does it right
when the last line of the file ends with spaces and no newline
at the end.
Function stripspace needs again to be non-static in order to call
it from "builtin-tag.c" and the upcoming "builtin-commit.c".
A new parameter skip_comments was also added to the stripspace
function to optionally strips every shell #comment from the input,
needed for doing this task on those programs.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, if the size of refs_file at that point is ever an exact
multiple of BUFSIZ, then an EIO or ENOSPC error on the final write would
not be diagnosed.
It's not worth worrying about EPIPE here.
Although theoretically possible that someone kill this process
with a manual SIGPIPE, it's not at all likely.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I audited git for potential undetected write failures.
In the cases fixed below, the diagnostics I add mimic the diagnostics
used in surrounding code, even when that means not reporting
the precise strerror(errno) cause of the error.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require $DISPLAY just to get --version
The Tools/Migrate menu option is a hack just for me. Yes, that's
right, git-gui has a hidden feature that really only works for me,
and the users that I support within my day-job's great firewall.
The menu option is not supported outside of that environment.
In the past we only enabled Tools/Migrate if our special local
script 'gui-miga' existed in the proper location, and if there
was a special '.pvcsrc' in the top level of the working directory.
This latter test for the '.pvcsrc' file is now failing, as the file
was removed from all Git repositories due to changes made to other
tooling within the great firewall's realm.
I have changed the test to only work on Cygwin, and only if the
special 'gui-miga' is present. This works around the configuration
changes made recently within the great firewall's realm, but really
this entire Tools/Migrate thing should be abstracted out into some
sort of plugin system so other users can extend git-gui as they need.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt reported that MinGW/MSYS does not have a nice.exe to
drop the priority of a child process when it gets spawned. So we
have to avoid trying to start `git blame` through nice when we are
on Windows and do not have Cygwin available to us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Use \n as delimiter between key and value and \0 as
delimiter after each key/value pair. This should be
easily parsable output.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Print no space after the name of a key without value.
Otherwise keys without values are printed exactly the
same as keys with empty values.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The asciidoc documentation of the --get-regexp option was
incomplete. Add some missing pieces:
- List the option in SYNOPSIS
- Mention that key names are printed
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a picture, and keep the setup and the tests together.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
RPM build broke with "File not found" error on git-gui.1 and git-citool.1
They actually are git-gui.1.gz and git-citool.1.gz
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A pack-file can get created without any objects in it (to transfer "no
data" - which can happen if you use a reference git repo, for example,
or just otherwise just end up transferring only branch head information
and already have all the objects themselves).
And while we probably should never create an index for such a pack, if we
do (and we do), the index file size sanity checking was incorrect.
This fixes it.
Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch, the code would look for the submodule
commits in the superproject and (needlessly) fail when it
couldn't find them.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk: (21 commits)
gitk: Add a progress bar to show progress while resetting
gitk: Improve handling of whitespace and special chars in filenames
gitk: Fix bug causing nearby tags/heads to sometimes not be displayed
gitk: Limit how often we change the canvas scrolling region
gitk: Add a "reset branch to here" row context-menu operation
gitk: Get rid of the childlist variable
gitk: Speed up the reading of references
gitk: Show local uncommitted changes as a fake commit
gitk: New algorithm for drawing the graph lines
gitk: Store ids in rowrangelist and idrowranges rather than row numbers
gitk: Disable the head context menu entries for the checked-out branch
gitk: Cope with commit messages with carriage-returns and initial blank lines
gitk: Implement a simple scheduler for the compute-intensive stuff
gitk: Improve the behaviour of the initial selection
gitk: Add some more comments to the optimize_rows procedure
gitk: Don't try to list large numbers of tags or heads in the details pane
gitk: New infrastructure for working out branches & previous/next tags
[PATCH] gitk: Allow specifying tabstop as other than default 8 characters.
[PATCH] gitk: Update fontsize in patch / tree list
[PATCH] gitk: Make selection highlight color configurable
...
Conflicts:
gitk
Since git reset now gets chatty while resetting, we were getting errors
reported when a reset was done using the "reset branch to here" menu
item. With this we now read the progress messages from git reset and
update a progress bar. Because git reset outputs the progress messages
to standard error, and Tcl treats messages to standard error as error
messages, we have to invoke git reset via a shell and redirect standard
error into standard output.
This also fixes a bug in computing descendent heads when head ids
are changed via a reset.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is trying to implement the strict IO error checks that Jim Meyering
suggested, but explicitly limits it to just regular files. If a pipe gets
closed on us, we shouldn't complain about it.
If the subcommand already returned an error, that takes precedence (and we
assume that the subcommand already printed out any relevant messages
relating to it)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should change no code at all, it just moves the definition of "struct
cmd_struct" out, and then splits out the running of the right command into
the "run_command()" function.
It also removes the long-unused 'envp' pointer passing.
This is just preparation for adding some more error checking.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using `git push origin +foo` to forcefully overwrite the remote
branch named foo is a common idiom, especially since + is shorter
than the long option --force and can be specified on a per-branch
basis.
We now complete `git push origin +foo` just like we do the standard
`git push origin foo`. The leading + on a branch refspec does not
alter the completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the original $from address fails to yield a valid-looking
e-mail address, we created a bogus looking message ID, formatted
like this:
Message-Id: <11823357623688-git-send-email->
This commit fixes it by moving call to make_message_id() to
where it matters, namely, before the $message_id is needed to be
placed in the generated e-mail header; this has an important
side effect of making it clear that $from is already available.
Also throw in Sys::Hostname::hostname() just for fun, although I
suspect that the code would never trigger due to the modified
call sequence that makes sure $from is always available. This
is based on a suggestion by Michael Hendricks.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make clear in the documentation that when using --branches/-b and
--prefix with 'init', the prefix must include a trailing slash.
This matches the actual behavior of git-svn, e.g.:
$ git svn init -Ttrunk -treleases -bbranches --prefix xxx \
http://svn.sacredchao.net/svn/quodlibet/
--prefix='xxx' must have a trailing slash '/'
$
This was noticed by R. Vanicat and reported through
http://bugs.debian.org/429443
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-parse --git-dir outputs a full path - except for the single case
of when the path would be $(pwd)/.git, in which case it outputs simply
.git. Check for this special case and handle it.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Theodore Ts'o
Junio C Hamano
Linus Torvalds
Matt Kraai
Sam Vilain
Alexandre Vassalotti
Shawn O. Pearce
Alex Riesen
Gerrit Pape
Carlos Rica
Jim Meyering
Adam Roben
Mark Levedahl
Frank Lichtenheld
Simon Hausmann
Quy Tonthat
Sven Verdoolaege
Paul Mackerras
Julian Phillips
Matthias Lederhofer