Make the --force-remove flag behave same as --add, --remove and
--replace. This means I can do
git-update-cache --force-remove -- file1.c file2.c
which is probably saner and also makes it easier to use in cg-rm.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We still refuse to add ".", ".." and ".git".
In theory, you could track another git-repository by allowing ".git",
but the potential for confusion is just too high.
Fix various things that sparse complains about:
- use NULL instead of 0
- make sure we declare everything properly, or mark it static
- use proper function declarations ("fn(void)" instead of "fn()")
Sparse is always right.
Fixes all in-code names that leaved during "big name change".
Signed-off-by: Alexey Nezhdanov <snake@penza-gsm.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With -u flag, git-checkout-cache picks up the stat information
from newly created file and updates the cache. This removes the
need to run git-update-cache --refresh immediately after running
git-checkout-cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
this patch fixes a 1-byte overflow in update-cache.c (probably not
exploitable). A specially crafted db object might trigger this overflow.
the bug is that normally the 'type' field is parsed by read_sha1_file(),
via:
if (sscanf(buffer, "%10s %lu", type, size) != 2)
i.e. 0-10 long strings, which take 1-11 bytes of space. Normally the
type strings are stored in char [20] arrays, but in update-cache.c that
is char [10], so a 1 byte overflow might occur.
This should not happen with a 'friendly' DB, as the longest type string
("commit") is 7 bytes long. The fix is to use the customary char [20].
(someone might want to clean those open-coded constants up with a
TYPE_LEN define, they do tend to cause problems like this. I'm not
against open-coded constants (they make code much more readable), but
for fields that get filled in from possibly hostile objects this is
playing with fire.)
hey, this might be the first true security fix for GIT? ;-)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Petr Baudis <pasky@ucw.cz>
When we used to have "path" as a file or a symlink, but now we
have "path/file" (or in general, have "path" as a directory), we
would want to remove "path" before adding "path/file". The
logic in add_file_to_cache() only runs lstat() and does not
detect this case and fails to allow removing it in this case.
In the opposite case of having "path/file" in the index and
having "path" on the filesystem as a file or a symlink we do
allow removal of "path/file", so to be symmetric we should allow
it as well, without forcing the user to say --force-remove.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When "path" exists as a file or a symlink in the index, an
attempt to add "path/file" is refused because it results in file
vs directory conflict. Similarly when "path/file1",
"path/file2", etc. exist, an attempt to add "path" as a file or
a symlink is refused. With git-update-cache --replace, these
existing entries that conflict with the entry being added are
automatically removed from the cache, with warning messages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It didn't properly mark all cache updates as being dirty, and
causes merge errors due to that. In particular, it didn't notice
when a file was force-removed.
Besides, it was ugly as hell. I've put in place a slightly cleaner
version, but I've not enabled the optimization because I don't
want to be burned again.
Fix update-cache to compare the blob of a symlink against the link-target
and not the file it points to. Also ignore all permissions applied to
links.
Thanks to Greg for recognizing this while he added our list of symlinks
back to the udev repository.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The git-update-cache command, especially with --refresh, may not change
anything. In such a case, writing 1.6MB of the same thing is a waste.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow to store and track symlink in the repository. A symlink is stored
the same way as a regular file, only with the appropriate mode bits set.
The symlink target is therefore stored in a blob object.
This will hopefully make our udev repository fully functional. :)
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This new flag tells git-update-cache to remove the named path even
when the work tree still happens to have the file. It is used to
update git-merge-one-file-script not to smudge the work tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A new command, git-write-blob, is introduced. This registers
the contents of any file on the filesystem as a blob in the
object database and reports its SHA1 to the standard output.
To implement it, the patch promotes index_fd() from a static
function in update-cache.c to extern and moves it to a library
source, sha1_file.c.
This command is used to update git-merge-one-file-script so that
it does not smudge the work tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Scripts may find it useful if they do not have to parse the
output from the command but just can rely on its exit status.
Earlier both Linus and myself thought this would be necessary to
make git-prune-script safer but it turns out that the issue was
somewhere else and not related to what this patch addresses.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I found this during a conflict merge testing. The original did
not have either DF (a file) or DF/DF (a file DF/DF under a
directory DF). One side created DF, the other created DF/DF. I
first resolved DF as a new file by taking what the first side
did. After that, the entry DF/DF cannot be resolved by running
git-update-cache --remove although it does not exist on the
filesystem.
$ /bin/ls -F
AN DF MN NM NN SS Z/
$ git-ls-files --stage | grep DF
100644 71420ab81e254145d26d6fc0cddee64c1acd4787 0 DF
100644 68a6d8b91da11045cf4aa3a5ab9f2a781c701249 2 DF/DF
$ git-update-cache --remove DF/DF
fatal: Unable to add DF/DF to database
It turns out that the errno from open() in this case was not
ENOENT but ENOTDIR, which the code did not check. Here is a
fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Introduce xmalloc and xrealloc to die gracefully with a descriptive
message when out of memory, rather than taking a SIGSEGV.
Signed-off-by: Christopher Li<chrislgit@chrisli.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds an --ignore-missing option to update-cache, which makes it
ignore missing files. Together with the "-n" option to checkout-cache,
it allows me to do
checkout-cache -n -f -a && update-cache --ignore-missing --refresh
which only updates and refreshes the files I already have checked out.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We use that to specify alternative index files, which can be useful
if you want to (for example) generate a temporary index file to do
some specific operation that you don't want to mess with your main
one with.
It defaults to the regular ".git/index" if it hasn't been specified.
The "update-cache --refresh" command attempts refresh_entry()
on unmerged path, which results in as many "needs update" messages
as there are unmerged stages for that path. This does not do
any harm to the working directory, but it is confusing.
Here is a fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The function index_fd() in update-cache.c takes 5 arguments, but
two is not necessary and one that is a pointer to a structure
really needs to be a pointer to one member of that structure.
This patch cleans it up.
Also it removes printf() apparently left after initial
debugging.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This allows using a git tree over NFS with different byte order, and
makes it possible to just copy a fully populated repository and have
the end result immediately usable (needing just a refresh to update
the stat information).
It seems like the nsec portability is limited; in particular, older
glibcs (<=2.2.4 at least) don't seem to like it. So access the nsec
fields in struct stat only when -DNSEC.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Now there is error() for "library" errors and die() for fatal "application"
errors. usage() is now used strictly only for usage errors.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
refresh the "stat" information.
We need this after having done a "read-tree", for example, when the
stat information does not match the checked-out tree, and we want to
start getting efficient cache matching against the parts of the tree
that are already up-to-date.
It now requires the "--add" flag before you add any new files, and
a "--remove" file if you want to mark files for removal. And giving
it the "--refresh" flag makes it just update all the files that it
already knows about.
It finds the cache entry position for a given name, and is
generally useful. Sure, everybody can just scan the active
cache array, but since it's sorted, you actually want to
search it with a binary search, so let's not duplicate that
logic all over the place.
The tool interface sucks (especially "committing" information, which is just
me doing everything by hand from the command line), but I think this is in
theory actually a viable way of describing the world. So copyright it.
Petr Baudis