The fn_table is used to record the result of earlier patch application in
case a hand-crafted input file contains multiple patches to the same file.
Both its string key (filename) and the contents are borrowed from "struct
patch" that represents the previous application in the same apply_patch()
call, and they do not leak, but the table itself was not freed properly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were all allocated in the heap by parsing the header parts of the
patch, but we did not bother to free them. Some used to share the memory
(e.g. copying def_name to old_name) so this is not just the matter of
adding three calls to free().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://github.com/git-l10n/git-po:
Add url of Swedish l10n team in TEAMS file
l10n: Review zh_CN translation for Git 1.7.10-rc1
Update Swedish translation (724t0f0u).
l10n: Update zh_CN translation for Git 1.7.10-rc1
l10n: Update git.pot (1 new message)
$COLUMNS must be unset to not interfere with the tests. The tests
already ignore the terminal size because output is redirected to a
file, but COLUMNS overrides terminal size detection and changes the
test output away from the standard 80.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Overall review of the zh_CN translation:
- Distinguish the translations of index and stage, though they are the
same thing.
- Many other fixes, e.g., add the lost periods at the end of translated
sentences.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
- Update for 1.7.10-rc1.
- Add a missing -e when generaring the "Untracked files" message.
- Fixed some wordings after playing with the localized version.
There's currently no way to suppress the informational
"deleted branch..." or "set up tracking..." messages. This
patch provides a "-q" option to do so.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like the "switched to..." message (which is already
suppressed by "-q"), this message is purely informational.
Let's silence it if the user asked us to be quiet.
This patch is slightly more than a one-liner, because we
have to teach create_branch to propagate the flag all the
way down to install_branch_config.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Each ref structure contains a "nonfastforward" field which
is set during push to show whether the ref rewound history.
Originally this was a single bit, but it was changed in
f25950f (push: Provide situational hints for non-fast-forward
errors) to an enum differentiating a non-ff of the current
branch versus another branch.
However, we never actually set the member according to the
enum values, nor did we ever read it expecting anything but
a boolean value. But we did use the side effect of declaring
the enum constants to store those values in a totally
different integer variable. The code as-is isn't buggy, but
the enum declaration inside "struct ref" is somewhat
misleading.
Let's convert nonfastforward back into a single bit, and
then define the NON_FF_* constants closer to where they
would be used (they are returned via the "int *nonfastforward"
parameter to transport_push, so we can define them there).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of the other options were included in the synopsis, so it makes
sense to include these as well.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lots of code in Git's configure.ac doesn't follow the typical formatting,
idioms and best practices for Autoconf input files. Improve the situation.
There are probably many more similar improvements to be done, but trying
to clump all of them in a single change would make it unreviewable, so we
content ourselves with a partial improvement.
This change is just cosmetic, and should cause no semantic change.
The most relevant of the changes introduced by this patch are:
- Do not add trailing '\' characters for line continuation where they
are not truly needed.
- In several (but not all) macro calls, properly quote the arguments.
- Few cosmetic changes in spacing and comments.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change is just cosmetic, and should cause no semantic change, nor
any change in the generated configure script.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way, no spurious comments nor whitespace will be propagated in the
generated configure script.
This change is a pure code movement (plus addition of a comment line).
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously GIT_EDITOR was not listed in git(1) "Environment Variables" section,
which could be very confusing to users. Include it in "other" subsection along
with a link to git-var(1), since that is the page that fully describes all
places where editor can be set and also their preference order.
Also, git-var(1) did not say that hardcoded fallback 'vi' may have been changed
at build time. A user could be puzzled if 'nano' pops up even when none of the
mentioned environment vars or config.editor are set. Clarify this.
Ideally, the build system should be changed to reflect the chosen fallback
editor when creating the man pages. Not sure if that is even possible though.
Signed-off-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An alphabetic ordered list (a.) is converted to numerical in
the man page (1.) so context comments naming 'a' were confusing,
fix that by not using ordered list notation for 'a' anb 'b' items.
Signed-off-by: Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If both la and context are zero at the start of the loop, la wraps around
and we end up reading from memory far away. Skip the loop in that case
instead.
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://ozlabs.org/~paulus/gitk:
gitk: Teach gitk to respect log.showroot
gitk: Add menu items for comparing a commit with the marked commit
gitk: Speed up resolution of short SHA1 ids
gitk: Use symbolic font names "sans" and "monospace" when available
gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields
gitk: Make "git describe" output clickable, too
gitk: Fix the display of files when filtered by path
gitk: Use a tabbed dialog to edit preferences
gitk: Use "gitk: repo-top-level-dir" as window title
In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development history in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.
"git log" learned to show the patch for the initial commit without requiring
--root command line option at 0f03ca9 (config option log.showroot to show
the diff of root commits, 2006-11-23).
Teach gitk to respect log.showroot.
[paulus@samba.org: Cleaned up the Tcl a bit, use --bool on the
git config call]
Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge-recursive detects renames so that if one side modifies
"foo" and the other side moves it to "bar", the modification
is applied to "bar". However, our rename detection is based
on content analysis, it can be wrong (i.e., two files were
not intended as a rename, but just happen to have the same
or similar content).
This is quite rare if the files actually contain content,
since two unrelated files are unlikely to have exactly the
same content. However, empty files present a problem, in
that there is nothing to analyze. An uninteresting
placeholder file with zero bytes may or may not be related
to a placeholder file with another name.
The result is that adding content to an empty file may cause
confusion if the other side of a merge removed it; your
content may end up in another random placeholder file that
was added.
Let's err on the side of caution and not consider empty
files as renames. This will cause a modify/delete conflict
on the merge, which will let the user sort it out
themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our rename detection is a heuristic, matching pairs of
removed and added files with similar or identical content.
It's unlikely to be wrong when there is actual content to
compare, and we already take care not to do inexact rename
detection when there is not enough content to produce good
results.
However, we always do exact rename detection, even when the
blob is tiny or empty. It's easy to get false positives with
an empty blob, simply because it is an obvious content to
use as a boilerplate (e.g., when telling git that an empty
directory is worth tracking via an empty .gitignore).
This patch lets callers specify whether or not they are
interested in using empty files as rename sources and
destinations. The default is "yes", keeping the original
behavior. It works by detecting the empty-blob sha1 for
rename sources and destinations.
One more flexible alternative would be to allow the caller
to specify a minimum size for a blob to be "interesting" for
rename detection. But that would catch small boilerplate
files, not large ones (e.g., if you had the GPL COPYING file
in many directories).
A better alternative would be to allow a "-rename"
gitattribute to allow boilerplate files to be marked as
such. I'll leave the complexity of that solution until such
time as somebody actually wants it. The complaints we've
seen so far revolve around empty files, so let's start with
the simple thing.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The read-cache implementation defines this static function,
but it is a generally useful concept in git. Let's give
the empty blob the same treatment as the empty tree,
providing both hex and binary forms of the sha1.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This macro already evaluates to the correct type, as it
casts the string literal to "unsigned char *" itself
(and callers who want the literal can use the _LITERAL
form).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Removing this function shortens the code and makes it easier to read.
Now all environment variables are set as part of procedural operation.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The system call to Git works the same whether or not ".exe" is
appended to "git". The extra code is not necessary.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adding the script directory to PATH is not needed. The script is
located at '$(git --exec-path)', which is already on the PATH.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prior to this commit, the script exited with an error whenever the
usage string was printed, regardless of the reason it was done. In
cases where usage was printed due to a user request (e.g. '-h'
option), the script should exit without error (exit 0).
This commit adds an argument to the usage function that allows the
exit code to be specified when the function is called.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit teaches difftool to handle the '--no-gui' option. This option
negates the existing '--gui' option. The last setting given on the command
line wins.
This allows a user to configure "[alias] mdt = difftool --gui", but still
have the ability to override the setting without error:
$ git mdt --no-gui
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace custom option/argument parser with standard Getopt::Long
module. This shortens the code and makes it easier to understand.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change "it's" to "its" where a possessive is intended. Also add two
missing "the" that were noticed by Ben Walton.
Signed-off-by: David Waitzman <djw@bbn.com>
Sometimes one wants to see the different between two commits that are
a long distance apart in the graph display. This is difficult to do
with the "Diff this -> selected" and "Diff selected -> this" menu
items because the need to maintain the selection means that one can't
use the find facilities or the reference list window to navigate from
one to the other.
This provides an alternative using the mark. Having found one commit,
one marks it with the "Mark this commit" menu item, then navigates to
the other commit and uses the new "Diff this -> marked commit" and/or
"Diff marked commit -> this" menu items.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Certain versions of zsh seems to treat
local var=()
as a function declaration, rather than an assignment of an empty array,
although its documentation does not suggest that this should be the case.
With zsh 4.3.15 on Fedora Core 15, this causes
__git_ps1 " (%s)"
to trigger an error message:
local:2: command not found: svn_url_pattern
when GIT_PS1_SHOWUPSTREAM="auto".
Signed-off-by: Alex Merry <dev@randomguy3.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though 1.7.9.x series does not open the editor by default
when merging in general, it does do so in one occassion: when
merging an annotated tag. And worse yet, there is no good way
for older scripts to decline this.
Backport the support for GIT_MERGE_AUTOEDIT environment variable
from 1.7.10 track to help those stuck on 1.7.9.x maintenance
track.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nelson Benitez Leon opened a discussion with a patch with this in the
note:
Hi, I was using git rebase -i for some time now and never occured to
me I could reorder the commit lines to affect the order the commits
are applied, learnt that recently from a git tutorial.
Nelson's patch was to stress the fact that the lines in the insn sheet can
be re-ordered in a much more verbose way. Let's add a one-liner reminder
and also remind that the lines in the insn sheet is read from top to
bottom, unlike the "git log" output.
Discussion-triggered-by: Nelson Benitez Leon
Signed-off-by: Junio C Hamano <gitster@pobox.com>
