This changes semantics very subtly, because it adds a new atomicity
guarantee.
In particular, if you "git rm" several files, it will now do all or
nothing. The old shell-script really looped over the removed files one by
one, and would basically randomly fail in the middle if "-f" was used and
one of the files didn't exist in the working directory.
This C builtin one will not re-write the index after each remove, but
instead remove all files at once. However, that means that if "-f" is used
(to also force removal of the file from the working directory), and some
files have already been removed from the workspace, it won't stop in the
middle in some half-way state like the old one did.
So what happens is that if the _first_ file fails to be removed with "-f",
we abort the whole "git rm". But once we've started removing, we don't
leave anything half done. If some of the other files don't exist, we'll
just ignore errors of removal from the working tree.
This is only an issue with "-f", of course.
I think the new behaviour is strictly an improvement, but perhaps more
importantly, it is _different_. As a special case, the semantics are
identical for the single-file case (which is the only one our test-suite
seems to test).
The other question is what to do with leading directories. The old "git
rm" script didn't do anything, which is somewhat inconsistent. This one
will actually clean up directories that have become empty as a result of
removing the last file, but maybe we want to have a flag to decide the
behaviour?
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since large quilt trees like -mm can easily have patches
without clear authorship information, add a --dry-run
option to make the problem patches easy to find.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Importing a quilt patch series into git is not very difficult
but parsing the patch descriptions and all of the other
minutia take a bit of effort to get right, so this automates it.
Since git and quilt complement each other it makes sense
to make it easy to go back and forth between the two.
If a patch is encountered that it cannot derive the author
from the user is asked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* ts/doctar:
Documentation/Makefile: create tarballs for the man pages and html files
SubmittingPatches: The download location of External Editor has moved
Make git-check-format-ref a builtin.
Make "git rev-list" be a builtin
builtin-diff: do not say files are renamed when blob and file are given
Provide a way to flush git-diff-tree's output
[jc: rewrote by stealing from what I run to update html and
man branches automatically]
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was surprisingly easy. The diff is truly minimal: rename "main()" to
"cmd_rev_list()" in rev-list.c, and rename the whole file to reflect its
new built-in status.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this one, it's now a fatal error to try to add a pathname
that cannot be added with "git add", i.e.
[torvalds@g5 git]$ git add .git/config
fatal: unable to add .git/config to index
and
[torvalds@g5 git]$ git add foo/../bar
fatal: unable to add foo/../bar to index
instead of the old "Ignoring path xyz" warning that would end up
silently succeeding on any other paths.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git add Documentation/" when Documentation directory exists
does not barf (as it should not), but "git add ." barfed when it
did not add anything. This was because we checked for the path
prefix ("Documentation/" in the former case, and an empty string
in the latter case) for existence, and lstat("", &st) would say
"Huh?".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Gitk wants to use git-diff-tree as a filter to tell it which ids from
a given list affect a set of files or directories. We don't want to
fork and exec a new git-diff-tree process for each batch of ids, since
there could be a lot of relatively small batches. For example, a
batch could contain as many ids as fit in gitk's headline display
window, i.e. 20 or so, and we would be processing a new batch every
time the user scrolls that window.
The --stdin flag to git-diff-tree is suitable for this, but the main
difficulty is that the output of git-diff-tree gets buffered and
doesn't get sent until the buffer is full.
This provides a way to get git-diff-tree to flush its output buffers.
If a blank line is supplied on git-diff-tree's standard input, it will
flush its output buffers and then accept further input.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes the pserver says "Removed" instead of "Remove-entry".
Signed-off-by: Elrond <elrond+kernel.org@samba-tng.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The --cached mode does not deal with the working tree, so we
should not check it with lstat. An earlier code omitted the
call to lstat but forgot to omit the check for the errno.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Of course, it still ignores the fact that not all grep's support some of
the flags like -F/-L/-A/-C etc, but for those cases, the external grep
itself will happily just say "unrecognized option -F" or similar.
So with this change, "git grep" should handle all the flags the native
grep handles, which is really quite fine. We don't _need_ to expose
anything more, and if you do want our extensions, you can get them with
"--uncached" and an up-to-date index.
No configuration necessary, and we automatically take advantage of any
native grep we have, if possible.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* lt/dirwalk:
builtin-add: warn on unmatched pathspecs
Do "git add" as a builtin
Clean up git-ls-file directory walking library interface
libify git-ls-files directory traversal
Not a conflict, but builtin-add needed to be adjusted to properly
invalidate the cache_tree entry.
This is in the same spirit as what bba319b5 and 45e48120 tried
to do to help users. A command such as "git add Documentaiton"
with misspelled pathspecs would give a friendly reminder with
this.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
First try. Let's see how well this works.
In many ways, the hard parts of "git commit" are not so different from
this, and a builtin commit would share a lot of the code, I think.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This does not change the logic but moves the order of checks
around so that merging of read-tree safety code would become
easier.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some implementations do not know what to do with -H; define
NO_H_OPTION_IN_GREP when you build git if your grep lacks -H.
Most of the time, it can be worked around by prepending
/dev/null to the argument list, but that causes -L and -c to
slightly misbehave (they both expose /dev/null is given), so
when these options are given, do not run external grep that does
not understand -H.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the code to add the per-directory ignore files for the base
directory into the library routine.
That not only allows us to turn the function push_exclude_per_directory()
static again, it also simplifies the library interface a lot (the caller
no longer needs to worry about any of the per-directory exclude files at
all).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the core directory traversal and filename exclusion logic
into the general git library, making it available for other users
directly.
If we ever want to do "git commit" or "git add" as a built-in (and we
do), we want to be able to handle most of git-ls-files as a library.
NOTE! Not all of git-ls-files is libified by this. The index matching
and pathspec prefix calculation is still in ls-files.c, but this is a
big part of it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a merge results in a creation of a path that did not exist
in HEAD, and if you already have that path on the working tree,
because the index has not been told about the working tree file,
read-tree happily removes it. The issue was brought up by Santi
Béjar on the list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
