Local change analysis can take a noticeable amount of time on large
file sets, and produce no output if there are no changes. Register
the back-ends in commfd, so that they get properly killed on window
close.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When collecting commits for a rarely changed, or recently
created file or directory, rev-list may work for a noticeable
period of time without producing any output. Such processes
don't receive SIGPIPE for a while after gitk is closed, thus
becoming runaway CPU hogs.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When the SYNOPSIS says e.g. "<path>...", it is nice if the DESCRIPTION
also mentions "<path>..." and says the specified "paths" (note plural)
are used for $whatever. This fixes the obvious mismatches.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since version 1.5.6 "git bisect" doesn't use a "bisect" branch any
more, but the user manual had not been updated to reflect this.
So this patch does that and while at it also adds a few words about
"git bisect skip" and points user to the "git bisect" man page for
more information.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cmd_help() is called, we always need the list of main and other
commands, not just when the list of all commands is shown. Before this
patch 'git help diff' invoked 'man gitdiff' because cmd_to_page()
thought 'diff' is not a git command.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OPT_INTEGER() works on an integer, not on an unsigned long. On a big
endian architecture with long larger than int, integer test gives bogus
results because of this bug.
Reported by H.Merijn Brand in HP-UX 64-bit environment.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When merging an early part of a branch, e.g. "git merge xyzzy~20", we were
supposed to say "branch 'xyzzy' (early part)", but it incorrectly said
"branch 'refs/heads/xy' (early part)" instead.
The logic was supposed to first strip away "~20" part to make sure that
what follows "~" is a non-zero posint, prefix it with "refs/heads/" and
ask resolve_ref() if it is a ref. If it is, then we know xyzzy was a
branch, and we can give the correct message.
However, there were a few bugs. First of all, the logic to build this
"true branch refname" did not count the characters correctly. At this
point of the code, "len" is the number of trailing, non-name part of the
given extended SHA-1 expression given by the user, i.e. number of bytes in
"~20" in the above example.
In addition, the message forgot to skip "refs/heads/" it prefixed from the
output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suppose you have this topology, and you are trying to make an octopus
across A, B and C (you are at C and merging A and B into your branch).
The protoccol between "git merge" and merge strategies is for the former
to pass common ancestor(s), '--' and then commits being merged.
git-merge-octopus does not produce the final merge in one-go. It
iteratively produces pairwise merges. So the first step might be to come
up with a merge between B and C:
o---o---o---o---C
/ :
/ o---o---o---B..(M)
/ /
---1---2---o---o---o---A
and for that, "1" is used as the merge base, not because it is the base
across A, B and C but because it is the base between B and C. For this
merge, A does not matter.
I drew M in parentheses and lines between B and C to it in dotted line
because we actually do _not_ create a real commit --- the only thing we
need is a tree object, in order to proceed to the next step.
Then the final merge result is obtained by merging tree of (M) and A using
their common ancestor. For that, we _could_ still use "1" as the merge
base.
But if you imagine a case where you started from A and M, you would _not_
pick "1" as the merge base; you would rather use "2" which is a better
base for this merge.
That is why git-merge-octopus ignores the merge base given by "merge" but
computes its own.
The comment at the end of git-merge-octopus talks about "merge reference
commit", that we used to update it to common found in this round, and that
that updating was pointless. After the first round of merge to produce
the tree for M (but without actually creating the commit object M itself),
in order to figure out the merge base used to merge that with A in the
second round, we used to use A and "1" (which was merge base between B and
C). That was pointless --- "merge-base A 1" is guaranteed to give a base
that is no better than either "merge-base A B" or "merge-base A C". So
the current code keeps using the original head (iow, MRC=C, because in
this case we are starting from C and merging B and then A into it).
This trickerly was necessary only because we avoided creating the extra
merge commit object M.
Side note. An alternative implementation could have been to
actually record it as a real merge commit M, and then let the
two-commit merge-base compute the base between A and M when
merging A to the result of the previous round, but we avoided
creating M, at the expense of potentially using suboptimal base in
the later rounds.
But we do not have to be that pessimistic. We can instead accumulate the
commits we have merged so far in MRC, and have merge_bases_many() compute
the merge base for the new head being merged and the heads we have
processed so far, which can give a better base than what we currently do.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://repo.or.cz/git-gui:
git-gui (Windows): Change wrapper to execdir 'libexec/git-core'
git-gui (Windows): Switch to relative discovery of oguilib
git-gui: Correct installation of library to be $prefix/share
git-gui: Fix gitk search in $PATH to work on Windows
git-gui: Preserve scroll position on reshow_diff.
git-gui: Fix the Remote menu separator.
Convert git archive to parse_options(). The parameters --remote and --exec
are still handled by their special parser. Define them anyway in order for
them to show up in the usage notice.
Note: in a command like "git archive --prefix --remote=a/ HEAD", the string
"--remote=a/" will be interpreted as a remote option, not a prefix, because
that special parser sees it first. If one needs such a strange prefix, it
needs to be specified like this: "git archive --prefix=--remote=a/ HEAD"
(with an equal sign).
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ie_modified() function is the workhorse for refresh_cache_entry(),
i.e. checking if an index entry that is stat-dirty actually has changes.
After running quicker check to compare cached stat information with
results from the latest lstat(2) to answer "has modification" early, the
code goes on to check if there really is a change by comparing the staged
data with what is on the filesystem by asking ce_modified_check_fs().
However, this function always said "no change" for any gitlinks that has a
directory at the corresponding path. This made ie_modified() to miss
actual changes in the subproject.
The patch fixes this first by modifying an existing short-circuit logic
before calling the ce_modified_check_fs() function. It knows that for any
filesystem entity to which ie_match_stat() says its data has changed, if
its cached size is nonzero then the contents cannot match, which is a
correct optimization only for blob objects. We teach gitlink objects to
this special case, as we already know that any gitlink that
ie_match_stat() says is modified is indeed modified at this point in the
codepath.
With the above change, we could leave ce_modified_check_fs() broken, but
it also futureproofs the code by teaching it to use ce_compare_gitlink(),
instead of assuming (incorrectly) that any directory is unchanged.
Originally noticed by Alex Riesen on Cygwin.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This treats aborting a commit more like a feature.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although it does not matter for Git itself, tools that
export to systems that explicitly track copies and
renames can benefit from such information.
This patch makes fast-export output correct action
logs when -M or -C are enabled.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This one tests '-s index' which is interesting because git-merge-index
is an existing git command but it is not a valid strategy.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Testing is done by creating a simple git-merge-theirs strategy which is
the opposite of ours. Using this in real merges is not recommended but
it's perfect for our testing needs.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow using a custom strategy, as long as it's named git-merge-foo. The
error handling is now done using is_git_command(). The list of available
strategies is now shown by list_commands().
If an invalid strategy is supplied, like -s foobar, then git-merge would
list all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are removed from the output by scanning the list of main commands;
if the git-merge-foo command is listed in the all_strategy list, then
it's shown, otherwise excluded. This does not exclude commands somewhere
else in the PATH, where custom strategies are expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make load_command_list() capable of filtering for a given prefix and
loading into a pair of "struct cmdnames" supplied by the caller.
Make the static add_cmdname(), exclude_cmds() and is_in_cmdlist()
functions non-static.
Make list_commands() accept a custom title, and work from a pair of
"struct cmdnames" supplied by the caller.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes two small changes to improve the output of --inline
and --attach.
The first is to write a newline preceding the boundary. This is needed because
MIME defines the encapsulation boundary as including the preceding CRLF (or in
this case, just LF), so we should be writing one. Without this, the last
newline in the pre-diff content is consumed instead.
The second change is to always write the line termination character
(default: newline) even when using --inline or --attach. This is simply to
improve the aesthetics of the resulting message. When using --inline an email
client should render the resulting message identically to the non-inline
version. And when using --attach this adds a blank line preceding the
attachment in the email, which is visually attractive.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svnimport is no longer supported, so don't mention it in the
documentation. This also updates the description, removing the
historical discussion, since it mostly dealt with how it differed from
svnimport. The new description gives some starting points into the
rest of the documentation.
Noticed by Jurko Gospodnetić <jurko.gospodnetic@docte.hr>
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though the underlying function for get_merge_bases() can compute
a merge base between one existing commit and another (possibly
nonexistent) commit that would be created by merging many commits,
the facility was not available to git-merge-base.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui needs bindir in PATH to be able to run 'git'. bindir
however is not necessarily in PATH if started directly through a
Windows shortcut. Therefore, we used to add the directory
git-gui is located in. But with the new 'libexec/git-core'
layout this directory is no longer identical to bindir.
This commit modifies the wrapper script to discover the bindir
and add it to PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Instead of using an absolute path, git-gui can discover its
gui library using a relative path from execdir. We want to
use the relative path discovery on MinGW to avoid issues
with translation of absolute paths.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We always wanted the library for git-gui to install into the
$prefix/share directory, not $prefix/libexec/share. All of
the files in our library are platform independent and may
be reused across systems, like any other content stored in
the share directory.
Our computation of where our library should install to was broken
when git itself started installing to $prefix/libexec/git-core,
which was one level down from where we expected it to be.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Back in 15430be5a1 ("Look for gitk in $PATH, not $LIBEXEC/git-core")
git-gui learned to use [_which gitk] to locate where gitk's script
is as Git 1.6 will install gitk to $prefix/bin (in $PATH) and all
of the other tools are in $gitexecdir.
This failed on Windows because _which adds the ".exe" suffix as it
searches for the program on $PATH, under the assumption that we can
only execute something from Tcl if it is a proper Windows executable.
When scanning for gitk on Windows we need to omit the ".exe" suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A new configuration variable 'core.trustctime' is introduced to
allow ignoring st_ctime information when checking if paths
in the working tree has changed, because there are situations where
it produces too much false positives. Like when file system crawlers
keep changing it when scanning and using the ctime for marking scanned
files.
The default is to notice ctime changes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch "git merge-base" just exited with error code 1
and without an error message in case it was passed a ref to an
object that is not a commit (for example a tree).
This patch makes it "die" in this case with an error message.
While at it, this patch also refactors the code to get the
commit reference from an argument into a new
"get_commit_reference" function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test assumed that we can keep the cached stat information fresh across
rename(2); many filesystems however update st_ctime (and POSIX allows them
to do so), and that assumption does not hold.
We can explicitly refresh the index for the purpose of these tests. The
only thing we are interested in is the staged contents and the mode bits
are preserved across "git mv".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We prefer running the dashless form, and POSIX side already does so; we
should use it in MinGW's start_command(), too.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
prepare_git_cmd(const char **argv) adds a first entry "git" to
the array argv. The new array is allocated on the heap. It's
the caller's responsibility to release it with free(). The code
was already present in execv_git_cmd() but could not be used from
outside. Now it can also be called for preparing the command list
in the MinGW codepath in run-command.c.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the C rewrite, "git verify-tag -v" just does nothing instead of
printing the usage message with an error. This patch fix the regression.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When run in a working copy subdirectory, git-ls-tree will automagically
add the prefix to the pathspec, which can result in an unexpected behavior
when the tree object accessed is not the root tree object.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In an earlier commit c70a8d9 (Makefile: Do not install a copy of 'git' in
$(gitexecdir), 2008-07-21), we tried to avoid installing two git, one in
/usr/bin/git and the other in /usr/libexec/git-core/git. It mistakenly
removed the only copy of git when gitexecdir and bindir are set to the
same directory, i.e. the traditional layout.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a follow-up patch to 49fa65a (Allow the built-in exec path to be
relative to the command invocation path, 2008-07-23). Without specific
gitexecdir passed from the command line, git-gui's build procedure would
try to figure out the value for it by running an installed git.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a user passes "--template=", then our template parameter
is blank. Unfortunately, copy_templates() assumes it has at
least one character, and does all sorts of bad things like
reading from template[-1] and then proceeding to link all of
'/' into the .git directory.
This patch just checks for that condition in copy_templates
and aborts. As a side effect, this means that --template=
now has the meaning "don't copy any templates."
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rewrite of git-mv from a shell script to a builtin was perhaps
a little too straightforward: the git add and git rm queues were
emulated directly, which resulted in a rather complicated code and
caused an inconsistent behaviour when moving dirty index entries;
git mv would update the entry based on working tree state,
except in case of overwrites, where the new entry would still have
sha1 of the old file.
This patch introduces rename_index_entry_at() into the index toolkit,
which will rename an entry while removing any entries the new entry
might render duplicate. This is then used in git mv instead
of all the file queues, resulting in a major simplification
of the code and an inevitable change in git mv -n output format.
Also the code used to refuse renaming overwriting symlink with a regular
file and vice versa; there is no need for that.
A few new tests have been added to the testsuite to reflect this change.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The path list builder had a branch for the case the source is not in index, but
this can happen only if the source was a directory. However, in that case we
have already expanded the list to the directory contents and set mode
to WORKING_DIRECTORY, which is tested earlier.
The patch removes the superfluous branch and adds an assert() instead. git-mv
testsuite still passes.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not all temporary file creation routines will ensure 14 bytes are
used to generate the temporary file name. In C Git this may be
true, but alternate implementations such as jgit are not always
able to generate a temporary file name with a specific prefix and
also ensure the file name length is 14 bytes long.
Since temporary files in a directory we are fsck'ing should be
uncommon (as they are short lived only long enough for an active
writer to finish writing the file and rename it) we shouldn't see
these show up very often. Always using a prefixcmp() call and
ignoring the length opens up room for other implementations to use
different name generation schemes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function list_commands_in_dir() tried to be lazy and just chdir()
to the directory which entries it listed, so that the check if the
file is executable could be done on dir->d_name.
However, there is no good reason to jump around wildly just to find
all Git commands.
Instead, have a strbuf and construct the full path dynamically.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After the optimization to --[no-]merged logic, the calculation of the
width of the longest refname to be shown might become inaccurate (since
the matching against merge_filter is performed after adding refs to
ref_list). This patch forces a recalculation of maxwidth when it might
be needed.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic for checking commits against merge_filter will be reused
when we recalculate the maxwidth of refnames.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous optimization to --[no-]merged ended up with some duplicated
code which this patch removes.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Those shorthands are explained in the rev-parse documentation but were not
actually supported by rev-parse itself.
gitk internally uses rev-parse to interpret its command line arguments, and
being able to use these "limit with parents" syntax is handy there.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
