| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The argc parameter is never used by the run_command_v family of
functions. Instead they require that the passed argv[] be NULL
terminated so they can rely on the operating system's execvp
function to correctly pass the arguments to the new process.
Making the caller pass the argc is just confusing, as the caller
could be mislead into believing that the argc might take precendece
over the argv, or that the argv does not need to be NULL terminated.
So goodbye argc. Don't come back.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many users find it unfriendly that they can create a bare git
repository easily with `git clone --bare` but are then unable to
run simple commands like `git log` once they cd into that newly
created bare repository. This occurs because we do not check to
see if the current working directory is a git repository.
Instead of failing out with "fatal: Not a git repository" we should
try to automatically detect if the current working directory is
a bare repository and use that for GIT_DIR, and fail out only if
that doesn't appear to be true.
We test the current working directory only after we have tried
searching up the directory tree. This is to retain backwards
compatibility with our previous behavior on the off chance that
a user has a 'refs' and 'objects' subdirectories and a 'HEAD'
file that looks like a symref, all stored within a repository's
associated working directory.
This change also consolidates the validation logic between the case
of GIT_DIR being supplied and GIT_DIR not being supplied, cleaning
up the code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
|
| |
We tend to use the nice constant GIT_DIR_ENVIRONMENT when we
are referring to the "GIT_DIR" constant, but git.c didn't do
so. Now it does.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
| |
For easier portability we prefer PATH_MAX over seemingly random
constants like 1024. Make it so.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many users have noticed that core.filemode doesn't appear to be
automatically set right on Cygwin when using a repository stored
on NTFS. The issue is that Cygwin and NTFS correctly supports
the executable mode bit, and Git properly detected that, but most
native Windows applications tend to create files such that Cygwin
sees the executable bit set when it probably shouldn't be.
This is especially bad if the user's favorite editor deletes the
file then recreates it whenever they save (vs. just overwriting)
as now a file that was created with mode 0644 by checkout-index
appears to have mode 0755.
So we introduce NO_TRUSTABLE_FILEMODE, settable at compile time.
Setting this option forces core.filemode to false, even if the
detection code would have returned true. This option should be
enabled by default on Cygwin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The line:
[remote "<remote>"]
was getting swallowed up by asciidoc, causing a critical line in the
explanation for how to store the .git/remotes information in .git/config
to go missing from the git-fetch, git-pull, and git-push manpages.
Put all of the examples into delimited blocks to fix this problem and to
make them look nicer.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In very obscure cases, a merge can hit an unexpected code path (where the
original code went as far as saying that this was a bug). This failing
merge was noticed by Alexandre Juillard.
The problem is that the original file contains something like this:
-- snip --
two non-empty lines
before two empty lines
after two empty lines
-- snap --
and this snippet is reduced to _one_ empty line in _both_ new files.
However, it is ambiguous as to which hunk takes the empty line: the first
or the second one?
Indeed in Alexandre's example files, the xdiff algorithm attributes the
empty line to the first hunk in one case, and to the second hunk in the
other case.
(Trimming down the example files _changes_ that behaviour!)
Thus, the call to xdl_merge_cmp_lines() has no chance to realize that the
change is actually identical in both new files. Therefore,
xdl_refine_conflicts() finds an empty diff script, which was not expected
there, because (the original author of xdl_merge() thought)
xdl_merge_cmp_lines() would catch that case earlier.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
|
|
|
| |
After re-coding the commit message into the encoding the user
specified (either with core.logoutputencidng or --encoding
option), this drops the "encoding" header altogether. The
output is after re-coding as the user asked (either with the
config or --encoding=<encoding> option), and the extra header
becomes redundant information.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
| |
People can spell config.commitencoding differently from what we
internally have ("utf-8") to mean UTF-8. Try to accept them and
treat them equally.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
| |
This way, git-rev-list and git-diff-tree with --pretty can use
it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
| |
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
| |
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
| |
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
|
|
| |
Telling the git-log family not to do any character conversion is
done with --encoding=none, which sets log_output_encoding to an
empty string. However, logmsg_reencode() confused this with
log_output_encoding and commit_encoding set to NULL. The latter
means we should use the default encoding (i.e. utf-8).
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|\
| |
| |
| |
| | |
* jc/curl:
Work around http-fetch built with cURL 7.16.0
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It appears that curl_easy_duphandle() from libcurl 7.16.0
returns a curl session handle which fails GOOD_MULTI_HANDLE()
check in curl_multi_add_handle(). This causes fetch_ref() to
fail because start_active_slot() cannot start the request.
For now, check for 7.16.0 to work this issue around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When '*.ig' is ignored, and you have two files f.ig and d.ig/foo
in the working tree,
$ git add .
correctly ignored f.ig but failed to ignore d.ig/foo. This was
caused by a thinko in an earlier commit 4888c534, when we tried
to allow adding otherwise ignored files.
After reverting that commit, this takes a much simpler approach.
When we have an unmatched pathspec that talks about an existing
pathname, we know it is an ignored path the user tried to add,
so we include it in the set of paths directory walker returned.
This does not let you say "git add -f D" on an ignored directory
D and add everything under D. People can submit a patch to
further allow it if they want to, but I think it is a saner
behaviour to require explicit paths to be spelled out in such a
case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
| |
| |
| | |
This reverts commit 4888c534099012d71d24051deb5b14319747bd1a.
|
| |
| |
| |
| |
| | |
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
| |
| |
| |
| |
| |
| | |
Not that this reveals anything new, but I did test_tick shell
function in test-lib and found it rather cute and nice.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* jc/utf8:
t3900: test conversion to non UTF-8 as well
Rename t3900 test vector file
UTF-8: introduce i18n.logoutputencoding.
Teach log family --encoding
i18n.logToUTF8: convert commit log message to UTF-8
Move encoding conversion routine out of mailinfo to utf8.c
Conflicts:
commit.c
|
| | |
| | |
| | |
| | | |
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It appears ISO-2022-JP is more widely accepted than ISO2022JP, so
rename it that way. We probably would need to have a way to skip
this test altogether in locale-challenged environments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is plausible for somebody to want to view the commit log in a
different encoding from i18n.commitencoding -- the project's
policy may be UTF-8 and the user may be using a commit message
hook to run iconv to conform to that policy (and either not have
i18n.commitencoding to default to UTF-8 or have it explicitly
set to UTF-8). Even then, Latin-1 may be more convenient for
the usual pager and the terminal the user uses.
The new variable i18n.logoutputencoding is used in preference to
i18n.commitencoding to decide what encoding to recode the log
output in when git-log and friends formats the commit log message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Updated commit objects record the encoding used in their
encoding header. This updates the log family to reencode it
into the encoding specified in i18n.commitencoding (or the
default, which is "utf-8") upon output.
To force a specific encoding that is different, log family takes
command line flag --encoding=<encoding>; giving --encoding=none
entirely disables the reencoding and lets you view log messges
in their original encoding.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When i18n.commitencoding is set to a non UTF-8 encoding,
commit-tree records the encoding in an extra header after
author/committer headers in the commit object.
An earlier version used trailer but Johannes points out that
there is little risk breaking existing Porcelains with a new
header.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This moves the body of convert_to_utf8() routine used in mailinfo
to the utf8.c i18n library.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This changes the default remote.origin.fetch configuration
created by git-clone so that it allows non-fast-forward updates.
When using the separate-remote layout with reflog enabled, it
does not make much sense to refuse to update the remote tracking
branch just because some of them do not fast-forward. git-fetch
issues warnings on non-fast-forwardness, and the user can peek
at what the previous state was using the reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Not using reflog for tags/ was very sensible; not giving reflog
for the remotes/ was not.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In some environments, certain tests have no way of succeeding
due to platform limitation, such as lack of 'unzip' program, or
filesystem that do not allow arbitrary sequence of non-NUL bytes
as pathnames.
You should be able to say something like
$ cd t
$ GIT_SKIP_TESTS=t9200.8 t9200-git-cvsexport-commit.sh
and even:
$ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make test
to omit such tests. The value of the environment variable is a
SP separated list of patterns that tells which tests to skip,
and either can match the "t[0-9]{4}" part to skip the whole
test, or t[0-9]{4} followed by ".$number" to say which
particular test to skip.
Note that some tests in the existing test suite rely on previous
test item, so you cannot arbitrarily disable one and expect the
remainder of test to check what the test originally was intended
to check.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
* jc/make:
gcc does not necessarily pass runtime libpath with -R
|
| | |/
| |/|
| | |
| | | |
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Otherwise, sending the diagnostic to stdout would provoke a
protocol failure.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The function xdl_refine_conflicts() tries to break down huge
conflicts by doing a diff on the conflicting regions. However,
this does not make sense when one side is empty.
Worse, when one side is not only empty, but after EOF, the code
accessed unmapped memory.
Noticed by Luben Tuikov, Shawn Pearce and Alexandre Julliard, the
latter providing a test case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This looks a bit more pleasant for users.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Not sure how I missed this the first time around...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This could be useful in finding new problems and helping users
debug.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We have less code to worry about now. As a bonus, --revision
can be used to reliably skip parts of history whenever fetch is
run, not just the first time. I'm not sure why anybody would
want to skip history in the middle, however...
For people (nearly everyone at the moment) without the
do_switch() function in their Perl SVN library, the entire tree
must be refetched if --follow-parent is used and a parent is
found. Future versions of SVN will have a working do_switch()
function accessible via Perl.
Accessing repositories on the local machine (especially file://
ones) is also slightly slower as a result; but I suspect most
git-svn users will be using it to access remote repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also, fixed an unportable use of 'export'.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I don't think anybody running tests needs to know they're
running init-db and creating a repository for testing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We get an extra measure of error checking here as well.
While we're at it, also removed a less portable use of export.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* js/shallow:
fetch-pack: Do not fetch tags for shallow clones.
get_shallow_commits: Avoid memory leak if a commit has been reached already.
git-fetch: Reset shallow_depth before auto-following tags.
upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
fetch-pack: Properly remove the shallow file when it becomes empty.
shallow clone: unparse and reparse an unshallowed commit
Why didn't we mark want_obj as ~UNINTERESTING in the old code?
Why does it mean we do not have to register shallow if we have one?
We should make sure that the protocol is still extensible.
add tests for shallow stuff
Shallow clone: do not ignore shallowness when following tags
allow deepening of a shallow repository
allow cloning a repository "shallowly"
support fetching into a shallow repository
upload-pack: no longer call rev-list
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is to adjust to:
count-objects -v: show number of packs as well.
which will break a test in this series.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
A better fix may be to only fetch tags that point to commits that we
are downloading, but git-clone doesn't have support for following
tags. This will happen automatically on the next git-fetch though.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Otherwise fetching the tags could also fetch commits up to the
specified depth, which isn't the expected behavior.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
A commit may have been put on the shallow list, and then reached from
another branch and marked NOT_SHALLOW without being removed from the
list.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The code was unlinking the lock file instead.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Otherwise we would not read the real parents from the commit
object.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Is this something we would want to do regardless of shallow clone?
|