aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* core.whitespace: cr-at-eolJunio C Hamano2008-02-05
| | | | | | | | | | | | | 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: Junio C Hamano <gitster@pobox.com>
* git-apply --whitespace=fix: fix whitespace fuzz introduced by previous runJunio C Hamano2008-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you have more than one patch series, an earlier one of which tries to introduce whitespace breakages and a later one of which has such a new line in its context, "git-apply --whitespace=fix" will apply and fix the whitespace breakages in the earlier one, making the resulting file not to match the context of the later patch. A short demonstration is in the new test, t4125. For example, suppose the first patch is: diff a/hello.txt b/hello.txt --- a/hello.txt +++ b/hello.txt @@ -20,3 +20,3 @@ Hello world.$ -How Are you$ -Today?$ +How are you $ +today? $ to fix broken case in the string, but it introduces unwanted trailing whitespaces to the result (pretend you are looking at "cat -e" output of the patch --- '$' signs are not in the patch but are shown to make the EOL stand out). And the second patch is to change the wording of the greeting further: diff a/hello.txt b/hello.txt --- a/hello.txt +++ b/hello.txt @@ -18,5 +18,5 @@ Greetings $ -Hello world.$ +Hello, everybody. $ How are you $ -today? $ +these days? $ If you apply the first one with --whitespace=fix, you will get this as the result: Hello world.$ How are you$ today?$ and this does not match the preimage of the second patch, which demands extra whitespace after "How are you" and "today?". This series is about teaching "git apply --whitespace=fix" to cope with this situation better. If the patch does not apply, it rewrites the second patch like this and retries: diff a/hello.txt b/hello.txt --- a/hello.txt +++ b/hello.txt @@ -18,5 +18,5 @@ Greetings$ -Hello world.$ +Hello, everybody.$ How are you$ -today?$ +these days?$ This is done by rewriting the preimage lines in the hunk (i.e. the lines that begin with ' ' or '-'), using the same whitespace fixing rules as it is using to apply the patches, so that it can notice what it did to the previous ones in the series. A careful reader may notice that the first patch in the example did not touch the "Greetings" line, so the trailing whitespace that is in the original preimage of the second patch is not from the series. Is rewriting this context line a problem? If you think about it, you will realize that the reason for the difference is because the submitter's tree was based on an earlier version of the file that had whitespaces wrong on that "Greetings" line, and the change that introduced the "Greetings" line was added independently of this two-patch series to our tree already with an earlier "git apply --whitespace=fix". So it may appear this logic is rewriting too much, it is not so. It is just rewriting what we would have rewritten in the past. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: pass ws_rule down to match_fragment()Junio C Hamano2008-02-05
| | | | | | | | This is necessary to allow match_fragment() to attempt a match with a preimage that is based on a version before whitespace errors were fixed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: move copy_wsfix() function a bit higher.Junio C Hamano2008-02-05
| | | | | | I'll be calling this from match_fragment() in later rounds. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: do not feed copy_wsfix() leading '+'Junio C Hamano2008-02-05
| | | | | | | | The "patch" parameter used to include leading '+' of an added line in the patch, and the array was treated as 1-based. Make it accept the contents of the line alone and simplify the code. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: simplify calling site to apply_line()Junio C Hamano2008-02-05
| | | | | | | | | | The function apply_line() changed its behaviour depending on the ws_error_action, whitespace_error and if the input was a context. Make its caller responsible for such checking so that we can convert the function to copy the contents of line while fixing whitespace breakage more easily. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: clean-up apply_one_fragment()Junio C Hamano2008-02-05
| | | | | | | | | | | | | | We had two pointer variables pointing to the same buffer and an integer variable used to index into its tail part that was active (old, oldlines and oldsize for the preimage, and their 'new' counterparts for the postimage). To help readability, use 'oldlines' as the allocated pointer, and use 'old' as the pointer to the tail that advances while the code builds up the contents in the buffer. The size 'oldsize' can be computed as (old-oldines). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: mark common context lines in lineinfo structure.Junio C Hamano2008-02-05
| | | | | | | | | | | This updates the way preimage and postimage in a patch hunk is parsed and prepared for applying. By looking at image->line[n].flag, the code can tell if it is a common context line that is the same between the preimage and the postimage. This matters when we actually start applying a patch with contexts that have whitespace breakages that have already been fixed in the target file.
* builtin-apply.c: optimize match_beginning/end processing a bit.Junio C Hamano2008-02-05
| | | | | | | | | | | Wnen the caller knows the hunk needs to match at the beginning or at the end, there is no point starting from the line number that is found in the patch and trying match with increasing offset. The logic to find matching lines was made more line oriented with the previous patch and this optimization is now trivial. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: make it more line orientedJunio C Hamano2008-02-05
| | | | | | | | | | | | | | | | | This changes the way git-apply internally works to be more line oriented. The logic to find where the patch applies with offset used to count line numbers by always counting LF from the beginning of the buffer, but it is simplified because we count the line length of the target file and the preimage snippet upfront now. The ultimate motivation is to allow applying patches whose preimage context has whitespace corruption that has already been corrected in the local copy. For that purpose, we introduce a table of line-hash that allows us to match lines that differ only in whitespaces. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: push match-beginning/end logic downJunio C Hamano2008-02-05
| | | | | | | | | | | | | | | This moves the logic to force match at the beginning and/or at the end of the buffer to the actual function that finds the match from its caller. This is a necessary preparation for the next step to allow matching disregarding certain differences, such as whitespace changes. We probably could optimize this even more by taking advantage of the fact that match_beginning and match_end forces the match to be at an exact location (anchored at the beginning and/or the end), but that's for another commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: restructure "offset" matchingJunio C Hamano2008-02-05
| | | | | | | | | This restructures code to find matching location with offset in find_offset() function, so that there is need for only one call site of match_fragment() function. There still isn't a change in the logic of the program. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply.c: refactor small part that matches contextJunio C Hamano2008-02-05
| | | | | | | | | This moves three "if" conditions out of line from find_offset() function, which is responsible for finding the matching place in the preimage to apply the patch. There is no change in the logic of the program. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* man pages are littered with .ft C and othersJonas Fonseca2008-02-05
| | | | | | | | | | | | | | | | | | | | | Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008: > Junio C Hamano wrote: > > Jakub Narebski <jnareb@gmail.com> writes: > > > > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458 > Julian Phillips: > > Are you using docbook xsl 1.72? There are known problems building the > > manpages with that version. 1.71 works, and 1.73 should work when it get > > released. I was able to solve this problem with this patch, which adds a XSL file used specifically for DOCBOOK_XSL_172=YesPlease and where dots and backslashes are escaped properly so they won't be substituted to the wrong thing further down the "DocBook XSL pipeline". Doing the escaping in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end this part of the manpage nightmare. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add a BuildRequires for gettext in the spec file.James Bowes2008-02-04
| | | | | Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Test :/string form for checkoutDaniel Barkalow2008-02-04
| | | | | Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fix misuse of prefix_path()Junio C Hamano2008-02-03
| | | | | | | | | | | | | | When DEFAULT_GIT_TEMPLATE_DIR is specified as a relative path, init-db made it relative to exec_path using prefix_path(), which is wrong. prefix_path() is about a file inside the work tree. There was a similar misuse in config.c that takes relative ETC_GITCONFIG path. A convenience function prefix_filename() can concatenate two paths to form a path that points at somewhere outside the work tree. Use it in these codepaths instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse_object_buffer: don't ignore errors from the object specific parsing ↵Martin Koegler2008-02-03
| | | | | | | | | | | | | functions In the case of an malformed object, the object specific parsing functions would return an error, which is currently ignored. The object can be partial initialized in this case. This patch make parse_object_buffer propagate such errors. Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-fsck: report missing author/commit line in a commit as an errorMartin Koegler2008-02-03
| | | | | | | | | | | | | | | A zero commit date could be caused by: * a missing author line * a missing commiter line * a malformed email address in the commiter line * a malformed commit date Simply reporting it as zero commit date is missleading. Additionally, it upgrades the message to an error (instead of an printf). Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2008-02-03
|\ | | | | | | | | | | * maint: git-remote documentation: fix synopsis to match description git-am: fix type in its usage string
| * git-remote documentation: fix synopsis to match descriptionJörg Sommer2008-02-03
| | | | | | | | | | | | | | | | In the text, the argument of -m is <master> which should be used in the command synopsis, too. Signed-off-by: Jörg Sommer <joerg@alea.gnuu.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-am: fix type in its usage stringJörg Sommer2008-02-03
| | | | | | | | | | Signed-off-by: Jörg Sommer <joerg@alea.gnuu.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-p4: Fix an obvious typoTommy Thorn2008-02-03
| | | | | | | | | | | | | | | | | | | | The regexp "$," can't match anything. Clearly not intended. This was introduced in ce6f33c8 which is quite a while ago. Signed-off-by: Tommy Thorn <tommy-git@thorn.ws> Acked-by: Simon Hausmann <simon@lst.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Let "git svn" run "git gc --auto" occasionallyKarl Hasselström2008-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let "git svn" run "git gc --auto" every 1000 imported commits to reduce the number of loose objects. To handle the common use case of frequent imports, where each invocation typically fetches much less than 1000 commits, also run gc unconditionally at the end of the import. "1000" is the same number that was used by default when we called git-repack. It isn't necessarily still the best choice. Signed-off-by: Karl Hasselström <kha@treskal.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-svn: Don't call git-repack anymoreKarl Hasselström2008-02-03
| | | | | | | | | | | | | | | | | | | | | | | | In a moment, we'll start calling git-gc --auto instead, since it is a better fit to what we're trying to accomplish. The command line options are still accepted, but don't have any effect, and we warn the user about that. Signed-off-by: Karl Hasselström <kha@treskal.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-p4: Ensure the working directory and the index are clean before "git-p4 ↵Simon Hausmann2008-02-03
| | | | | | | | | | | | rebase" Signed-off-by: Simon Hausmann <simon@lst.de>
* | git-p4: Fix submit user-interface.Simon Hausmann2008-02-03
| | | | | | | | | | | | Don't ask any questions when submitting, behave similar to git-svn dcommit. Signed-off-by: Simon Hausmann <simon@lst.de>
* | Remove $Id: ..$ $Header: ..$ etc from +ko and +k files during importJason McMullan2008-02-03
| | | | | | | | | | | | | | | | | | | | This patch removes the '$Keyword: ...$' '...' data, so that files don't have spurious megre conflicts between branches. Handles both +ko and +k styles, and leaves the '$Foo$' in the original file. Signed-off-by: Simon Hausmann <simon@lst.de>
* | Merge branch 'maint'Junio C Hamano2008-02-03
|\ \ | |/ | | | | | | | | * maint: Fix "git-commit -C $tag" Documentation/git-stash.txt: Adjust SYNOPSIS command syntax (2)
| * Fix "git-commit -C $tag"Junio C Hamano2008-02-03
| | | | | | | | | | | | | | | | The scripted version might not have handled this correctly either, but the version rewritten in C definitely does not grok this and complains $tag is not a commit object. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Documentation/git-stash.txt: Adjust SYNOPSIS command syntax (2)Jari Aalto2008-02-03
| | | | | | | | | | | | | | | | Adjust the command syntax to better reflect the call parameters: [save] [message...] => [save [<message>]]. Signed-off-by: Jari Aalto <jari.aalto AT cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | known breakage: revision range computation with clock skewJunio C Hamano2008-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the absolute minimum (and reliable) reproduction recipe to demonstrate that revision range in a history with clock skew sometimes fails to mark UNINTERESTING commit in topologically early parts of the history. The history looks like this: o---o---o---o one four but one has the largest timestamp. "git rev-list four..one" fails to notice that "one" should not be emitted. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | test: reword the final message of tests with known breakagesJunio C Hamano2008-02-03
| | | | | | | | | | | | | | | | | | | | When we have known breakages, we still said "passed all N test(s)", which was a bit funny. This rewords it to read "passed all remaining N test(s)" in such a case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Sane use of test_expect_failureJunio C Hamano2008-02-01
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Update stale documentation links from the main documentation.Junio C Hamano2008-02-01
| | | | | | This could have been part of the 1.5.4 commit, but it isn't. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* GIT 1.5.4v1.5.4Junio C Hamano2008-02-01
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix "git checkout -b foo ':/substring'"Junio C Hamano2008-02-01
| | | | | | | | | | Because ':/substring' extended SHA1 expression cannot take postfix modifiers such as ^{tree} and ^{commit}, we would need to do it in multiple steps. With the patch, you can start a new branch from a randomly-picked commit whose message has the named string in it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix typo in a comment in t/test-lib.shMichele Ballabio2008-01-31
| | | | | Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git rev-parse manpage: spelling fixMiklos Vajna2008-01-31
| | | | | Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Revert "filter-branch docs: remove brackets so not to imply revision arg is ↵Junio C Hamano2008-01-31
| | | | | | | | optional" This reverts commit c41b439244c51b30c60953192816afc91e552578, as we decided to default to HEAD when revision parameters are missing and they are no longer mandatory.
* Documentation/git-cvsserver: Fix typoJean-Luc Herren2008-01-30
| | | | | Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* filter-branch: assume HEAD if no revision suppliedBrandon Casey2008-01-30
| | | | | | | | | | filter-branch previously took the first non-option argument as the name for a new branch. Since dfd05e38, it now takes a revision or a revision range and modifies the current branch. Update to operate on HEAD by default to conform with standard git interface practice. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* filter-branch docs: remove brackets so not to imply revision arg is optionalBrandon Casey2008-01-30
| | | | | Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Use 'printf %s $x' notation in t5401Shawn O. Pearce2008-01-30
| | | | | | | | | | | | | | | | We only care about getting what should be an empty string and sending it to a file, without a trailing LF, so the empty string translates into a 0 byte file. Earlier when I originally wrote these lines Mac OS X allowed the format string of printf to be the empty string, but more recent versions appear to have been 'improved' with error messages if the format is not given. This may cause problems if we ever wind up with changes to the hook tests. A minor cleanup makes the test more safe on all systems, by conforming to accepted printf conventions. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* filter-branch.sh: remove temporary directory on failureBrandon Casey2008-01-30
| | | | | | | | | | | | One of the first things filter-branch does is to create a temporary directory. This directory is eventually removed by the script during normal operation, but is not removed if the script encounters an error. Set a trap to remove it when the script terminates for any reason. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-relink: avoid hard linking in objects/info directoryBrandon Casey2008-01-30
| | | | | | | | | | | git-relink is intended to search for packs and loose objects in common between two repositories and to replace the one set with hard links to the other. Files other than packs and loose objects should not be touched, so add the "info" sub-directory to the pattern of directory excludes. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gitweb: Make use of the $git_dir variable at sub git_get_project_descriptionBruno Ribas2008-01-29
| | | | | Signed-off-by: Bruno Ribas <ribas@c3sl.ufpr.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gitweb: Add info about $projectroot and $projects_list to gitweb/READMEJakub Narebski2008-01-29
| | | | | | | | | | | Those two configuration variables are important enough that it is worth to explicitely write about them in the "Gitweb config file variables" section even if they are usually set during build by GITWEB_PROJECTROOT and GITWEB_LIST build (Makefile) configuration variables. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fix doc typosJim Meyering2008-01-29
| | | | | Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* reflog-expire: Avoid creating new files in a directory inside readdir(3) loopJunio C Hamano2008-01-29
| | | | | | | | | | | | | | | | | "git reflog expire --all" opened a directory in $GIT_DIR/logs/, read reflog files in there readdir(3), and rewrote the file by creating a new file and renaming it back inside the loop. This code structure can cause the newly created file to be returned by subsequent call to readdir(3), and fall into an infinite loop in the worst case. This separates the processing to two phase. Running for_each_reflog() to find out and collect all refs, and then iterate over them, calling expire_reflog(). This way, the program would behave exactly the same way as if all the refs were given by the user from the command line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2025-01-01 02:20:37 +0000