If a user has customized format.pretty in config, git-svn rebase fails with:
Unable to determine upstream SVN information from working tree history
because the command expects to read the commit log in the default format.
This fixes the command to explicitly ask for the format it wants to read
from.
Signed-off-by: Pedro Melo <melo@simplicidade.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tagger is equal to the committer, not the author, so
GIT_COMMITTER_DATE is the right environment variable to use, not
GIT_AUTHOR_DATE.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Its documentation was removed by 6c96753 (Documentation/git-commit: rewrite
to make it more end-user friendly, 2006-12-08), even though it is referenced
from a few places, including builtin-commit.c (as part of the commentary in
the commit message template).
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This attached patch introduces a single bit "use_terminator" in "struct
rev_info", which is normally false (i.e. most formats use separator
semantics) but by flipping it to true, you can ask for terminator
semantics just like oneline format does.
The function get_commit_format(), which is what parses "--pretty=" option,
now takes a pointer to "struct rev_info" and updates its commit_format and
use_terminator fields. It used to return the value of type "enum
cmit_fmt", but all the callers assigned it to rev->commit_format.
There are only two cases the code turns use_terminator on. Obviously, the
traditional oneline format (--pretty=oneline) is one of them, and the new
case is --pretty=tformat:... that acts like --pretty=format:... but flips
the bit on.
With this, "--pretty=tformat:%H %s" acts like --pretty=oneline.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many other commands use the "no arguments" form to show a
list (e.g., git-branch, git-tag). While we did show all
remotes for just "git remote", we displayed a usage error
for "git remote show" with no arguments. This is
counterintuitive, since by giving it _more_ information, we
get _less_ result.
The usage model can now be thought of as:
- "git remote show <remote>": show a remote
- "git remote show": show all remotes
- "git remote": assume "show"; i.e., shorthand for "git remote show"
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, a fetch like:
git fetch git://some/url
would show no ref status output (just the object downloading
status, if there was any), leading to some confusion.
With this patch, we now show the usual ref table, with
remote refs going into FETCH_HEAD. Previously this output
was shown only if "-v"erbose was specified.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-fetch: fix status output when not storing tracking ref
core-tutorial.txt: Fix showing the current behaviour.
git-archive: ignore prefix when checking file attribute
Fix documentation syntax of optional arguments in short options.
There was code in update_local_ref for handling this case,
but it never actually got called. It assumed that storing in
FETCH_HEAD meant a blank peer_ref name, but we actually have
a NULL peer_ref in this case, so we never even made it to
the update_local_ref function.
On top of that, the display formatting was different from
all of the other cases, probably owing to the fact that
nobody had ever actually seen the output.
This patch harmonizes the output with the other cases and
moves the detection of this case into store_updated_refs,
where we can actually trigger it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.5.4:
core-tutorial.txt: Fix showing the current behaviour.
git-archive: ignore prefix when checking file attribute
Fix documentation syntax of optional arguments in short options.
The --root option from "git diff-tree" won't do nothing
when is given to commands like git-whatchanged or git-log,
because those always print the initial commit by default.
This fixes the tutorial explaining the function of the
log.showroot configuration variable.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ulrik Sverdrup noticed that git-archive doesn't correctly apply the attribute
export-subst when the option --prefix is given, too.
When it checked if a file has the attribute turned on, git-archive would try
to look up the full path -- including the prefix -- in .gitattributes. That's
wrong, as the prefix doesn't need to have any relation to any existing
directories, tracked or not.
This patch makes git-archive ignore the prefix when looking up if value of the
attribute export-subst for a file.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an argument for an option is optional, like in -n from git-tag,
puting a space between the option and the argument is interpreted
as a missing argument for the option plus an isolated argument.
Documentation now reflects the need to write the parameter following
the option -n, as in "git tag -nARG", for instance.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It disables git-gc --auto when you are running Linux and you are
not on AC.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If such a hook is available and exits with a non-zero status, then
git-gc --auto won't run.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we pick 'mi' between 'lo' and 'hi' at 50%, which was what the
simple binary search did, we are halving the search space
whether the entry at 'mi' is lower or higher than the target.
The previous patch was about picking not the middle but closer
to 'hi', when we know the target is a lot closer to 'hi' than it
is to 'lo'. However, if it turns out that the entry at 'mi' is
higher than the target, we would end up reducing the search
space only by the difference between 'mi' and 'hi' (which by
definition is less than 50% --- that was the whole point of not
using the simple binary search), which made the search less
efficient. And the risk of overshooting becomes very high, if
we try to be too precise.
This tweaks the selection of 'mi' to be a bit closer to the
middle than we would otherwise pick to avoid the problem.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of counting added and removed lines (and mixing the byte size
reported for binary files in the result), summarize the extent of damage
the same way as we count similarity for rename detection.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when looking for a packed object from the pack idx, a
simple binary search is used.
A conventional binary search loop looks like this:
unsigned lo, hi;
do {
unsigned mi = (lo + hi) / 2;
int cmp = "entry pointed at by mi" minus "target";
if (!cmp)
return mi; "mi is the wanted one"
if (cmp > 0)
hi = mi; "mi is larger than target"
else
lo = mi+1; "mi is smaller than target"
} while (lo < hi);
"did not find what we wanted"
The invariants are:
- When entering the loop, 'lo' points at a slot that is never
above the target (it could be at the target), 'hi' points at
a slot that is guaranteed to be above the target (it can
never be at the target).
- We find a point 'mi' between 'lo' and 'hi' ('mi' could be
the same as 'lo', but never can be as high as 'hi'), and
check if 'mi' hits the target. There are three cases:
- if it is a hit, we have found what we are looking for;
- if it is strictly higher than the target, we set it to
'hi', and repeat the search.
- if it is strictly lower than the target, we update 'lo'
to one slot after it, because we allow 'lo' to be at the
target and 'mi' is known to be below the target.
If the loop exits, there is no matching entry.
When choosing 'mi', we do not have to take the "middle" but
anywhere in between 'lo' and 'hi', as long as lo <= mi < hi is
satisfied. When we somehow know that the distance between the
target and 'lo' is much shorter than the target and 'hi', we
could pick 'mi' that is much closer to 'lo' than (hi+lo)/2,
which a conventional binary search would pick.
This patch takes advantage of the fact that the SHA-1 is a good
hash function, and as long as there are enough entries in the
table, we can expect uniform distribution. An entry that begins
with for example "deadbeef..." is much likely to appear much
later than in the midway of a reasonably populated table. In
fact, it can be expected to be near 87% (222/256) from the top
of the table.
This is a work-in-progress and has switches to allow easier
experiments and debugging. Exporting GIT_USE_LOOKUP environment
variable enables this code.
On my admittedly memory starved machine, with a partial KDE
repository (3.0G pack with 95M idx):
$ GIT_USE_LOOKUP=t git log -800 --stat HEAD >/dev/null
3.93user 0.16system 0:04.09elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+55588minor)pagefaults 0swaps
Without the patch, the numbers are:
$ git log -800 --stat HEAD >/dev/null
4.00user 0.15system 0:04.17elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+60258minor)pagefaults 0swaps
In the same repository:
$ GIT_USE_LOOKUP=t git log -2000 HEAD >/dev/null
0.12user 0.00system 0:00.12elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+4241minor)pagefaults 0swaps
Without the patch, the numbers are:
$ git log -2000 HEAD >/dev/null
0.05user 0.01system 0:00.07elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+8506minor)pagefaults 0swaps
There isn't much time difference, but the number of minor faults
seems to show that we are touching much smaller number of pages,
which is expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The presence of a .git directory used to be good enough evidence that
GIT-VERSION-GEN could use 'git describe' to get a version number. But
now .git might as well be a file so the test must be extended to cater for
such setups.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-submodule tries to detect 'active' submodules, it checks for the
existence of a directory named '.git'. This isn't good enough now that .git
can be a file pointing to the real $GIT_DIR so the tests are changed to
reflect this.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When .git in a submodule is a file, resolve_gitlink_ref() needs to pick up
the real GIT_DIR of the submodule from that file.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch allows .git to be a regular textfile containing the path of
the real git directory (prefixed with "gitdir: "), which can be useful on
platforms lacking support for real symlinks.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This expands on the previous patch, and allows "git add" to sanely handle
a filename that has changed case, keeping the case in the index constant,
and avoiding aliases.
In particular, if you have an index entry called "File", but the
checked-out tree is case-corrupted and has an entry called "file"
instead, doing a
git add .
(or naming "file" explicitly) will automatically notice that we have an
alias, and will replace the name "file" with the existing index
capitalization (ie "File").
However, if we actually have *both* a file called "File" and one called
"file", and they don't have the same lstat() information (ie we're on a
case-sensitive filesystem but have the "core.ignorecase" flag set), we
will error out if we try to add them both.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies the matching case of "I already have this file and it is
up-to-date" and makes it do the right thing in the face of
case-insensitive aliases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is immaterial on sane filesystems, but if you have a broken (aka
case-insensitive) filesystem, and the objective is to remove the file
'abc' and replace it with the file 'Abc', then we must make sure to do
the removal first.
Otherwise, you'd first update the file 'Abc' - which would just
overwrite the file 'abc' due to the broken case-insensitive filesystem -
and then remove file 'abc' - which would now brokenly remove the just
updated file 'Abc' on that broken filesystem.
By doing removals first, this won't happen.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we find an unexpected file, see if that filename perhaps exists in a
case-insensitive way in the index, and whether the file matches that. If
so, ignore it as a known pre-existing file of a different name.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
..and start using it for directory entry traversal (ie "git status" will
not consider entries that match an existing entry case-insensitively to
be a new file)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now nobody uses it, but "index_name_exists()" gets a flag so
you can enable it on a case-by-case basis.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows verify_absent() in unpack_trees() to use the hash chains
rather than looking it up using the binary search.
Perhaps more importantly, it's also going to be useful for the next phase,
where we actually start looking at the cache entry when we do
case-insensitive lookups and checking the result.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's really totally separate functionality, and if we want to start
doing case-insensitive hash lookups, I'd rather do it when it's
separated out.
It also renames "remove_index_entry()" to "remove_name_hash()", because
that really describes the thing better. It doesn't actually remove the
index entry, that's done by "remove_index_entry_at()", which is something
very different, despite the similarity in names.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of wasting space with whole integers for a single bit.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mk/unpack-careful:
t5300: add test for "index-pack --strict"
receive-pack: allow using --strict mode for unpacking objects
unpack-objects: fix --strict handling
t5300: add test for "unpack-objects --strict"
unpack-objects: prevent writing of inconsistent objects
* fl/send-email-outside:
send-email: Don't require to be called in a repository
Git.pm: Don't require repository instance for ident
Git.pm: Don't require a repository instance for config
var: Don't require to be in a git repository.
When using git-svn to follow only a single (empty) path per
svn-remote (i.e. not using --stdlayout), following the history
of a renamed path was broken in
c586879cdf.
This reverts the regression for the single (emtpy) path per
svn-remote case.
To avoid breaking the tests in a committed revision, this is an
addendum to a patch originally submitted by
Santhosh Kumar Mani <santhoshmani@gmail.com>:
> git-svn: add test for renamed directory fetch
>
> This test tries to fetch a directory which had renames in the
> history from a SVN repository.
[ew: unneccesary dependency on the starting an HTTP server
removed from Santhosh's original test.]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In commit 15387e3 (Test suite: reset TERM to its previous value after
testing., 2007-10-26), I added a workaround to reset TERM to its previous
value before the "test_done" at the end of "t7005-editor.sh" because
otherwise "test_done" would have printed the test result with a bad TERM
env variable (this resulted in output with no color on konsole).
But since commit c2116a1 (test-lib: fix TERM to dumb for test
repeatability, 2008-03-06), colored output is printed in a subshell with
TERM reset to its original value so the earlier workaround is not needed
anymore.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit 4be6096 (apply --unidiff-zero: loosen sanity checks for
--unidiff=0 patches, 2006-09-17) made match_beginning and match_end
computed incorrectly. If a hunk inserts at the beginning, old position
recorded at the hunk is line 0, and if a hunk changes at the beginning, it
is line 1. The new test added to t4104 exposes that the old code did not
insist on matching at the beginning for a patch to add a line to an empty
file.
An even older 65aadb9 (apply: force matching at the beginning.,
2006-05-24) was equally wrong in that it tried to take hints from the
number of leading context lines, to decide if the hunk must match at the
beginning, but we can just look at the line number in the hunk to decide.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With tcl/tk8.5 the lset command seems to behave differently. When
changing the background color through Edit->Preferences, the changes
are applied, but new dialogs, such as View->New view... barf with
Error: unknown color name "{#ffffff}"
Additionally when closing gitk, and starting it up again, a bad value
has been saved to ~/.gitk, preventing gitk from running properly; it
fails with
Error in startup script: unknown color name "{#ffffff}"
...
This commit fixes the problem by changing the color dialogs to pass
the empty string {} as the list index to choosecolor. This causes
the lset and lindex commands used by choosecolor to use and set the
whole variable (bgcolor, fgcolor or selectbgcolor) rather than
treating them as a 1-element list. Tested with tcl/tk8.4 and 8.5.
Dmitry Potapov reported this problem through
http://bugs.debian.org/472615
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
