summaryrefslogtreecommitdiff
path: root/apply.c
Commit message (Collapse)AuthorAgeFilesLines
* apply: use SWAP macroRené Scharfe2017-01-301-16/+7
| | | | | | | | Use the exported macro SWAP instead of the file-scoped macro swap and remove the latter's definition. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* hold_locked_index(): align error handling with hold_lockfile_for_update()Junio C Hamano2016-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Callers of the hold_locked_index() function pass 0 when they want to prepare to write a new version of the index file without wishing to die or emit an error message when the request fails (e.g. somebody else already held the lock), and pass 1 when they want the call to die upon failure. This option is called LOCK_DIE_ON_ERROR by the underlying lockfile API, and the hold_locked_index() function translates the paramter to LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update(). Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop translating. Callers other than the ones that are replaced with this change pass '0' to the function; no behaviour change is intended with this patch. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Among the callers of hold_locked_index() that passes 0: - diff.c::refresh_index_quietly() at the end of "git diff" is an opportunistic update; it leaks the lockfile structure but it is just before the program exits and nobody should care. - builtin/describe.c::cmd_describe(), builtin/commit.c::cmd_status(), sequencer.c::read_and_refresh_cache() are all opportunistic updates and they are OK. - builtin/update-index.c::cmd_update_index() takes a lock upfront but we may end up not needing to update the index (i.e. the entries may be fully up-to-date), in which case we do not need to issue an error upon failure to acquire the lock. We do diagnose and die if we indeed need to update, so it is OK. - wt-status.c::require_clean_work_tree() IS BUGGY. It asks silence, does not check the returned value. Compare with callsites like cmd_describe() and cmd_status() to notice that it is wrong to call update_index_if_able() unconditionally.
* i18n: apply: mark error message for translationVasco Almeida2016-10-171-2/+2
| | | | | | | Update test to reflect changes. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* i18n: apply: mark error messages for translationVasco Almeida2016-10-141-24/+24
| | | | | | | | Mark error messages for translation passed to error() and die() functions. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* i18n: apply: mark info messages for translationVasco Almeida2016-10-141-4/+4
| | | | | | | Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* i18n: apply: mark plural string for translationVasco Almeida2016-10-141-4/+6
| | | | | | | Mark plural string for translation using Q_(). Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* introduce CHECKOUT_INITrs/checkout-init-macroRené Scharfe2016-09-221-3/+1
| | | | | | | | | Add a static initializer for struct checkout and use it throughout the code base. It's shorter, avoids a memset(3) call and makes sure the base_dir member is initialized to a valid (empty) string. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'bc/object-id'Junio C Hamano2016-09-191-215/+215
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "unsigned char sha1[20]" to "struct object_id" conversion continues. Notable changes in this round includes that ce->sha1, i.e. the object name recorded in the cache_entry, turns into an object_id. It had merge conflicts with a few topics in flight (Christian's "apply.c split", Dscho's "cat-file --filters" and Jeff Hostetler's "status --porcelain-v2"). Extra sets of eyes double-checking for mismerges are highly appreciated. * bc/object-id: builtin/reset: convert to use struct object_id builtin/commit-tree: convert to struct object_id builtin/am: convert to struct object_id refs: add an update_ref_oid function. sha1_name: convert get_sha1_mb to struct object_id builtin/update-index: convert file to struct object_id notes: convert init_notes to use struct object_id builtin/rm: convert to use struct object_id builtin/blame: convert file to use struct object_id Convert read_mmblob to take struct object_id. notes-merge: convert struct notes_merge_pair to struct object_id builtin/checkout: convert some static functions to struct object_id streaming: make stream_blob_to_fd take struct object_id builtin: convert textconv_object to use struct object_id builtin/cat-file: convert some static functions to struct object_id builtin/cat-file: convert struct expand_data to use struct object_id builtin/log: convert some static functions to use struct object_id builtin/blame: convert struct origin to use struct object_id builtin/apply: convert static functions to struct object_id cache: convert struct cache_entry to use struct object_id
* | apply: learn to use a different index fileChristian Couder2016-09-071-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes we want to apply in a different index file. Before the apply functionality was libified it was possible to use the GIT_INDEX_FILE environment variable, for this purpose. But now, as the apply functionality has been libified, it should be possible to do that in a libified way. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: pass apply state to build_fake_ancestor()Christian Couder2016-09-071-4/+5
| | | | | | | | | | | | | | | | | | | | To libify git apply functionality, we will need to read from a different index file in get_current_sha1(). This index file will be stored in "struct apply_state", so let's pass the state to build_fake_ancestor() which will later pass it to get_current_sha1(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: refactor `git apply` option parsingChristian Couder2016-09-071-13/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parsing `git apply` options can be useful to other commands that want to call the libified apply functionality, because this way they can easily pass some options from their own command line to the libified apply functionality. This will be used by `git am` in a following patch. To make this possible, let's refactor the `git apply` option parsing code into a new libified apply_parse_options() function. Doing that makes it possible to remove some functions definitions from "apply.h" and make them static in "apply.c". Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: change error_routine when silentChristian Couder2016-09-071-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid printing anything when applying with `state->apply_verbosity == verbosity_silent`, let's save the existing warn and error routines before applying, and let's replace them with a routine that does nothing. Then after applying, let's restore the saved routines. Note that, as we need to restore the saved routines in all cases, we cannot return early any more in apply_all_patches(). Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: don't print on stdout in verbosity_silent modeChristian Couder2016-09-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When apply_verbosity is set to verbosity_silent nothing should be printed on both stderr and stdout. To avoid printing on stdout, we can just skip calling the following functions: - stat_patch_list(), - numstat_patch_list(), - summary_patch_list(). It is safe to do that because the above functions have no side effects other than printing: - stat_patch_list() only computes some local values and then call show_stats() and print_stat_summary(), those two functions only compute local values and call printing functions, - numstat_patch_list() also only computes local values and calls printing functions, - summary_patch_list() calls show_file_mode_name(), printf(), show_rename_copy(), show_mode_change() that are only printing. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: make it possible to silently applyChristian Couder2016-09-071-22/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes 'int apply_verbosely' into 'enum apply_verbosity', and changes the possible values of the variable from a bool to a tristate. The previous 'false' state is changed into 'verbosity_normal'. The previous 'true' state is changed into 'verbosity_verbose'. The new added state is 'verbosity_silent'. It should prevent anything to be printed on both stderr and stdout. This is needed because `git am` wants to first call apply functionality silently, if it can then fall back on 3-way merge in case of error. Printing on stdout, and calls to warning() or error() are not taken care of in this patch, as that will be done in following patches. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: use error_errno() where possibleChristian Couder2016-09-071-8/+8
| | | | | | | | | | | | | | | | To avoid possible mistakes and to uniformly show the errno related messages, let's use error_errno() where possible. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: make some parsing functions static againChristian Couder2016-09-071-3/+3
| | | | | | | | | | | | | | | | | | Some parsing functions that were used in both "apply.c" and "builtin/apply.c" are now only used in the former, so they can be made static to "apply.c". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: move libified code from builtin/apply.c to apply.{c,h}Christian Couder2016-09-071-0/+4731
| | | | | | | | | | | | | | | | | | | | | | As most of the apply code in builtin/apply.c has been libified by a number of previous commits, it can now be moved to apply.{c,h}, so that more code can use it. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin/apply: move check_apply_state() to apply.cChristian Couder2016-08-111-0/+32
| | | | | | | | | | | | | | | | | | | | To libify `git apply` functionality we must make check_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into "apply.c". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply: make init_apply_state() return -1 instead of exit()ingChristian Couder2016-08-111-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", init_apply_state() should return -1 instead of calling exit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | builtin/apply: move init_apply_state() to apply.cChristian Couder2016-08-111-0/+94
|/ | | | | | | | | | | To libify `git apply` functionality we must make init_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into a new "apply.c". Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Builtin git-apply.Peter Eriksen2006-05-231-2299/+0
| | | | | Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply --cached: do not check newly added file in the working treeJunio C Hamano2006-05-171-4/+6
| | | | | | | | 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>
* apply --cached: apply a patch without using working tree.Junio C Hamano2006-05-151-20/+52
| | | | | | | | A new flag "--cached" takes the cached data, applies the patch and stores the result in the index, without using the working tree. Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply --numstat: show new name, not old name.Junio C Hamano2006-05-151-1/+1
| | | | | | | Somehow --stat showed the new name but --numstat showed the old name for renamed/copied paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'jc/bindiff'Junio C Hamano2006-05-091-61/+237
|\ | | | | | | | | | | | | | | * jc/bindiff: improve base85 generated assembly code binary diff and apply: testsuite. binary diff: further updates. binary patch.
| * binary diff: further updates.Junio C Hamano2006-05-051-33/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates the user interface and generated diff data format. * "diff --binary" is used to signal that we want an e-mailable binary patch. It implies --full-index and -p. * "apply --allow-binary-replacement" acquired a short synonym "apply --binary". * After the "GIT binary patch\n" header line there is a token to record which binary patch mechanism was used, so that we can extend it later. Currently there are two mechanisms defined: "literal" and "delta". The former records the deflated postimage and the latter records the deflated delta from the preimage to postimage. For purely implementation convenience, I added the deflated length after these "literal/delta" tokens (otherwise the decoding side needs to guess and reallocate the buffer while inflating). Improvement patches are very welcomed. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * binary patch.Junio C Hamano2006-05-051-60/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds "binary patch" to the diff output and teaches apply what to do with them. On the diff generation side, traditionally, we said "Binary files differ\n" without giving anything other than the preimage and postimage object name on the index line. This was good enough for applying a patch generated from your own repository (very useful while rebasing), because the postimage would be available in such a case. However, this was not useful when the recipient of such a patch via e-mail were to apply it, even if the preimage was available. This patch allows the diff to generate "binary" patch when operating under --full-index option. The binary patch follows the usual extended git diff headers, and looks like this: "GIT binary patch\n" <length byte><data>"\n" ... "\n" Each line is prefixed with a "length-byte", whose value is upper or lowercase alphabet that encodes number of bytes that the data on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ..., 'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of 5-byte sequence, each of which encodes up to 4 bytes in base85 encoding. Because 52 / 4 * 5 = 65 and we have the length byte, an output line is capped to 66 characters. The payload is the same diff-delta as we use in the packfiles. On the consumption side, git-apply now can decode and apply the binary patch when --allow-binary-replacement is given, the diff was generated with --full-index, and the receiving repository has the preimage blob, which is the same condition as it always required when accepting an "Binary files differ\n" patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | apply: fix infinite loop with multiple patches with --indexEric Wong2006-05-091-9/+9
|/ | | | | | | | | | | | When multiple patches are passed to git-apply, it will attempt to open multiple file descriptors to an index, which means multiple entries will be in the circular cache_file_list. This change makes git-apply only open the index once and write the index at exit. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Implement limited context matching in git-apply.Eric W. Biederman2006-04-101-18/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ok this really should be the good version. The option handling has been reworked to be automation safe. Currently to import the -mm tree I have to work around git-apply by using patch. Because some of Andrews patches in quilt will only apply with fuzz. I started out implementing a --fuzz option and then I realized fuzz is not a very safe concept for an automated system. What you really want is a minimum number of context lines that must match. This allows policy to be set without knowing how many lines of context a patch actually provides. By default the policy remains to match all provided lines of context. Allowng git-apply to match a restricted set of context makes it much easier to import the -mm tree into git. I am still only processing 1.5 to 1.6 patches a second for the 692 patches in 2.6.17-rc1-mm2 is still painful but it does help. If I just loop through all of Andrews patches in order and run git-apply --index -C1 I process the entire patchset in 1m53s or about 6 patches per second. So running git-mailinfo, git-write-tree, git-commit-tree, and git-update-ref everytime has a measurable impact, and shows things can be speeded up even more. All of these timings were taking on my poor 700Mhz Athlon with 512MB of ram. So people with fast machiens should see much better performance. When a match is found after the number of context are reduced a warning is generated. Since this is a rare event and possibly dangerous this seems to make sense. Unless you are patching a single file the error message is a little bit terse at the moment, but it should be easy to go back and fix. I have also updated the documentation for git-apply to reflect the new -C option that sets the minimum number of context lines that must match. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Replace xmalloc+memset(0) with xcalloc.Peter Eriksen2006-04-041-6/+3
| | | | | Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use blob_, commit_, tag_, and tree_type throughout.Peter Eriksen2006-04-041-2/+3
| | | | | | | | | This replaces occurences of "blob", "commit", "tag", and "tree", where they're really used as type specifiers, which we already have defined global constants for. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: safety fixesLinus Torvalds2006-03-251-1/+3
| | | | | | | | | | | | | | | | | | | This was triggered by me testing the "@@" numbering shorthand by GNU patch, which not only showed that git-apply thought it meant the number was duplicated (when it means that the second number is 1), but my tests showed than when git-apply mis-understood the number, it would then not raise an alarm about it if the patch ended early. Now, this doesn't actually _matter_, since with a three-line context, the only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in which case git-apply got it right), but the fact that git-apply would also silently accept truncated patches was a missed opportunity for additional sanity-checking. So make git-apply refuse to look at a patch fragment that ends early. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: do not barf when updating an originally empty file.Junio C Hamano2006-03-221-1/+1
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))Junio C Hamano2006-03-091-1/+1
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add --temp and --stage=all options to checkout-index.Shawn Pearce2006-03-051-1/+2
| | | | | | | | | | | | Sometimes it is convient for a Porcelain to be able to checkout all unmerged files in all stages so that an external merge tool can be executed by the Porcelain or the end-user. Using git-unpack-file on each stage individually incurs a rather high penalty due to the need to fork for each file version obtained. git-checkout-index -a --stage=all will now do the same thing, but faster. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* war on whitespaces: documentation.Junio C Hamano2006-03-021-1/+1
| | | | | | | We were missing the --whitespace option in the usage string for git-apply and git-am, so this commit adds them. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply: war on whitespace -- finishing touches.Junio C Hamano2006-02-281-0/+11
| | | | | | | | | This changes the default --whitespace policy to nowarn when we are only getting --stat, --summary etc. IOW when not applying the patch. When applying the patch, the default is warn (spit out warning message but apply the patch). Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-apply --whitespace=nowarnJunio C Hamano2006-02-271-2/+6
| | | | | | | | | Andrew insists --whitespace=warn should be the default, and I tend to agree. This introduces --whitespace=warn, so if your project policy is more lenient, you can squelch them by having apply.whitespace=nowarn in your configuration file. Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply --whitespace: configuration option.Junio C Hamano2006-02-271-24/+48
| | | | | | | | | | | | | | The new configuration option apply.whitespace can take one of "warn", "error", "error-all", or "strip". When git-apply is run to apply the patch to the index, they are used as the default value if there is no command line --whitespace option. Andrew can now tell people who feed him git trees to update to this version and say: git repo-config apply.whitespace error Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply: squelch excessive errors and --whitespace=error-allJunio C Hamano2006-02-271-8/+45
| | | | | | | | | This by default makes --whitespace=warn, error, and strip to warn only the first 5 additions of trailing whitespaces. A new option --whitespace=error-all can be used to view all of them before applying. Signed-off-by: Junio C Hamano <junkio@cox.net>
* apply --whitespace fixes and enhancements.Junio C Hamano2006-02-261-23/+54
| | | | | | | | | | | | | | | | | | | | | | In addition to fixing obvious command line parsing bugs in the previous round, this changes the following: * Adds "--whitespace=strip". This applies after stripping the new trailing whitespaces introduced to the patch. * The output error message format is changed to say "patch-filename:linenumber:contents of the line". This makes it similar to typical compiler error message format, and helps C-x ` (next-error) in Emacs compilation buffer. * --whitespace=error and --whitespace=warn do not stop at the first error. We might want to limit the output to say first 20 such lines to prevent cluttering, but on the other hand if you are willing to hand-fix after inspecting them, getting everything with a single run might be easier to work with. After all, somebody has to do the clean-up work somewhere. Signed-off-by: Junio C Hamano <junkio@cox.net>
* The war on trailing whitespaceLinus Torvalds2006-02-261-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Sat, 25 Feb 2006, Andrew Morton wrote: > > I'd suggest a) git will simply refuse to apply such a patch unless given a > special `forcing' flag, b) even when thus forced, it will still warn and c) > with a different flag, it will strip-then-apply, without generating a > warning. This doesn't do the "strip-then-apply" thing, but it allows you to make git-apply generate a warning or error on extraneous whitespace. Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error to make it a fatal error to have whitespace at the end. Totally untested, of course. But it compiles, so it must be fine. HOWEVER! Note that this literally will check every single patch-line with "+" at the beginning. Which means that if you fix a simple typo, and the line had a space at the end before, and you didn't remove it, that's still considered a "new line with whitespace at the end", even though obviously the line wasn't really new. I assume this is what you wanted, and there isn't really any sane alternatives (you could make the warning activate only for _pure_ additions with no deletions at all in that hunk, but that sounds a bit insane). Linus
* Merge branch 'jc/nostat'Junio C Hamano2006-02-211-1/+1
|\ | | | | | | | | | | | | | | | | | | | | * jc/nostat: cache_name_compare() compares name and stage, nothing else. "assume unchanged" git: documentation. ls-files: split "show-valid-bit" into a different option. "Assume unchanged" git: --really-refresh fix. ls-files: debugging aid for CE_VALID changes. "Assume unchanged" git: do not set CE_VALID with --refresh "Assume unchanged" git
| * "Assume unchanged" gitJunio C Hamano2006-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds "assume unchanged" logic, started by this message in the list discussion recently: <Pine.LNX.4.64.0601311807470.7301@g5.osdl.org> This is a workaround for filesystems that do not have lstat() that is quick enough for the index mechanism to take advantage of. On the paths marked as "assumed to be unchanged", the user needs to explicitly use update-index to register the object name to be in the next commit. You can use two new options to update-index to set and reset the CE_VALID bit: git-update-index --assume-unchanged path... git-update-index --no-assume-unchanged path... These forms manipulate only the CE_VALID bit; it does not change the object name recorded in the index file. Nor they add a new entry to the index. When the configuration variable "core.ignorestat = true" is set, the index entries are marked with CE_VALID bit automatically after: - update-index to explicitly register the current object name to the index file. - when update-index --refresh finds the path to be up-to-date. - when tools like read-tree -u and apply --index update the working tree file and register the current object name to the index file. The flag is dropped upon read-tree that does not check out the index entry. This happens regardless of the core.ignorestat settings. Index entries marked with CE_VALID bit are assumed to be unchanged most of the time. However, there are cases that CE_VALID bit is ignored for the sake of safety and usability: - while "git-read-tree -m" or git-apply need to make sure that the paths involved in the merge do not have local modifications. This sacrifices performance for safety. - when git-checkout-index -f -q -u -a tries to see if it needs to checkout the paths. Otherwise you can never check anything out ;-). - when git-update-index --really-refresh (a new flag) tries to see if the index entry is up to date. You can start with everything marked as CE_VALID and run this once to drop CE_VALID bit for paths that are modified. Most notably, "update-index --refresh" honours CE_VALID and does not actively stat, so after you modified a file in the working tree, update-index --refresh would not notice until you tell the index about it with "git-update-index path" or "git-update-index --no-assume-unchanged path". This version is not expected to be perfect. I think diff between index and/or tree and working files may need some adjustment, and there probably needs other cases we should automatically unmark paths that are marked to be CE_VALID. But the basics seem to work, and ready to be tested by people who asked for this feature. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Optionally support old diffsJohannes Schindelin2006-02-171-0/+8
|/ | | | | | | | | | Some versions of diff do not correctly detect a missing new-line at the end of the file under certain circumstances. When defining NO_ACCURATE_DIFF, work around this bug. Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use sha1_file.c's mkdir-like routine in apply.c.Jason Riedy2006-02-031-21/+4
| | | | | | | | | | | | | | | As far as I can see, create_subdirectories() in apply.c just duplicates the functionality of safe_create_leading_directories() from sha1_file.c. The former has a warm, fuzzy const parameter, but that's not important. The potential problem with EEXIST and creating directories should never occur here, but will be removed by future safe_create_leading_directories() changes. Other uses of EEXIST in apply.c should be fine barring intentionally malicious behavior. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make apply accept the -pNUM option like patch does.Daniel Barkalow2006-01-311-2/+6
| | | | | | | This only applies to traditional diffs, not to git diffs. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* fix potential deadlock in create_one_fileAlex Riesen2006-01-051-1/+2
| | | | | | | | It can happen if the temporary file already exists (i.e. after a panic and reboot). Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* trivial: O_EXCL makes O_TRUNC redundantAlex Riesen2006-01-051-1/+1
| | | | | Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* xread/xwrite: do not worry about EINTR at calling sites.Junio C Hamano2005-12-191-17/+6
| | | | | | | | | | We had errno==EINTR check after read(2)/write(2) sprinkled all over the places, always doing continue. Consolidate them into xread()/xwrite() wrapper routines. Credits for suggestion goes to HPA -- bugs are mine. Signed-off-by: Junio C Hamano <junkio@cox.net>
View Lorry Controller Status