The Git cli will accept dot '.' (period) as the relative path
to the current repository. Explain this action.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses "git reset" when dealing with
submodules. Now that we have parse_pathspec we can easily handle this
by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
To do this, we need to move the read_cache() call before the
parse_pathspec() call. All of the existing paths through cmd_reset()
that do not die early already call read_cache() at some point, so there
is no performance impact to doing this in the common case.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of re-implementing the "remove trailing slashes" loop in
builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to
parse_pathspec.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Current code makes pack-objects always do check_pack_crc() in
unpack_entry() even if right after that we find out there's a cached
version and pack access is not needed. Swap two code blocks, search
for cached version first, then check crc.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
check-ignore currently shows how .gitignore rules would treat untracked
paths. Tracked paths do not generate useful output. This prevents
debugging of why a path became tracked unexpectedly unless that path is
first removed from the index with `git rm --cached <path>`.
The option --no-index tells the command to bypass the check for the
path being in the index and hence allows tracked paths to be checked
too.
Whilst this behaviour deviates from the characteristics of `git add` and
`git status` its use case is unlikely to cause any user confusion.
Test scripts are augmented to check this option against the standard
ignores to ensure correct behaviour.
Signed-off-by: Dave Williams <dave@opensourcesolutions.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When append_normalized_escapes is called, its internal strbuf_add* calls can
cause the strbuf's buf to be reallocated changing the value of the buf pointer.
Do not use the strbuf buf pointer from before any append_normalized_escapes
calls afterwards. Instead recompute the needed pointer.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was unclear in the documentation how various configurations and
environment variables determine which pager is eventually used.
* jc/pager-configuration-doc:
config: rewrite core.pager documentation
* mm/mediawiki-dumb-push-fix:
git-remote-mediawiki: no need to update private ref in non-dumb push
git-remote-mediawiki: use no-private-update capability on dumb push
transport-helper: add no-private-update capability
git-remote-mediawiki: add test and check Makefile targets
"git config" did not provide a way to set or access numbers larger
than a native "int" on the platform; it now provides 64-bit signed
integers on all platforms.
* jk/config-int-range-check:
git-config: always treat --int as 64-bit internally
config: make numeric parsing errors more clear
config: set errno in numeric git_parse_* functions
config: properly range-check integer values
config: factor out integer parsing from range checks
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using git-gui as the primary git application on Windows it can be
awkward obtaining a suitable shell. This commit adds a menu item to the
Repository menu that launches the bash shell provided with the git
installation on Windows.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
On some systems (e.g. MinGW 4.0), string.h has only inline
definition of strcasecmp and no non-inline implementation is
supplied anywhere, which is, eh, "unusual". We cannot take an
address of such a function to store it in namemap.cmp.
Work it around by introducing our own level of indirection.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This turns the template COMMIT_EDITMSG from e.g
# [...]
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: builtin/commit.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# t/foo
#
to
# [...]
# Changes to be committed:
# modified: builtin/commit.c
#
# Untracked files:
# t/foo
#
Most status hints were written to be accurate when running "git status"
before running a commit. Many of them are not applicable when the commit
has already been started, and should not be shown in COMMIT_EDITMSG. The
most obvious are hints advising to run "git commit",
"git rebase/am/cherry-pick --continue", which do not make sense when the
command has already been run.
Other messages become slightly inaccurate (e.g. hint to use "git add" to
add untracked files), as the suggested commands are not immediately
applicable during the editing of COMMIT_EDITMSG, but would be applicable
if the commit is aborted. These messages are both potentially helpful and
slightly misleading. This patch chose to remove them too, to avoid
introducing too much complexity in the status code.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
No behavior change in this patch, but this makes the display of status
hints more flexible as they can be enabled or disabled for individual
calls to commit.c:run_status().
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cmd_commit and cmd_status use very similar code to initialize the
wt_status structure. Factor this code into a function to ensure future
changes will keep both versions consistent.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A recommended way to move trees between repositories is to use
git-filter-branch to revise the history for a single tree:
However, this can lead to "argument list too long" errors when the
original repository has many retained branches (>6k)
/usr/local/git/libexec/git-core/git-filter-branch: line 270:
/usr/local/git/libexec/git-core/git: Argument list too long
Could not get the commits
Saving the output from rev-parse and feeding it into rev-list from
its standard input avoids this problem, since the rev-parse output
is not processed as a command line argument.
Signed-off-by: Lee Carver <Lee.Carver@servicenow.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The HTTP 1.1 standard requires an Allow header for 405 Method Not Allowed:
The response MUST include an Allow header containing a list of valid methods
for the requested resource.
So provide such a header when we return a 405 to the user agent.
Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git ls-files -k" needs to crawl only the part of the working tree
that may overlap the paths in the index to find killed files, but
shared code with the logic to find all the untracked files, which
made it unnecessarily inefficient.
* jc/ls-files-killed-optim:
dir.c::test_one_path(): work around directory_exists_in_index_icase() breakage
t3010: update to demonstrate "ls-files -k" optimization pitfalls
ls-files -k: a directory only can be killed if the index has a non-directory
dir.c: use the cache_* macro to access the current index
The commit object names in the insn sheet that was prepared at the
beginning of "rebase -i" session can become ambiguous as the
rebasing progresses and the repository gains more commits. Make
sure the internal record is kept with full 40-hex object names.
* es/rebase-i-no-abbrev:
rebase -i: fix short SHA-1 collision
t3404: rebase -i: demonstrate short SHA-1 collision
t3404: make tests more self-contained
"git rebase -p" internally used the merge machinery, but when
rebasing, there should not be a need for merge summary.
* rt/rebase-p-no-merge-summary:
rebase --preserve-merges: ignore "merge.log" config
Tweak Gitweb CSS to layout some elements better.
* tf/gitweb-ss-tweak:
gitweb: make search help link less ugly
gitweb: omit the repository owner when it is unset
gitweb: vertically centre contents of page footer
gitweb: ensure OPML text fits inside its box
A call to xread() was used without a loop around to cope with short
read in the codepath to stream new contents to a pack.
* js/xread-in-full:
stream_to_pack: xread does not guarantee to read all requested bytes
"rebase -i" forgot that the comment character can be configurable
while reading its insn sheet.
* es/rebase-i-respect-core-commentchar:
rebase -i: fix cases ignoring core.commentchar
Update post-receive-email script to make sure the message contents
and pathnames are encoded consistently in UTF-8.
* jn/post-receive-utf8:
hooks/post-receive-email: set declared encoding to utf-8
hooks/post-receive-email: force log messages in UTF-8
hooks/post-receive-email: use plumbing instead of git log/show
"git pull --rebase" always flattened the history; pull.rebase can
now be set to "preserve" to invoke "rebase --preserve-merges".
* sh/pull-rebase-preserve:
pull: allow pull to preserve merges when rebasing
With MinGW runtime version 4.0 this interferes with the previous
definition from sdkddkver.h.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the synopsis, the second form to detach HEAD at the named commit
labelled the argument as '<commit>'. While this is technically more
correct, because the feature to detach is not limited to the tip of
a named branch, it was found confusing and did not express the fact
that you have to give `--detach` if you are naming the commit you
want to detach HEAD at with a branch name.
Separate this case into two syntactical forms, mimicking the way how
the DESCRIPTION section shows this usage. Also update the text that
explains the syntax to name the commit to detach HEAD at to clarify.
Suggested-by: Benjamin Bergman <ben@benbergman.ca>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
hashtable_index() appears to be a close duplicate of hash_obj().
Keep only the later and make it usable for all cases.
Also remove the modulus as this is an expensive operation.
The size argument is always a power of 2 anyway, so a simple
mask operation provides the same result.
On a 'git rev-list --all --objects' run this decreased the time spent
in lookup_object from 27.5% to 24.1%.
[jc: with a few comments on "modulus turned into mask" by Peff]
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git status' and 'git commit' can be told to also show the output of "git
submodule summary" by setting the "status.submodulesummary" config option.
But status and commit also honor the "diff.ignoreSubmodules" and the
"submodule.<name>.ignore" settings, which then disable the summary partly
or completely. This - and the fact that the last two settings do not
affect the "git submodule" commands at all - is not well documented.
Extend the documentation in those places where "status.submodulesummary",
"diff.ignoreSubmodules" and "submodule.<name>.ignore" are described to
better explain these dependencies.
Thanks-to: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In msvc.h, there's a couple of stat related functions defined diffently
from mingw.h. When we remove these definitions, the only problem we get is
"warning C4005: '_stati64' : macro redefinition" for this line in mingw.h:
#define _stati64(x,y) mingw_stat(x,y)
The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the
original _stati64 family of functions was renamed to _stat32i64, and the
former function names became macros (pointing to the appropriate function
based on the definition of _USE_32BIT_TIME_T).
Defining _stati64 works on MinGW because MinGW by default compiles against
the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather
than a macro).
Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC
apparently can also compile for the Windows MSVCRT.DLL via the DDK (see
http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ).
Remove the stat definitions from msvc.h, as they are not compiler related.
In mingw.h, determine the runtime version in use from the definitions of
_stati64 and _USE_32BIT_TIME_T, and define stat() accordingly.
This also fixes that stat() in MSVC builds still resolves to mingw_lstat()
instead of mingw_stat().
Signed-off-by: Karsten Blees <blees@dcon.de>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Skip errno.h definitions if they are already defined.
Signed-off-by: Karsten Blees <blees@dcon.de>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set NO_GETTEXT in config.mak.uname to get rid of libintl.h dependency.
Signed-off-by: Karsten Blees <blees@dcon.de>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extend t/t1400-update-ref.sh to cover cases using the --stdin option.
Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When determining the file mode from either ls-tree or diff-tree
output, we used to grab these octal mode string (typically 100644 or
100755) and then did
$git_perms .= "r" if ( $mode & 4 );
$git_perms .= "w" if ( $mode & 2 );
$git_perms .= "x" if ( $mode & 1 );
which was already wrong, as (100644 & 4) is very different from
oct("100644") & 4. An earlier refactoring 2c3af7e7 (cvsserver:
factor out git-log parsing logic, 2012-10-13) further changed it to
pick the third octal digit (10*0*644 or 10*0*755) from the left and
then do the above conversion, which does not make sense, either.
Let's use the third digit from the last of the octal mode string to
make sure we get the executable and read bits right.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Michael Cronenworth <mike@cchtml.com>
If SSL verification is enabled in git send-email, we could attempt to call a
method on an undefined value if the verification failed, since $smtp would end
up being undef. Look up the error string in a way that will produce a helpful
error message and not cause further errors.
Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use "struct pathspec" interface in more places, instead of array of
characters, the latter of which cannot express magic pathspecs
(e.g. ":(icase)makefile" that matches both Makefile and makefile).
* nd/magic-pathspec:
add: lift the pathspec magic restriction on "add -p"
pathspec: catch prepending :(prefix) on pathspec with short magic
Send a large request to read(2)/write(2) as a smaller but still
reasonably large chunks, which would improve the latency when the
operation needs to be killed and incidentally works around broken
64-bit systems that cannot take a 2GB write or read in one go.
* sp/clip-read-write-to-8mb:
Revert "compat/clipped-write.c: large write(2) fails on Mac OS X/XNU"
xread, xwrite: limit size of IO to 8MB
