Introduce is_utf() to check if a text looks like it is encoded
in UTF-8, utf8_width() to count display width, and implements
print_wrapped_text() using them.
git-commit-tree warns if the commit message does not minimally
conform to the UTF-8 encoding when i18n.commitencoding is either
unset, or set to "utf-8".
Now that Git depends on pread in index-pack its safe to say we can
also depend on it within the git_mmap emulation we activate when
NO_MMAP is set. On most systems pread should be slightly faster
than an lseek/read/lseek sequence as its one system call vs. three
system calls.
We also now honor EAGAIN and EINTR error codes from pread and
restart the prior read.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This minor cleanup was suggested by Johannes Schindelin.
The mmap is still fake in the sense that we don't support PROT_WRITE
or MAP_SHARED with external modification at all, but that hasn't
stopped us from using mmap() thoughout the Git code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Makefile: add quick-install-doc for installing pre-built manpages
This adds and uses the install-doc-quick.sh file to
Documentation/, which is usable for people who track either the
'html' or 'man' heads in Junio's repository (prefixed with
'origin/' if cloned locally). You may override this by
specifying DOC_REF in the make environment or in config.mak.
GZ may also be set in the environment (or config.mak) if you
wish to gzip the documentation after installing it.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Display 'theirs' branch name when possible in merge.
Displaying the SHA1 of 'their' branch (the branch being merged into
the current branch) is not nearly as friendly as just displaying
the name of that branch, especially if that branch is already local
to this repository.
git-merge now sets the environment variable 'GITHEAD_%(sha1)=%(name)'
for each argument it gets passed, making the actual input name that
resolved to the commit '%(sha1)' easily available to the invoked
merge strategy.
git-merge-recursive makes use of these environment variables when
they are available by using '%(name)' whenever it outputs the commit
identification rather than '%(sha1)'. This is most obvious in the
conflict hunks created by xdl_merge:
Use extended SHA1 syntax in merge-recursive conflicts.
When we get a line-level conflict in merge-recursive and print out
the two sides in the conflict hunk header and footer we should use
the standard extended SHA1 syntax to specify the specific blob,
as this allows the user to copy and paste the line right into
'git show' to view the complete version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Part of the patch for "gitweb: Show '...' links in "summary" view only
if there are more items" (313ce8cee665447e4476d7e8985b270346a8e5a1) is
missing. Add it back in.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-show-branch options similar to git-branch.
Branch has "-r" for remote branches and "-a" for local and remote.
It seems logical to mirror that in show-branch. Also removes the
dubiously useful "--tags" option (as part of changing the meaning
for "--all").
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
The option checking code for --git-dir had an off by 1 error that
would cause it to access uninitialized memory if it was the last
argument. This causes it to display an error and display the usage
string instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is confusing when somebody attempts to do this:
$ git pull origin/foo
which is not syntactically correct (unless you have origin/foo.git
repository) and should fail, but it resulted in a mysterious
access to the 'foo' subdirectory of the origin repository.
Which was what it was designed to do, but because this is an
oddball "feature" I suspect nobody uses, let's remove it.
default pull: forget about "newbie protection" for now.
This will not be backward compatible no matter how you cut it.
Shelve it for now until somebody comes up with a better way to
determine when we can safely refuse to use the first set of
branchse for merging without upsetting valid workflows.
merge and reset: adjust for "reset --hard" messages
An earlier commit made "reset --hard" chattier but leaking its
message from "git rebase" (which calls it when first rewinding
the current branch to prepare replaying our own changes) without
explanation was confusing, so add an extra message to mention
it. Inside restorestate in merge (which is rarely exercised
codepath, where more than one strategies are attempted),
resetting to the original state uses "reset --hard" -- this can
be squelched entirely.
Like the existing error() function the new warn() function can be
used to describe a situation that probably should not be occuring,
but which the user (and Git) can continue to work around without
running into too many problems.
An example situation is a bad commit SHA1 found in a reflog.
Attempting to read this record out of the reflog isn't really an
error as we have skipped over it in the past.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Because I am about to introduce a global warn() function (much
like the global error function) this global declaration would
conflict with the one supplied by imap-send. Further since
imap-send's warn function output depends on its Quiet setting
we cannot simply remove its internal definition and use the
forthcoming global one.
So refactor warn() -> imap_warn() and info() -> imap_info()
(the latter was done just to be consistent in naming).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
parse-remote: mark all refs not for merge only when fetching more than one
An earlier commit a71fb0a1 implemented much requested safety
valve to refuse "git pull" or "git pull origin" without explicit
refspecs from using the first set of remote refs obtained by
reading .git/remotes/origin file or branch.*.fetch configuration
variables to create a merge. The argument was that while on a
branch different from the default branch, it is often wrong to
merge the default remote ref suitable for merging into the master.
That is fine as a theory. But many repositories already in use
by people in the real world do not have any of the per branch
configuration crap. They did not need it, and they do not need
it now. Merging with the first remote ref listed was just fine,
because they had only one ref (e.g. 'master' from linux-2.6.git)
anyway.
So this changes the safety valve to be a lot looser. When "git
fetch" gets only one remote branch, the irritating warning would
not trigger anymore.
I think we could also make the warning trigger when branch.*.merge
is not specified for the current branch, but is for some other
branch. That is for another commit.
The logic to decide when to refuse to use the default "first set of
refs fetched" for merge was utterly bogus.
In a repository that happily worked correctly without any of the
per-branch configuration crap did not have (and did not have to
have) any branch.<current>.merge. With that broken commit, pulling
from origin no longer would work.
Now that we have decided to make 'add' behave like 'update-index'
(and therefore fully classify update-index as strictly plumbing)
the am/revert/cherry-pick family of commands should not steer the
user towards update-index. Instead send them to the command they
probably already know, 'add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
When parsing the diff line starting with '@@', the line number of the
'+' file is parsed. For the subsequent line parses, the line number
should therefore be incremented after the parse, not before it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
This corrects minor remaining bits that still talked about <tree-ish>;
the Porcelain users (as opposed to plumbers) are mostly interested in
commits so use <commit> consistently and keep a sentence that mentions
that <tree-ish> can be used in place of them.
* jc/clone:
Move "no merge candidate" warning into git-pull
Use preprocessor constants for environment variable names.
Do not create $GIT_DIR/remotes/ directory anymore.
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
git-clone: lose the traditional 'no-separate-remote' layout
git-clone: lose the artificial "first" fetch refspec
git-pull: refuse default merge without branch.*.merge
git-clone: use wildcard specification for tracking branches
index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
It was reported by Randal L. Schwartz <merlyn@stonehenge.com> that
indexing the Linux repository ~150MB pack takes about an hour on OS x
while it's a minute on Linux. It seems that the OS X mmap()
implementation is more than 2 orders of magnitude slower than the Linux
one.
Linus proposed a patch replacing mmap() with pread() bringing index-pack
performance on OS X in line with the Linux one. The performances on
Linux also improved by a small margin.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Show '...' links in "summary" view only if there are more items
Show "..." links in "summary" view to shortlog, heads (if there are
any), and tags (if there are any) only if there are more items to show
than shown already.
This means that "..." link is shown below shortened shortlog if there
are more than 16 commits, "..." link below shortened heads list if
there are more than 16 heads refs (16 branches), "..." link below
shortened tags list if there are more than 16 tags.
Modified patch from Jakub to to apply cleanly to master, also preform
the same "..." link logic to the forks list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove COLLISION_CHECK from Makefile since it's not used.
It's rather misleading to have configuration options that don't do
anything. If someone adds collision checking they might also want to
restore this option.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Feeding symmetric difference to gitk is so useful, and it is the
same for other graphical Porcelains. Rather than forcing them
to pass --no-left-right, making it optional.
Use preprocessor constants for environment variable names.
We broke the discipline Linus set up to allow compiler help us
avoid typos in environment names in the early days of git over
time. This defines a handful preprocessor constants for
environment variable names used in relatively core parts of the
system.
I've left out variable names specific to subsystems such as HTTP
and SSL as I do not think they are big problems.
* jc/test-clone: (35 commits)
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
rerere: fix breakage of resolving.
Add config example with respect to branch
Add documentation for show-branch --topics
make git a bit less cryptic on fetch errors
make patch_delta() error cases a bit more verbose
racy-git: documentation updates.
show-ref: fix --exclude-existing
parse-remote::expand_refs_wildcard()
vim syntax: follow recent changes to commit template
show-ref: fix --verify --hash=length
show-ref: fix --quiet --verify
avoid accessing _all_ loose refs in git-show-ref --verify
git-fetch: Avoid reading packed refs over and over again
Teach show-branch how to show ref-log data.
markup fix in svnimport documentation.
Documentation: new option -P for git-svnimport
Fix mis-mark-up in git-merge-file.txt documentation
...
Revert "fix testsuite: make sure they use templates freshly built from the source"
This reverts commit 74d20040cafdced657efbf49795183d209a3a07b.
Version from Johannes to introduce GIT_TEMPLATE_DIR is simpler,
although I unconsciously stayed away from introducing yet another
environment variable.
blame: -b (blame.blankboundary) and --root (blame.showroot)
When blame.blankboundary is set (or -b option is given), commit
object names are blanked out in the "human readable" output
format for boundary commits.
When blame.showroot is not set (or --root is not given), the
root commits are treated as boundary commits. The code still
attributes the lines to them, but with -b their object names are
not shown.
If there are more than one branches to be deleted, failure on
one will no longer stop git-branch to process the next ones.
The command still reports failures by exitting non-zero status.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
I just twisted it not to check fast-forwardness with the current
branch when you are removing a tracking branch. Most likely,
removal of a tracking branch is not because you are "done with"
it (for a local branch, it usually means "you merged it up"),
but because you are not even interested in it. In other words,
remote tracking branches are more like tags than branches.
fix testsuite: make sure they use templates freshly built from the source
The initial t/trash repository for testing was created properly
but over time we gained many tests that create secondary test
repositories with init-db or clone and they were not careful
enough.
commit e2b70087 botched the RCS merge to git-merge-file conversion.
There is no command called "git merge-file" (yes, we are using safer
variant of Perl's system(3)).
Add a quick paragraph explaining the --topics option for show-branch.
The explanation is an abbreviated version of the commit message from d320a5437f8304cf9ea3ee1898e49d643e005738.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
The remote server might not want to tell why it doesn't like us for
security reasons, but let's make the client report such error in a bit
less confusing way. The remote failure remains a mystery, but the local
message might be a bit less so.
[jc: with a gentle wording updates from Andy Parkins]
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
It is especially important to distinguish between a malloc() failure
from all the other cases. An out of memory condition is much less
worrisome than a compatibility/corruption problem.
Also make test-delta compilable again.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
We've removed the workaround for runtime penalty that did not
exist in practice some time ago, but the technical paper that
proposed that change still said "we probably should do so".
* 'jn/web' (early part):
gitweb: Add "next" link to commit view
gitweb: Add title attribute to ref marker with full ref name
gitweb: Do not show difftree for merges in "commit" view
gitweb: SHA-1 in commit log message links to "object" view
gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
gitweb: Add generic git_object subroutine to display object of any type
gitweb: Show target of symbolic link in "tree" view
gitweb: Don't use Content-Encoding: header in git_snapshot
git-fetch: Avoid reading packed refs over and over again
When checking which tags to fetch, the old code used to call
git-show-ref --verify for each remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out existing
refs using a new mode of operation of git-show-ref.
When using symmetric differences, I think the user almost always
would want to know which side of the symmetry each commit came
from. So this removes --left-right option from the command
line, and turns it on automatically when a symmetric difference
is used ("git log --merge" counts as a symmetric difference
between HEAD and MERGE_HEAD).
Just in case, a new option --no-left-right is provided to defeat
this, but I do not know if it would be useful.
The output from "symmetric diff", i.e. A...B, does not
distinguish between commits that are reachable from A and the
ones that are reachable from B. In this picture, such a
symmetric diff includes commits marked with a and b.
x---b---b branch B
/ \ /
/ .
/ / \
o---x---a---a branch A
However, you cannot tell which ones are 'a' and which ones are
'b' from the output. Sometimes this is frustrating. This adds
an output option, --left-right, to rev-list.
rev-list --left-right A...B
would show ones reachable from A prefixed with '<' and the ones
reachable from B prefixed with '>'.
When combined with --boundary, boundary commits (the ones marked
with 'x' in the above picture) are shown with prefix '-', so you
would see list that looks like this:
Default GIT_COMMITTER_NAME to login name in recieve-pack.
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs
are enabled we would normally die out with an error message asking
the user to correct their environment settings.
Now that reflogs are enabled by default in (what we guessed to be)
non-bare Git repositories this may cause problems for some users
who don't have their full name in the gecos field and who don't
have access to the remote system to correct the problem.
So rather than die()'ing out in receive-pack when we try to log a
ref change and have no committer name we default to the username,
as obtained from the host's password database.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'update-index --replace --add A/B'
did not properly remove the file to make room for the new
directory.
There was a trivial logic error, most likely a cut & paste one,
dating back to quite early days of git.