GIT-VERSION-GEN: mark the version 'dirty' only if there are modified files
We used to mark the version string with '-dirty' if the cache was not up
to date, but the only thing we want to know is if the binaries are built
from modified source. Refresh the cache to avoid false dirtyness.
Christian Jaeger noticed this issue while building under fakeroot
environment (without -u) that lies about the file ownership data.
"git commit -a" ignores untracked files and follows all tracked
files, regardless of whether they are listed in .gitignore. So
don't use it to motivate gitignore.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Acked-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: add ability to specify --commit-url for dcommit
This allows one to use public svn:// URLs for fetch and
svn+ssh:// URLs for committing (without using the complicated
rewriteRoot option, reimporting or git-filter-branch).
Using this can also help avoid unnecessary server
authentication/encryption overhead on busy SVN servers.
Along with the new --revision option, this can also be allowed
to override the branch detection in dcommit, too. This is
potentially dangerous and not recommended! (And also purposely
undocumented, but the loaded gun is there in case somebody
wants to make it safe).
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Files given on the command line are relative to $cwd
When running "git commit -F file" and "git tag -F file" from a
subdirectory, we should take it as relative to the directory we started
from, not relative to the top-level directory.
This adds a helper function "parse_options_fix_filename()" to make it more
convenient to fix this class of issues. Ideally, parse_options() should
support a new type of option, "OPT_FILENAME", to do this uniformly, but
this patch is meant to go to 'maint' to fix it minimally.
One thing to note is that value for "commit template file" that comes from
the command line is taken as relative to $cwd just like other parameters,
but when it comes from the configuration varilable 'commit.template', it
is taken as relative to the working tree root as before. I think this
difference actually is sensible (not that I particularly think
commit.template itself is sensible).
* git://repo.or.cz/git-gui:
git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
git-gui: add a part about format strings in po/README
git-gui: update po/it.po
git-gui: update Japanese translation
git-gui: Update swedish translation.
git-gui: Update git-gui.pot for 0.11 nearing release
git-gui: Update German translation
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Update swedish translation.
gitk: Updated German translation
gitk: Fallback to selecting the head commit upon load
gitk: Fixed automatic row selection during load
gitk: Fixed broken exception handling in diff
gitk: On Windows, use a Cygwin-specific flag for kill
gitk: Arrange to kill diff-files & diff-index on quit
gitk: Kill back-end processes on window close
usage pattern by Porcelains properly. For diff-tree to talk sensibly
about commits, it needs to see commits, not just trees; the code was fixed
to take list of commits on the standard input in 1.2.0.
However we left the documentation stale for a long time, until Karl
Hasselström finally noticed it very recently.
Optimize sha1_object_info for loose objects, not concurrent repacks
When dealing with a repository with lots of loose objects, sha1_object_info
would rescan the packs directory every time an unpacked object was referenced
before finally giving up and looking for the loose object. This caused a lot
of extra unnecessary system calls during git pack-objects; the code was
rereading the entire pack directory once for each loose object file.
This patch looks for a loose object before falling back to rescanning the
pack directory, rather than the other way around.
Signed-off-by: Steven Grimm <koreth@midwinter.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach fsck and prune that tmp_obj_ file names may not be 14 bytes long
As Shawn pointed out, not all temporary file creation routines can
ensure that the generated temporary file is of a certain length.
e.g. Java's createTempFile(prefix, suffix). So just depend on the
prefix 'tmp_obj_' for detection.
Update prune, and fix the "fix" introduced by a08c53a1 :)
Signed-off-by: Brandon "appendixless" Casey <casey@nrlssc.navy.mil> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add branch subcommand to completions and USAGE for git-stash.sh.
Complete stash names for show, apply, drop, pop, and branch.
Add "--index" long option for apply.
Signed-off-by: Lee Marlow <lee.marlow@gmail.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add completions for all long options specified in the docs
--local --no-hardlinks --shared --reference
--quiet --no-checkout --bare --mirror --origin
--upload-pack --template= --depth
Signed-off-by: Lee Marlow <lee.marlow@gmail.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Changed the ptouch bash function to use the "Text Last Updated"
date reported by 'svn info' when changing the modified time
(mtime) of the file/symlink/directory in the git working
directory. Previously it used the mtime of the item in the
svn working directory, which caused the race condition.
[ew: swapped argument order of ptouch() to minimize diff]
From: David D. Kilzer <ddkilzer@kilzer.net>
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configuration was added as a core option in 3299c6f (diff: make
default rename detection limit configurable., 2005-11-15), but 9ce392f
(Move diff.renamelimit out of default configuration., 2005-11-21)
separated diff-related stuff out of the core.
Up to that point it was Ok.
When we separated the Porcelain options out of the git_diff_config in 83ad63c (diff: do not use configuration magic at the core-level,
2006-07-08), we should have been more careful.
This mistake made diff-tree plumbing and git-show Porcelain to notice
different set of renames when the user explicitly asked for rename
detection.
The tests requires anonymous write access. Therefore, "anon-access =
write" is added to conf/svnserve.conf. But because it was added to
the end of the file, it is impossible to guarantee in what section
it will be located. It turned out that on SVN 1.5, it was placed in
the wrong section and as result the test failed.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Tested-by: Brad King <brad.king@kitware.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git::DESTROY calls _close_cat_blob and _close_hash_and_insert_object,
which in turn call command_close_bidi_pipe, which calls waitpid, which
alters $?. If this happens during global destruction, it may alter the
program's exit status unexpectedly. Making $? local to the function
solves the problem.
(The problem was discovered due to a failure of test #8 in
t9106-git-svn-commit-diff-clobber.sh.)
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
The new execdir is two levels below the root directory, while
the old execdir 'bin' was only one level below. This commit
adapts the discovery of oguilib that uses relative paths
accordingly. We determine whether we have the extra level in the same
way in which the Makefile defines sharedir, i.e. whether the last
directory part is 'git-core'.
Inspired-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-svn: Abort with an error if 'fetch' parameter is invalid.
Previously, if a config entry looked like this:
svn-remote.svn.fetch=:refs/heads/whatever
git-svn would silently do nothing if you asked it to "git svn fetch", and
give a strange error if asked to "git svn dcommit". What it really wants is
a line that looks like this:
svn-remote.svn.fetch=:refs/remotes/whatever
So we should simply abort if we get the wrong thing.
On the other hand, there's actually no good reason for git-svn to enforce
using the refs/remotes namespace, but the code seems to have hardcoded this
in several places and I'm not brave enough to try to fix it all right now.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone --bare: Add ".git" suffix to the directory name to clone into
We have a tradition that bare repositories live in directories ending
in ".git". To make this more a convention than just a tradition, teach
"git clone --bare" to add a ".git" suffix to the directory name.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
printf() without an explicit format string is not a good coding practise,
unless the printed string is guaranteed to not contain percent signs. While
fixing this, we might as well combine the calls to fwrite() and printf().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch enhances the tex funcname by adding support for
chapter and part sectioning commands. It also matches
the starred version of the sectioning commands.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Finds classes, records, functions, procedures, and sections. Most lines
need to start at the first column, or else there's no way to differentiate
a procedure's definition from its declaration.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-name-rev.c: split deeply nested part from the main function
The main function of this command implementation tries to do too many
things. Split out a handling of single input line into a separate
function to reduce nesting level and clutter.
git-add -i ranges expect number-number. But for the supremely lazy, typing in
that second number when selecting "from patch 7 to the end" is wasted effort.
So treat an empty second number in a range as "until the last item".
Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running git submodule update -i, the "-i" is shifted before recursing
into cmd_init and then again outside of the loop. This causes some /bin/sh
to complain about shifting when there are no arguments left (and would
discard anything written after -i too).
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
sort_in_topological_order(): avoid setting a commit flag
We used to set the TOPOSORT flag of commits during the topological
sorting, but we can just as well use the member "indegree" for it:
indegree is now incremented by 1 in the cases where the commit used
to have the TOPOSORT flag.
This is the same behavior as before, since indegree could not be
non-zero when TOPOSORT was unset.
Incidentally, this fixes the bug in show-branch where the 8th column
was not shown: show-branch sorts the commits in topological order,
assuming that all the commit flags are available for show-branch's
private matters.
But this was not true: TOPOSORT was identical to the flag corresponding
to the 8th ref. So the flags for the 8th column were unset by the
topological sorting.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Propagate -u/--upload-pack option of "git clone" to transport.
The -u option to override the remote system's path to git-upload-pack was
being ignored by "git clone"; caused by a missing call to
transport_set_option to set TRANS_OPT_UPLOADPACK. Presumably this crept in
when git-clone was converted from shell to C.
Signed-off-by: Steve Haslam <shaslam@lastminute.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A wildcard refspec is internally parsed into a refspec structure with src
and dst strings. Many parts of the code assumed that these do not include
the trailing "/*" when matching the wildcard pattern with an actual ref we
see at the remote. What this meant was that we needed to make sure not
just that the prefix matched, and also that a slash followed the part that
matched.
But a codepath that scans the result from ls-remote and finds matching
refs forgot to check the "matching part must be followed by a slash" rule.
This resulted in "refs/heads/b1" from the remote side to mistakenly match
the source side of "refs/heads/b/*:refs/remotes/b/*" refspec.
Worse, the refspec crafted internally by "git-clone", and a hardcoded
preparsed refspec that is used to implement "git-fetch --tags", violated
this "parsed widcard refspec does not end with slash" rule; simply adding
the "matching part must be followed by a slash" rule then would have
broken codepaths that use these refspecs.
This commit changes the rule to require a trailing slash to parsed
wildcard refspecs. IOW, "refs/heads/b/*:refs/remotes/b/*" is parsed as
src = "refs/heads/b/" and dst = "refs/remotes/b/". This allows us to
simplify the matching logic because we only need to do a prefixcmp() to
notice "refs/heads/b/one" matches and "refs/heads/b1" does not.
Acked-by: Daniel Barkalow <barkalow@iabervon.org> 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."
Allow "non-option" revision options in parse_option-enabled commands
Commands which use parse_options() but also call setup_revisions()
must do their parsing in a two step process:
1. first, they parse all options. Anything unknown goes to
parse_revision_opt() (which calls handle_revision_opt), which
may claim the option or say "I don't recognize this"
2. the non-option remainder goes to setup_revisions() to
actually get turned into revisions
Some revision options are "non-options" in that they must be
parsed in order with their revision counterparts in
setup_revisions(). For example, "--all" functions as a
pseudo-option expanding to all refs, and "--no-walk" affects refs
after it on the command line, but not before. The revision option
parser in step 1 recognizes such options and sets them aside for
later parsing by setup_revisions().
However, the return value used from handle_revision_opt indicated
"I didn't recognize this", which was wrong. It did, and it took
appropriate action (even though that action was just deferring it
for later parsing). Thus it should return "yes, I recognized
this."
Previously, these pseudo-options generated an error when used with
parse_options parsers (currently just blame and shortlog). With
this patch, they should work fine, enabling things like "git
shortlog --all".
Signed-off-by: Jeff King <peff@peff.net> Acked-By: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We recently let the user know explicitly that an empty
commit message will abort the commit. However, this adds yet
another line to the template; let's rephrase and re-wrap so
that this fits back on two lines.
This patch also makes the "fatal: empty commit message?"
warning a bit less scary, since this is now a "feature"
instead of an error. However, we retain the non-zero exit
status to indicate to callers that nothing was committed.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Switching views now actually preserves the selected commit.
- Reloading (also Edit View) preserves the currently selected commit.
- Initial selection does not produce weird scrolling.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Arrange to kill diff-files & diff-index on quit
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>
Make the DESCRIPTION match <x>... items in the SYNOPSIS
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>
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.
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.
* 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.
archive: allow --exec and --remote without equal sign
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>
Teach gitlinks to ie_modified() and ce_modified_check_fs()
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.