We allow otherwise ignored paths to be added to the index by
spelling its path out on the command line, but we would warn the
user about them when we do so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
One thing many people found confusing about git-add was that a
file whose name matches an ignored pattern could not be added to
the index. With this, such a file can be added by explicitly
spelling its name to git-add.
Fileglobs and recursive behaviour do not add ignored files to
the index. That is, if a pattern '*.o' is in .gitignore, and
two files foo.o, bar/baz.o are in the working tree:
$ git add foo.o
$ git add '*.o'
$ git add bar
Only the first form adds foo.o to the index.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the "git rm" command with saner semantics suggested
on the list earlier with:
Message-ID: <Pine.LNX.4.64.0612020919400.3476@woody.osdl.org>
Message-ID: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org>
The command still validates that the given paths all talk about
sensible paths to avoid mistakes (e.g. "git rm fiel" when file
"fiel" does not exist would error out -- user meant to remove
"file"), and it has further safety checks described next. The
biggest difference is that the paths are removed from both index
and from the working tree (if you have an exotic need to remove
paths only from the index, you can use the --cached option).
The command refuses to remove if the copy on the working tree
does not match the index, or if the index and the HEAD does not
match. You can defeat this check with -f option.
This safety check has two exceptions: if the working tree file
does not exist to begin with, that technically does not match
the index but it is allowed. This is to allow this CVS style
command sequence:
rm <path> && git rm <path>
Also if the index is unmerged at the <path>, you can use "git rm
<path>" to declare that the result of the merge loses that path,
and the above safety check does not trigger; requiring the file
to match the index in this case forces the user to do "git
update-index file && git rm file", which is just crazy.
To recursively remove all contents from a directory, you need to
pass -r option, not just the directory name as the <path>.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the return value from match_pathspec() so that the
caller can tell cases between exact match, leading pathname
match (i.e. file "foo/bar" matches a pathspec "foo"), or
filename glob match. This can be used to prevent "rm dir" from
removing "dir/file" without explicitly asking for recursive
behaviour with -r flag, for example.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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".
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
Paginate commit/author/committer search output to only show 100 commits
at a time, added appropriate nav links.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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:
$ git mege sideb~1
<<<<<<< HEAD:INSTALL
Good!
=======
Oops.
>>>>>>> sideb~1:INSTALL
[jc: adjusted a test script and a minor constness glitch.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
Use rev-list pattern search options instead of hand coded perl.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't need to call git_get_head_hash at all just pass in "HEAD" and
use the return id field.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't call gitweb_have_snapshot from within the loop.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only return one line of output and we don't need the refname value.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
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" (313ce8cee6) is
missing. Add it back in.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
dcommit does commits and fetches, so all options used for those
should work, too, including --authors-file.
Reported missing by Nicolas Vilz.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code no longer uses it, as we have --inaccurate-eof in
git-apply.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to support specifying the top part of remote URL in
remotes and use that as a short-hand for the URL.
$ cat .git/remotes/jgarzik
URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
$ git pull jgarzik/misc-2.6
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have a static allocation of MAXPARENT, but that limit was not
enforced, other than by a lucky invocation of the program segfaulting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The perl version used modules which are non-standard in some setups.
This patch brings the full power of rerere to a wider audience.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
read_file() was a useful function if you want to work with the xdiff stuff,
so it was renamed and put into a more central place.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This imitates the behaviour of git-commit.
Noticed by Han-Wen Nienhuys.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit a71fb0a141.
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>
