The logic of git-show has remained largely unchanged since around
5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start
a revision walker with no_walk=1, look at its pending objects and
handle them one-by-one. For commits, this means stuffing them into a
new queue all alone, and running the walker.
Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came
along and set no_walk=0 whenever the user specifies a range. Which
appears to work fine, until you actually prod it hard enough, as the
preceding commit shows: UNINTERESTING commits will be marked as such,
but not walked further to propagate the marks.
Demonstrate this with the main tests of this patch: 'showing a range
walks (Y shape)'. The Y shape of history ensures that propagating the
UNINTERESTING marks is necessary to correctly exclude the main1
commit. The only example I could find actually requires that the
negative revisions are listed later, and in this scenario a dotted
range actually works. However, it is easy to find examples in git.git
where a dotted range is wrong, e.g.
$ git show v1.7.0..v1.7.1 | grep ^commit | wc -l
1297
$ git rev-list v1.7.0..v1.7.1 | wc -l
702
While there, also test a few other things that are not covered so far:
the -N way of triggering a range (added in 5853cae, DWIM 'git show -5'
to 'git show --do-walk -5', 2010-06-01), and the interactions of tags,
commits and ranges.
Pointed out by Dr_Memory on #git.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even with many new kinds of options, the command still takes the
single <tree> as the first argument.
Probably we would want to update the command to allow it to take
<tree>-ish at the end for consistency.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
verify_filename() can be called in two different contexts. Either we
just tried to interpret a string as an object name, and it fails, so
we try looking for a working tree file (i.e. we finished looking at
revs that come earlier on the command line, and the next argument
must be a pathname), or we _know_ that we are looking for a
pathname, and shouldn't even try interpreting the string as an
object name.
For example, with this change, we get:
$ git log COPYING HEAD:inexistant
fatal: HEAD:inexistant: no such path in the working tree.
Use '-- <path>...' to specify paths that do not exist locally.
$ git log HEAD:inexistant
fatal: Path 'inexistant' does not exist in 'HEAD'
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diagnose_invalid_sha1_path() is meant to be called to diagnose a
misspelt <treeish>:<pathname> when <pathname> does not exist in
<treeish>. However, the code may call it if <treeish>:<pathname> is
invalid (which triggers another call with only_to_die == 1), but for
another reason. This happens when calling e.g.
git log existing-file HEAD:existing-file
because existing-file is a path and not a revision, the code
verifies that the arguments that follow to be paths. This leads to
an incorrect message like "existing-file does not exist in HEAD",
even though the path exists in HEAD.
Check that the search for <pathname> in <treeish> fails before
triggering the diagnosis.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option to autosquash is only used in case of an interactive rebase.
When merges are preserved, rebase uses an interactive rebase internally,
but in this case autosquash should still be disabled.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not mix byte and line counts. Binary files have byte counts;
skip them when accumulating line insertions/deletions.
The regression was introduced in e18872b.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no point in running a pager when --quiet is given,
since we are producing no output. The regular diff code path
handles this already, because --quiet implies --exit-code,
and we check for --exit-code when deciding not to run the
pager.
However, the "quiet implies exit-code" logic is done in
diff_setup_done, and the no-index code path sets up its
pager before running diff_setup_done, and misses this case.
We can fix this by reordering our initialization.
Currently we do:
1. read command line arguments into diff_options
2. Set pager if EXIT_CODE not requested
3. always set EXIT_CODE, since we are emulating
traditional diff
4. call diff_setup_done
We can fix the problem by moving pager initialization (step
2) after step 4. But step 3 must come after step 2 (since we
want to know whether the _user_ requested --exit-code, not
whether we turned it on unconditionally). So we must move
both.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-diff does not rely on the git wrapper to setup its
pager; instead, it sets it up on its own after seeing
whether --quiet or --exit-code has been specified. After
diff_no_index was split off from cmd_diff, commit b3fde6c
(git diff --no-index: default to page like other diff
frontends, 2008-05-26) duplicated the one-liner from
cmd_diff to turn on the pager.
Later, commit 8f0359f (Allow pager of diff command be
enabled/disabled, 2008-07-21) taught the the version in
cmd_diff to respect the pager.diff config, but the version
in diff_no_index was left behind. This meant that
git -c pager.diff=0 diff a b
would not use a pager, but
git -c pager.diff=0 diff --no-index a b
would. Let's fix it by factoring out a common function.
While we're there, let's update the antiquated comment,
which claims that the pager interferes with propagating the
exit code; this has not been the case since ea27a18 (spawn
pager via run_command interface, 2008-07-22).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
v1.7.11-rc1~12^2~2 (2012-05-27) and friends split some git-svn code
into separate modules but did not update the fallback rules to install
them when NO_PERL_MAKEMAKER is set. Add the appropriate rules so
users without MakeMaker can use git-svn again.
Affected modules: Git::SVN::Prompt, Git::SVN::Fetcher,
Git::SVN::Editor, Git::SVN::Ra, Git::SVN::Memoize::YAML.
Reported-by: Adam Roben <adam@roben.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmali.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adding or removing a module requires modifying both files to support
builds with and without MakeMaker. Add a comment to remind patch
authors and reviewers at the crucial moment.
Longer term, it would be nicer to maintain a single list, perhaps in a
separate file used by both build systems.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When given a set of commits, cherry-pick will apply the changes for
all of them. Specifying a simple range will also work as expected.
This can lead the user to think that
git cherry-pick A B..C
may apply A and then B..C, but that is not what happens.
Instead the revs are given to a single invocation of rev-list, which
will consider A and C as positive revs and B as a negative one. The
commit A will not be used if it is an ancestor of B.
Add a note about this and add an example with this particular
syntax, which has shown up on the list a few times.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing description can be misleading and cause the reader to
think that --no-walk will do something if they specify a range in the
command line instead of a set of revs.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git-blame-filter and git-blame-create-overlay we want to save
(along with the values of point and mark) the current-buffer in scope
when calling the functions. The idiom
(save-excursion
(set-buffer buf)
...)
will correctly restore the correct buffer, but will not save the
values of point and mark in buf (only in the buffer current when the
save-excursion call is executed). The intention of these functions is
to save the current buffer from the calling scope and the values of
point and mark in the buffer they are modifying. The correct idiom
for this is
(with-current-buffer buf
(save-excursion
...))
Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
goto-line is a user-level command, instead use the lisp-level
construct recommended in Emacs documentation.
Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Lawrence Mitchell <wence@gmx.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The simplify_merges() function needs to look at all history chain to
find the closest ancestor that is relevant after the simplification,
but after --first-parent traversal, side parents haven't been marked
for relevance (they are irrelevant by definition due to the nature
of first-parent-only traversal) nor culled from the parents list of
resulting commits.
We cannot simply remove these side parents from the parents list, as
the output phase still wants to see the parents. Instead, teach
simplify_one() and its callees to ignore the later parents.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we encounter an address part shaped like "[HOST]:PORT", we skip the opening
bracket and replace the closing one with a NUL. The variable host then points
to HOST and we've cut off the PORT part. Thus, when we go looking for it using
host a bit later, we can't find it. Start at end instead, which either points
to the colon, if present, or is equal to host.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
POSIX.1 (pax) is pretty clear on this:
The chksum field shall be the ISO/IEC 646:1991 standard IRV
representation of the octal value of the simple sum of all octets
in the header logical record. Each octet in the header shall be
treated as an unsigned value. These values shall be added to an
unsigned integer, initialized to zero, the precision of which is
not less than 17 bits. When calculating the checksum, the chksum
field is treated as if it were all <space> characters.
so is GNU:
http://www.gnu.org/software/tar/manual/html_node/Checksumming.html
Found by 7zip folks and reported by Rafał Mużyło.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 7f02f3d7 (completion: rename internal helpers _git and _gitk,
2012-05-19) renamed said functions to _main_git() and _main_gitk(),
respectively. By convention the name of our git-completion-specific
functions start with '_git' or '__git' prefix, so rename those
functions once again to put them back into our "namespace". Use the
two underscore prefix, because _git_main() could be mistaken for the
completion function of the (not yet existing) 'git main' command.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The If-Modified-Since support in Gitweb is conditional on the
availability of a date parser from either the HTTP::Date or
Time::ParseDate modules. If a suitable parser is not available,
then the corresponding 'modification times' tests should be skipped.
Introduce the DATE_PARSER test prerequisite and use it to skip
all of the dependent tests.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GIT-BUILD-OPTIONS defines PERL_PATH to be used in the test suite. Only a
few tests already actually use this variable when perl is needed. The
other test just call 'perl' and it might happen that the wrong perl
interpreter is used.
This becomes problematic on Windows, when the perl interpreter that is
compiled and installed on the Windows system is used, because this perl
interpreter might introduce some unexpected LF->CRLF conversions.
This patch makes sure that $PERL_PATH is used everywhere in the test suite
and that the correct perl interpreter is used.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tone down the lines that credit people involved and make them
comments, so that integrators who edit their merge messages can
still make use of the information, but lazy ones will not leave
the unverified guesses placed on the "via" line.
* jc/fmt-merge-msg-people:
fmt-merge-msg: make attribution into comment lines
It was unclear whether the field was to be specified by the user of the
API.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cc: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In commit e01105 Linus introduced gitlinks to update-index. He explains
that he thinks it is not the right thing to replace a gitlink with
something else.
That commit is from the very first beginnings of submodule support.
Since then we have gotten a lot closer to being able to remove a
submodule without losing its history. This check prevents such a use
case, so I think this assumption has changed.
Additionally in the git add codepath we do not have such a check, so for
consistency reasons I think removing this check is the correct thing to
do.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every "git svn fetch".
These caches use the 'nstore' format from the perl core module
Storable, which can be read and written quickly and was designed for
transfer over the wire (the 'n' stands for 'network'). This format is
endianness-independent and independent of floating-point
representation.
Unfortunately the format is *not* independent of the perl version ---
new perl versions will write files that very old perl cannot read.
Worse, the format is not independent of the size of a perl integer.
So if you toggle perl's use64bitint compile-time option, then using
'git svn fetch' on your old repositories produces errors like this:
Byte order is not compatible at ../../lib/Storable.pm (autosplit
into ../../lib/auto/Storable/_retrieve.al) line 380, at
/usr/share/perl/5.12/Memoize/Storable.pm line 21
That is, upgrading perl to a version that uses use64bitint for the
first time makes git-svn suddenly refuse to fetch in existing
repositories. Removing .git/svn/.caches lets git-svn recover.
It's time to switch to a platform independent serializer backend with
better compatibility guarantees. This patch uses YAML::Any.
Other choices were considered:
- thawing data from Data::Dumper involves "eval". Doing that without
creating a security risk is fussy.
- the JSON API works on scalars in memory and doesn't provide a
standard way to serialize straight to disk.
YAML::Any is reasonably fast and has a pleasant API. In most
backends, LoadFile() reads the entire file into a scalar anyway and
converts it as a second step, but having an interface that allows the
deserialization to happen on the fly without a temporary is still a
comfort.
YAML::Any is not a core perl module, so we take care to use it when
and only when it is available. Installations without that module
should fall back to using Storable with all its quirks, keeping their
cache files in
.git/svn/.caches/*.db
Installations with YAML peacefully coexist by keeping a separate set
of cache files in
.git/svn/.caches/*.yaml.
In most cases, switching between is a one-time thing, so it doesn't
seem worth the complication to migrate existing caches.
The upshot: after this patch, as long as YAML::Any is installed you
can move your git repository between machines with different perl
installations and "git svn fetch" will work fine. If you do not have
YAML::Any, the behavior is unchanged (and in particular does not get
any worse).
Reported-by: Sandro Weiser <sandro.weiser@informatik.tu-chemnitz.de>
Reported-by: Bdale Garbee <bdale@gag.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This slices off another 600 or so lines from the frighteningly long
git-svn.perl script.
The Git::SVN::Ra interface is similar enough to SVN::Ra that it is
probably safe to ignore most of its implementation on first reading.
(Documenting or moving functions that do not fit that pattern is left
as an exercise to the interested reader.)
[ew: rebased and fixed conflict against
commit c26ddce86d
(git-svn: platform auth providers are working only on 1.6.15 or newer)]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This makes the git-svn script shorter and less scary for beginners to
read through for the first time. Take the opportunity to explain the
purpose and basic interface of the Git::SVN::Editor class while at it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using mapcar here is a waste of memory because the mapped result
is not used.
Noticed by emacs ("Warning: `mapcar' called for effect").
[jn: split from a larger patch, with new description]
Signed-off-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Among the three similar-looking loops that walk singly linked
commit_list, the first one is only peeking and the same list is
later used for real work. Leave a comment not to mistakenly
free its elements there.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code internally runs sort_in_topo_order() already; it is more clear
to spell it out in the option parsing phase, instead of adding a special
case in simplify_merges() function.
