- 17 4月, 2008 1 次提交
-
-
由 Heikki Orsila 提交于
git init --shared=0xxx, where '0xxx' is an octal number, will create a repository with file modes set to '0xxx'. Users with a safe umask value (0077) can use this option to force file modes. For example, '0640' is a group-readable but not group-writable regardless of user's umask value. Values compatible with old Git versions are written as they were before, for compatibility reasons. That is, "1" for "group" and "2" for "everybody". "git config core.sharedRepository 0xxx" is also handled. Signed-off-by: NHeikki Orsila <heikki.orsila@iki.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 4月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
This new function can be used by config parsers to tell if a variable is simply set, set to 1, or set to "true". Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 3月, 2008 2 次提交
-
-
由 Linus Torvalds 提交于
This is in an effort to make the source index of 'unpack_trees()' as being const, and thus making the compiler help us verify that we only access it for reading. The constification also extended to some of the hashing helpers that get called indirectly. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
This new helper is identical to base_name_compare(), except it compares conflicting directory/file entries as equal in order to help handling DF conflicts (thus the name). Note that while a directory name compares as equal to a regular file with the new helper, they then individually compare _differently_ to a filename that has a dot after the basename (because '\0' < '.' < '/'). So a directory called "foo/" will compare equal to a file "foo", even though "foo.c" will compare after "foo" and before "foo/" This will be used by routines that want to traverse the git namespace but then handle conflicting entries together when possible. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 2月, 2008 2 次提交
-
-
由 Martin Koegler 提交于
The requirements are: * it may not crash on NULL pointers * a callback function is needed, as index-pack/unpack-objects need to do different things * the type information is needed to check the expected <-> real type and print better error messages Signed-off-by: NMartin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Daniel Barkalow 提交于
Originally by Kristian Hï¿œgsberg; I fixed the conversion of rerere, which had a different API. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 2月, 2008 1 次提交
-
-
由 Jeff King 提交于
This converts git_config_alias to the public alias_lookup function. Because of the nature of our config parser, we still have to rely on setting static data. However, that interface is wrapped so that you can just say value = alias_lookup(key); Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 2月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
This is used by git-apply but we can use it elsewhere by slightly generalizing it. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2008 3 次提交
-
-
由 Linus Torvalds 提交于
We used to just memcpy() the index entry when we copied the stat() and SHA1 hash information, which worked well enough back when the index entry was just an exact bit-for-bit representation of the information on disk. However, these days we actually have various management information in the cache entry too, and we should be careful to not overwrite it when we copy the stat information from another index entry. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
This makes the name hash removal function (which really just sets the bit that disables lookups of it) available to external routines, and makes read_cache_unmerged() use it when it drops an unmerged entry from the index. It's renamed to remove_index_entry(), and we drop the (unused) 'istate' argument. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
We handled the case of removing and re-inserting cache entries badly, which is something that merging commonly needs to do (removing the different stages, and then re-inserting one of them as the merged state). We even had a rather ugly special case for this failure case, where replace_index_entry() basically turned itself into a no-op if the new and the old entries were the same, exactly because the hash routines didn't handle it on their own. So what this patch does is to not just have the UNHASHED bit, but a HASHED bit too, and when you insert an entry into the name hash, that involves: - clear the UNHASHED bit, because now it's valid again for lookup (which is really all that UNHASHED meant) - if we're being lazy, we're done here (but we still want to clear the UNHASHED bit regardless of lazy mode, since we can become unlazy later, and so we need the UNHASHED bit to always be set correctly, even if we never actually insert the entry into the hash list) - if it was already hashed, we just leave it on the list - otherwise mark it HASHED and insert it into the list this all means that unhashing and rehashing a name all just works automatically. Obviously, you cannot change the name of an entry (that would be a serious bug), but nothing can validly do that anyway (you'd have to allocate a new struct cache_entry anyway since the name length could change), so that's not a new limitation. The code actually gets simpler in many ways, although the lazy hashing does mean that there are a few odd cases (ie something can be marked unhashed even though it was never on the hash in the first place, and isn't actually marked hashed!). Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 2月, 2008 1 次提交
-
-
由 Jay Soffian 提交于
"git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: NJay Soffian <jaysoffian@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 2月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
This helper function is the core of "$object^{type}" parser. Now it is made available to callers outside sha1_name.c
-
- 16 2月, 2008 4 次提交
-
-
由 Christian Couder 提交于
Also use "git_config_string" to simplify "config.c" code where "excludes_file" is set. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
Also use "git_config_string" to simplify "config.c" code where "editor_program" is set. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
Also use "git_config_string" to simplify "config.c" code where "pager_program" is set. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
In many places we just check if a value from the config file is not NULL, then we duplicate it and return 0. This patch introduces the new 'git_config_string' function to do that. This function is also used to refactor some code in 'config.c'. Refactoring other files is left for other patches. Also not all the code in "config.c" is refactored, because the function takes a "const char **" as its first parameter, but in many places a "char *" is used instead of a "const char *". (And C does not allow using a "char **" instead of a "const char **" without a warning.) Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 2月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
This is used to report misconfigured configuration file that does not give any value to a non-boolean variable, e.g. [section] var It is perfectly fine to say it if the section.var is a boolean (it means true), but if a variable expects a string value it should be flagged as a configuration error. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 2月, 2008 1 次提交
-
-
由 Daniel Barkalow 提交于
It's small, but it was in three places already, so it should be in the library. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
-
- 07 2月, 2008 2 次提交
-
-
由 Jeff King 提交于
The GIT_CONFIG_NOGLOBAL and GIT_CONFIG_NOSYSTEM environment variables are magic undocumented switches that can be used to ensure a totally clean environment. This is necessary for running reliable tests, since those config files may contain settings that change the outcome of tests. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Steffen Prohaska 提交于
CRLF conversion bears a slight chance of corrupting data. autocrlf=true will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data. If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes. Right after committing you still have the original file in your work tree and this file is not yet corrupted. You can explicitly tell git that this file is binary and git will handle the file appropriately. Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs corrupts data. This patch adds a mechanism that can either warn the user about an irreversible conversion or can even refuse to convert. The mechanism is controlled by the variable core.safecrlf, with the following values: - false: disable safecrlf mechanism - warn: warn about irreversible conversions - true: refuse irreversible conversions The default is to warn. Users are only affected by this default if core.autocrlf is set. But the current default of git is to leave core.autocrlf unset, so users will not see warnings unless they deliberately chose to activate the autocrlf mechanism. The safecrlf mechanism's details depend on the git command. The general principles when safecrlf is active (not false) are: - we warn/error out if files in the work tree can modified in an irreversible way without giving the user a chance to backup the original file. - for read-only operations that do not modify files in the work tree we do not not print annoying warnings. There are exceptions. Even though... - "git add" itself does not touch the files in the work tree, the next checkout would, so the safety triggers; - "git apply" to update a text file with a patch does touch the files in the work tree, but the operation is about text files and CRLF conversion is about fixing the line ending inconsistencies, so the safety does not trigger; - "git diff" itself does not touch the files in the work tree, it is often run to inspect the changes you intend to next "git add". To catch potential problems early, safety triggers. The concept of a safety check was originally proposed in a similar way by Linus Torvalds. Thanks to Dimitry Potapov for insisting on getting the naked LF/autocrlf=true case right. Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
-
- 05 2月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
A pattern "foo/" in the exclude list did not match directory "foo", but a pattern "foo" did. This attempts to extend the exclude mechanism so that it would while not matching a regular file or a symbolic link "foo". In order to differentiate a directory and non directory, this passes down the type of path being checked to excluded() function. A downside is that the recursive directory walk may need to run lstat(2) more often on systems whose "struct dirent" do not give the type of the entry; earlier it did not have to do so for an excluded path, but we now need to figure out if a path is a directory before deciding to exclude it. This is especially bad because an idea similar to the earlier CE_UPTODATE optimization to reduce number of lstat(2) calls would by definition not apply to the codepaths involved, as (1) directories will not be registered in the index, and (2) excluded paths will not be in the index anyway. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
This new error mode allows a line to have a carriage return at the end of the line when checking and fixing trailing whitespace errors. Some people like to keep CRLF line ending recorded in the repository, and still want to take advantage of the automated trailing whitespace stripping. We still show ^M in the diff output piped to "less" to remind them that they do have the CR at the end, but these carriage return characters at the end are no longer flagged as errors. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 1月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
This delays the hashing of index names until it becomes necessary for the first time. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
This creates a hash index of every single file added to the index. Right now that hash index isn't actually used for much: I implemented a "cache_name_exists()" function that uses it to efficiently look up a filename in the index without having to do the O(logn) binary search, but quite frankly, that's not why this patch is interesting. No, the whole and only reason to create the hash of the filenames in the index is that by modifying the hash function, you can fairly easily do things like making it always hash equivalent names into the same bucket. That, in turn, means that suddenly questions like "does this name exist in the index under an _equivalent_ name?" becomes much much cheaper. Guiding principles behind this patch: - it shouldn't be too costly. In fact, my primary goal here was to actually speed up "git commit" with a fully populated kernel tree, by being faster at checking whether a file already existed in the index. I did succeed, but only barely: Best before: [torvalds@woody linux]$ time git commit > /dev/null real 0m0.255s user 0m0.168s sys 0m0.088s Best after: [torvalds@woody linux]$ time ~/git/git commit > /dev/null real 0m0.233s user 0m0.144s sys 0m0.088s so some things are actually faster (~8%). Caveat: that's really the best case. Other things are invariably going to be slightly slower, since we populate that index cache, and quite frankly, few things really use it to look things up. That said, the cost is really quite small. The worst case is probably doing a "git ls-files", which will do very little except puopulate the index, and never actually looks anything up in it, just lists it. Before: [torvalds@woody linux]$ time git ls-files > /dev/null real 0m0.016s user 0m0.016s sys 0m0.000s After: [torvalds@woody linux]$ time ~/git/git ls-files > /dev/null real 0m0.021s user 0m0.012s sys 0m0.008s and while the thing has really gotten relatively much slower, we're still talking about something almost unmeasurable (eg 5ms). And that really should be pretty much the worst case. So we lose 5ms on one "benchmark", but win 22ms on another. Pick your poison - this patch has the advantage that it will _likely_ speed up the cases that are complex and expensive more than it slows down the cases that are already so fast that nobody cares. But if you look at relative speedups/slowdowns, it doesn't look so good. - It should be simple and clean The code may be a bit subtle (the reasons I do hash removal the way I do etc), but it re-uses the existing hash.c files, so it really is fairly small and straightforward apart from a few odd details. Now, this patch on its own doesn't really do much, but I think it's worth looking at, if only because if done correctly, the name hashing really can make an improvement to the whole issue of "do we have a filename that looks like this in the index already". And at least it gets real testing by being used even by default (ie there is a real use-case for it even without any insane filesystems). NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just not ashamed of it enough to really care. I took all the numbers out of my nether regions - I'm sure it's good enough that it works in practice, but the whole point was that you can make a really much fancier hash that hashes characters not directly, but by their upper-case value or something like that, and thus you get a case-insensitive hash, while still keeping the name and the index itself totally case sensitive. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 1月, 2008 3 次提交
-
-
由 Junio C Hamano 提交于
Aside from the lstat(2) done for work tree files, there are quite many lstat(2) calls in refname dwimming codepath. This patch is not about reducing them. * It adds a new ce_flag, CE_UPTODATE, that is meant to mark the cache entries that record a regular file blob that is up to date in the work tree. If somebody later walks the index and wants to see if the work tree has changes, they do not have to be checked with lstat(2) again. * fill_stat_cache_info() marks the cache entry it just added with CE_UPTODATE. This has the effect of marking the paths we write out of the index and lstat(2) immediately as "no need to lstat -- we know it is up-to-date", from quite a lot fo callers: - git-apply --index - git-update-index - git-checkout-index - git-add (uses add_file_to_index()) - git-commit (ditto) - git-mv (ditto) * refresh_cache_ent() also marks the cache entry that are clean with CE_UPTODATE. * write_index is changed not to write CE_UPTODATE out to the index file, because CE_UPTODATE is meant to be transient only in core. For the same reason, CE_UPDATE is not written to prevent an accident from happening. Signed-off-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Junio C Hamano 提交于
We currently use lower 12-bit (masked with CE_NAMEMASK) in the ce_flags field to store the length of the name in cache_entry, without checking the length parameter given to create_ce_flags(). This can make us store incorrect length. Currently we are mostly protected by the fact that many codepaths first copy the path in a variable of size PATH_MAX, which typically is 4096 that happens to match the limit, but that feels like a bug waiting to happen. Besides, that would not allow us to shorten the width of CE_NAMEMASK to use the bits for new flags. This redefines the meaning of the name length stored in the cache_entry. A name that does not fit is represented by storing CE_NAMEMASK in the field, and the actual length needs to be computed by actually counting the bytes in the name[] field. This way, only the unusually long paths need to suffer. Signed-off-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
This converts the index explicitly on read and write to its on-disk format, allowing the in-core format to contain more flags, and be simpler. In particular, the in-core format is now host-endian (as opposed to the on-disk one that is network endian in order to be able to be shared across machines) and as a result we can dispense with all the htonl/ntohl on accesses to the cache_entry fields. This will make it easier to make use of various temporary flags that do not exist in the on-disk format. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 18 1月, 2008 1 次提交
-
-
由 Shawn O. Pearce 提交于
fast-import was relying on the fact that on most systems mmap() and write() are synchronized by the filesystem's buffer cache. We were relying on the ability to mmap() 20 bytes beyond the current end of the file, then later fill in those bytes with a future write() call, then read them through the previously obtained mmap() address. This isn't always true with some implementations of NFS, but it is especially not true with our NO_MMAP=YesPlease build time option used on some platforms. If fast-import was built with NO_MMAP=YesPlease we used the malloc()+pread() emulation and the subsequent write() call does not update the trailing 20 bytes of a previously obtained "mmap()" (aka malloc'd) address. Under NO_MMAP that behavior causes unpack_entry() in sha1_file.c to be unable to read an object header (or data) that has been unlucky enough to be written to the packfile at a location such that it is in the trailing 20 bytes of a window previously opened on that same packfile. This bug has gone unnoticed for a very long time as it is highly data dependent. Not only does the object have to be placed at the right position, but it also needs to be positioned behind some other object that has been accessed due to a branch cache invalidation. In other words the stars had to align just right, and if you did run into this bug you probably should also have purchased a lottery ticket. Fortunately the workaround is a lot easier than the bug explanation. Before we allow unpack_entry() to read data from a pack window that has also (possibly) been modified through write() we force all existing windows on that packfile to be closed. By closing the windows we ensure that any new access via the emulated mmap() will reread the packfile, updating to the current file content. This comes at a slight performance degredation as we cannot reuse previously cached windows when we update the packfile. But it is a fairly minor difference as the window closes happen at only two points: - When the packfile is finalized and its .idx is generated: At this stage we are getting ready to update the refs and any data access into the packfile is going to be random, and is going after only the branch tips (to ensure they are valid). Our existing windows (if any) are not likely to be positioned at useful locations to access those final tip commits so we probably were closing them before anyway. - When the branch cache missed and we need to reload: At this point fast-import is getting change commands for the next commit and it needs to go re-read a tree object it previously had written out to the packfile. What windows we had (if any) are not likely to cover the tree in question so we probably were closing them before anyway. We do try to avoid unnecessarily closing windows in the second case by checking to see if the packfile size has increased since the last time we called unpack_entry() on that packfile. If the size has not changed then we have not written additional data, and any existing window is still vaild. This nicely handles the cases where fast-import is going through a branch cache reload and needs to read many trees at once. During such an event we are not likely to be updating the packfile so we do not cycle the windows between reads. With this change in place t9301-fast-export.sh (which was broken by c3b0dec5) finally works again. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2008 1 次提交
-
-
由 Brandon Casey 提交于
The lockfile API is a handy way to obtain a file that is cleaned up if you die(). But sometimes you would need this sequence to work: 1. hold_lock_file_for_update() to get a file descriptor for writing; 2. write the contents out, without being able to decide if the results should be committed or rolled back; 3. do something else that makes the decision --- and this "something else" needs the lockfile not to have an open file descriptor for writing (e.g. Windows do not want a open file to be renamed); 4. call commit_lock_file() or rollback_lock_file() as appropriately. This adds close_lock_file() you can call between step 2 and 3 in the above sequence. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 12月, 2007 1 次提交
-
-
由 Wincent Colaiuta 提交于
This commit unifies three separate places where whitespace checking was performed: - the whitespace checking previously done in builtin-apply.c is extracted into a function in ws.c - the equivalent logic in "git diff" is removed - the emit_line_with_ws() function is also removed because that also rechecks the whitespace, and its functionality is rolled into ws.c The new function is called check_and_emit_line() and it does two things: checks a line for whitespace errors and optionally emits it. The checking is based on lines of content rather than patch lines (in other words, the caller must strip the leading "+" or "-"); this was suggested by Junio on the mailing list to allow for a future extension to "git show" to display whitespace errors in blobs. At the same time we teach it to report all classes of whitespace errors found for a given line rather than reporting only the first found error. Signed-off-by: NWincent Colaiuta <win@wincent.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 12月, 2007 1 次提交
-
-
由 Jeff King 提交于
When deciding whether or not to turn on automatic color support, git_config_colorbool checks whether stdout is a tty. However, because we run a pager, if stdout is not a tty, we must check whether it is because we started the pager. This used to be done by checking the pager_in_use variable. This variable was set only when the git program being run started the pager; there was no way for an external program running git indicate that it had already started a pager. This patch allows a program to set GIT_PAGER_IN_USE to a true value to indicate that even though stdout is not a tty, it is because a pager is being used. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 12月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
An earlier fix to the said commit was incomplete; it mixed up the meaning of the flag parameter passed to the internal fmt_ident() function, so this corrects it. git_author_info() and git_committer_info() can be told to issue a warning when no usable user information is found, and optionally can be told to error out. Operations that actually use the information to record a new commit or a tag will still error out, but the caller to leave reflog record will just silently use bogus user information. Not warning on misconfigured user information while writing a reflog entry is somewhat debatable, but it is probably nicer to the users to silently let it pass, because the only information you are losing is who checked out the branch. * git_author_info() and git_committer_info() used to take 1 (positive int) to error out with a warning on misconfiguration; this is now signalled with a symbolic constant IDENT_ERROR_ON_NO_NAME. * These functions used to take -1 (negative int) to warn but continue; this is now signalled with a symbolic constant IDENT_WARN_ON_NO_NAME. * fmt_ident() function implements the above error reporting behaviour common to git_author_info() and git_committer_info(). A symbolic constant IDENT_NO_DATE can be or'ed in to the flag parameter to make it return only the "Name <email@address.xz>". * fmt_name() is a thin wrapper around fmt_ident() that always passes IDENT_ERROR_ON_NO_NAME and IDENT_NO_DATE. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 12月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
The `core.whitespace` configuration variable allows you to define what `diff` and `apply` should consider whitespace errors for all paths in the project (See gitlink:git-config[1]). This attribute gives you finer control per path. For example, if you have these in the .gitattributes: frotz whitespace nitfol -whitespace xyzzy whitespace=-trailing all types of whitespace problems known to git are noticed in path 'frotz' (i.e. diff shows them in diff.whitespace color, and apply warns about them), no whitespace problem is noticed in path 'nitfol', and the default types of whitespace problems except "trailing whitespace" are noticed for path 'xyzzy'. A project with mixed Python and C might want to have: *.c whitespace *.py whitespace=-indent-with-non-tab in its toplevel .gitattributes file. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 12月, 2007 1 次提交
-
-
由 Christian Couder 提交于
Now that str_buf takes care of all the allocations, there is no more gain to pass an argument count. So this patch removes the "count" argument from: - "sq_quote_argv" - "trace_argv_printf" and all the callers. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 12月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
Introduce fmt_name() specifically meant for formatting the name and email pair, to add signed-off-by value. This reverts parts of 13208572 (builtin-commit: fix --signoff) so that an empty datestamp string given to fmt_ident() by mistake will error out as before. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 12月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
When we consider if a path has been totally rewritten, we did not touch changes from symlinks to files or vice versa. But a change that modifies even the type of a blob surely should count as a complete rewrite. While we are at it, modernise diffcore-break to be aware of gitlinks (we do not want to touch them). Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 11月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
This separates the logic to limit the extent of change to the index by where you are (controlled by "prefix") and what you specify from the command line (controlled by "pathspec"). Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
This exports three helper functions from ls-files. * pathspec_match() checks if a given path matches a set of pathspecs and optionally records which pathspec was used. This function used to be called "match()" but renamed to be a bit less vague. * report_path_error() takes a set of pathspecs and the record pathspec_match() above leaves, and gives error message. This was split out of the main function of ls-files. * overlay_tree_on_cache() takes a tree-ish (typically "HEAD") and overlays it on the current in-core index. By iterating over the resulting index, the caller can find out the paths in either the index or the HEAD. This function used to be called "overlay_tree()" but renamed to be a bit more descriptive. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 11月, 2007 1 次提交
-
-
由 Steffen Prohaska 提交于
The old rules used by fetch were coded as a series of ifs. The old rules are: 1) match full refname if it starts with "refs/" or matches "HEAD" 2) verify that full refname starts with "refs/" 3) match abbreviated name in "refs/" if it starts with "heads/", "tags/", or "remotes/". 4) match abbreviated name in "refs/heads/" This is replaced by the new rules a) match full refname b) match abbreviated name prefixed with "refs/" c) match abbreviated name prefixed with "refs/heads/" The details of the new rules are different from the old rules. We no longer verify that the full refname starts with "refs/". The new rule (a) matches any full string. The old rules (1) and (2) were stricter. Now, the caller is responsible for using sensible full refnames. This should be the case for the current code. The new rule (b) is less strict than old rule (3). The new rule accepts abbreviated names that start with a non-standard prefix below "refs/". Despite this modifications the new rules should handle all cases as expected. Two tests are added to verify that fetch does not resolve short tags or HEAD in remotes. We may even think about loosening the rules a bit more and unify them with the rev-parse rules. This would be done by replacing ref_ref_fetch_rules with ref_ref_parse_rules. Note, the two new test would break. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-