swh:1:snp:6df5a50b8107b6bbe1e51d0239d816a7503c536a

sort by:
Revision Author Date Message Commit Date
aba170c GIT 1.5.2 Signed-off-by: Junio C Hamano <junkio@cox.net> 20 May 2007, 07:30:39 UTC
e40a304 git-cvsserver: exit with 1 upon "I HATE YOU" Signed-off-by: Junio C Hamano <junkio@cox.net> 20 May 2007, 07:19:48 UTC
03f6db0 Merge branch 'maint' to synchronize with 1.5.1.6 * maint: GIT 1.5.1.6 git-svn: don't minimize-url when doing an init that tracks multiple paths git-svn: avoid crashing svnserve when creating new directories user-manual: Add section on ignoring files user-manual: finding commits referencing given file content user-manual: discourage shared repository tutorial: revise index introduction tutorials: add user-manual links Conflicts: GIT-VERSION-GEN RelNotes 20 May 2007, 07:19:30 UTC
f7b47b2 GIT 1.5.1.6 Signed-off-by: Junio C Hamano <junkio@cox.net> 20 May 2007, 07:15:53 UTC
2be2e26 Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint * 'maint' of git://linux-nfs.org/~bfields/git: user-manual: Add section on ignoring files user-manual: finding commits referencing given file content user-manual: discourage shared repository tutorial: revise index introduction tutorials: add user-manual links 20 May 2007, 06:25:59 UTC
dc43166 git-svn: don't minimize-url when doing an init that tracks multiple paths I didn't have a chance to test the off-by-default minimize-url stuff enough before, but it's quite broken for people passing the --trunk/-T, --tags/-t, --branches/-b switches to "init" or "clone" commands. Additionally, follow-parent functionality seems broken when we're not connected to the root of the repository. Default behavior for "traditional" git-svn users who only track one directory (without needing follow-parent) should be reasonable, as those users started using things before minimize-url functionality existed. Behavior for users more used to the git-svnimport-like command line will also benefit from a more-flexible command-line than svnimport given the assumption they're working with non-restrictive read permissions on the repository. I hope to properly fix these bugs when I get a chance to in the next week or so, but I would like to get this stopgap measure of reverting to the old behavior as soon as possible. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 19:28:50 UTC
6442754 git-svn: avoid crashing svnserve when creating new directories When sorting directory names by depth (slash ("/") count) and closing the deepest directories first (as the protocol requires), we failed to put the root baton (with an empty string as its key "") after top-level directories (which did not have any slashes). This resulted in svnserve being in a situation it couldn't handle and caused a segmentation fault on the remote server. This bug did not affect users of DAV and filesystem repositories. Signed-off-by: Eric Wong <normalperson@yhbt.net> Confirmed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 19:26:36 UTC
2dc5361 user-manual: Add section on ignoring files The todo list at the end of the user manual says that something must be said about .gitignore. Also, there seems to be a lack of documentation on how to choose between the various types of ignore files (.gitignore vs. .git/info/exclude, etc.). This patch adds a section on ignoring files which try to introduce how to tell git about ignored files, and how the different strategies complement eachother. The syntax of exclude patterns is explained in a simplified manner, with a reference to git-ls-files(1) which already contains a more thorough explanation. Signed-off-by: Johan Herland <johan@herland.net> 19 May 2007, 05:06:05 UTC
187b0d8 user-manual: finding commits referencing given file content Another amusing git exploration example brought up in irc. (Credit to aeruder for the complete solution.) Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 May 2007, 05:00:55 UTC
8fae222 user-manual: discourage shared repository I don't really want to look like we're encouraging the shared repository thing. Take down some of the argument for using purely single-developer-owned repositories and collaborating using patches and pulls instead. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 May 2007, 05:00:45 UTC
93f9cc6 tutorial: revise index introduction The embarassing history of this tutorial is that I started it without really understanding the index well, so I avoided mentioning it. And we all got the idea that "index" was a word to avoid using around newbies, but it was reluctantly mentioned that *something* had to be said. The result is a little awkward: the discussion of the index never actually uses that word, and isn't well-integrated into the surrounding material. Let's just go ahead and use the word "index" from the very start, and try to demonstrate its use with a minimum of lecturing. Also, remove discussion of using git-commit with explicit filenames. We're already a bit slow here to get people to their first commit, and I'm not convinced this is really so important. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 May 2007, 05:00:27 UTC
cd50aba tutorials: add user-manual links Mention the user manual, especially as an alternative introduction for user's mainly interested in read-only operations. And fix a typo while we're there. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 19 May 2007, 04:57:19 UTC
404fdef Merge branch 'maint' * maint: Documentation: Reformatted SYNOPSIS for several commands Documentation: Added [verse] to SYNOPSIS where necessary 19 May 2007, 04:50:56 UTC
97925fd Documentation: Reformatted SYNOPSIS for several commands Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 04:47:45 UTC
e448ff8 Documentation: Added [verse] to SYNOPSIS where necessary Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 04:47:40 UTC
2ff3f61 Documentation/git.txt: Update links to older documentation pages. It's starting to take too much space at the beginning of the main documentation page. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 04:43:13 UTC
c906b18 gitweb: Fix "Use of uninitialized value" warning in git_feed Initial (root) commit has no parents, and $co{'parent'} is undefined. Use '--root' for initial commit. This fixes "Use of uninitialized value in open at gitweb/gitweb.perl line 4925." warning. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 02:49:45 UTC
c0e9892 Merge branch 'sp/cvsexport' * sp/cvsexport: Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file. 19 May 2007, 00:28:50 UTC
b6e4db6 Add link to 1.5.1.5 release notes. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 00:28:24 UTC
d6b3e3a Merge 1.5.1.5 in Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 00:27:08 UTC
6b68342 GIT v1.5.1.5 Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 00:21:43 UTC
cecb98a Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint * 'maint' of git://linux-nfs.org/~bfields/git: user-manual: reorganize public git repo discussion user-manual: listing commits reachable from some refs not others user-manual: introduce git user-manual: add a "counting commits" example user-manual: move howto/using-topic-branches into manual user-manual: move howto/make-dist.txt into user manual Documentation: remove howto's now incorporated into manual user-manual: move quick-start to an appendix glossary: expand and clarify some definitions, prune cross-references user-manual: revise birdseye-view chapter Add a birdview-on-the-source-code section to the user manual 19 May 2007, 00:13:47 UTC
7f79b01 gitweb: Remove redundant $searchtype setup Sorry, this was inadverently introduced by my grep search patch. It causes annoying "redefined" warnings. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 00:12:36 UTC
a5c2d26 Documentation: git-rev-list's "patterns" git-rev-list(1) talks about patterns as values for the --grep, --committed etc. parameters, without going into detail. This patch mentions that these patterns are actually regexps. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 00:12:10 UTC
760f0c6 Fix crlf attribute handling to match documentation gitattributes.txt says, of the crlf attribute: Set:: Setting the `crlf` attribute on a path is meant to mark the path as a "text" file. 'core.autocrlf' conversion takes place without guessing the content type by inspection. That is to say that the crlf attribute does not force the file to have CRLF line endings, instead it removes the autocrlf guesswork and forces the file to be treated as text. Then, whatever line ending is defined by the autocrlf setting is applied. However, that is not what convert.c was doing. The conversion to CRLF was being skipped in crlf_to_worktree() when the following condition was true: action == CRLF_GUESS && auto_crlf <= 0 That is to say conversion took place when not in guess mode (crlf attribute not specified) or core.autocrlf set to true. This was wrong. It meant that the crlf attribute being on for a given file _forced_ CRLF conversion, when actually it should force the file to be treated as text, and converted accordingly. The real test should simply be auto_crlf <= 0 That is to say, if core.autocrlf is falsei (or input), conversion from LF to CRLF is never done. When core.autocrlf is true, conversion from LF to CRLF is done only when in CRLF_GUESS (and the guess is "text"), or CRLF_TEXT mode. Similarly for crlf_to_worktree(), if core.autocrlf is false, no conversion should _ever_ take place. In reality it was only not taking place if core.autocrlf was false _and_ the crlf attribute was unspecified. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 May 2007, 00:02:47 UTC
5e6cfc8 git-archive: convert archive entries like checkouts do As noted by Johan Herland, git-archive is a kind of checkout and needs to apply any checkout filters that might be configured. This patch adds the convenience function convert_sha1_file which returns a buffer containing the object's contents, after converting, if necessary (i.e. it's a combination of read_sha1_file and convert_to_working_tree). Direct calls to read_sha1_file in git-archive are then replaced by calls to convert_sha1_file. Since convert_sha1_file expects its path argument to be NUL-terminated -- a convention it inherits from convert_to_working_tree -- the patch also changes the path handling in archive-tar.c to always NUL-terminate the string. It used to solely rely on the len field of struct strbuf before. archive-zip.c already NUL-terminates the path and thus needs no such change. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 May 2007, 23:36:45 UTC
eda6944 user-manual: reorganize public git repo discussion Helping a couple people set up public repos recently, I wanted to point them at this piece of the user manual, but found it wasn't as helpful as it could be: - It starts with a big explanation of why you'd want a public repository, not necessary in their case since they already knew why they wanted that. So, separate that out. - It skimps on some of the git-daemon details, and puts the http export information first. Fix that. Also group all the public repo subsections into a single section, and do some miscellaneous related editing. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 03:23:08 UTC
629d9f7 user-manual: listing commits reachable from some refs not others This is just an amusing example raised by someone in irc. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:58:53 UTC
99eaefd user-manual: introduce git Well, we should say at least something about what git is. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:58:53 UTC
46acd3f user-manual: add a "counting commits" example This is partly just an excuse to mention --pretty= and rev-list. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:58:51 UTC
9e2163e user-manual: move howto/using-topic-branches into manual Move howto/using-topic-branches into the user manual as an example for the "sharing development" chapter. While we're at it, remove some discussion that's covered in earlier chapters, modernize somewhat (use separate-heads setup, remotes, replace "whatchanged" by "log", etc.), and replace syntax we'd need to explain by syntax we've already covered (e.g. old..new instead of new ^old). The result may not really describe what Tony Luck does any more.... Hope that's not annoying. Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:20:10 UTC
82c8bf2 user-manual: move howto/make-dist.txt into user manual There seems to be a perception that the howto's are bit-rotting a little. The manual might be a more visible location for some of them, and make-dist.txt seems like a good candidate to include as an example in the manual. For now, incorporate much of it verbatim. Later we may want to update the example a bit. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:08:02 UTC
4db75b7 Documentation: remove howto's now incorporated into manual These two howto's have both been copied into the manual. I'd rather not maintain both versions if possible, and I think the user-manual will be more visible than the howto directory. (Though I wouldn't mind some duplication if people really like having them here.) Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:05:46 UTC
2624d9a user-manual: move quick-start to an appendix The quick start interrupts the flow of the manual a bit. Move it to "appendix A" but add a reference to it in the preface. Also rename the todo chapter to "appendix B", and revise the preface a little. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:05:46 UTC
343cad9 glossary: expand and clarify some definitions, prune cross-references Revise and expand some of the definitions in the glossary, based in part on a recent thread started by a user looking for help with some of the jargon. I've borrowed some of the language from Linus's email on that thread. (I'm assuming standing permission to plagiarize Linus's email....) Also start making a few changes to mitigate the appearance of "circularity" mentioned in that thread: - feel free to use somewhat longer definitions and to explain some things more than once instead of relying purely on cross-references - don't use cross-references when they're redundant: eliminate self-references and repeated references to the same entry. Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:03:59 UTC
a5fc33b user-manual: revise birdseye-view chapter Some revisions suggested by Junio along with some minor style fixes and one compile fix (asterisks need escaping). Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> 18 May 2007, 01:02:35 UTC
4229aa5 gitweb: Allow arbitrary strings to be dug with pickaxe Currently, there are rather draconian restrictions on the strings accepted by the pickaxe search, which degrades its usefulness for digging in code significantly. This patch remedies mentioned limitation. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 May 2007, 00:37:31 UTC
e773855 gitweb: Add support for grep searches The 'grep' type of search greps the currently selected tree for given regexp and shows the results in a fancy table with links into blob view. The number of shown matches is limited to 1000 and the whole feature can be turned off (grepping linux-2.6.git already makes repo.or.cz a bit unhappy). This second revision makes it in documentation explicit that grep accepts regexps, and makes grep accept extended regexps instead of basic regexps. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 May 2007, 00:37:31 UTC
d77b567 gitweb: Normalize searchbar font size Currently, searchbar font was as big as the page heading font, because font-size was made relative - but to the parent element, which was for some reason indeed page_header. Since that seems to be illogical to me, I just moved the div.search outside of div.page_header. I'm no CSS/DOM expert but no adverse effects were observed by me. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 May 2007, 00:37:30 UTC
8299886 Merge branch 'maint' * maint: Document core.excludesfile for git-add git-send-email: allow leading white space on mutt aliases 18 May 2007, 00:36:57 UTC
164b198 Document core.excludesfile for git-add During the discussion of core.excludesfile in the user-manual, I realized that the configuration wasn't mentioned in the man pages. Signed-off-by: Michael Hendricks <michael@ndrix.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 May 2007, 00:36:38 UTC
5f85505 gitweb: Fix error in git_patchset_body for deletion in merge commit Checking if $diffinfo->{'status'} is equal 'D' is no longer the way to check if the file was deleted in result. For merge commits $diffinfo->{'status'} is reference to array of statuses for each parent. Use the fact that $diffinfo->{'to_id'} is all zeros as sign that file was deleted in result. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 May 2007, 00:35:33 UTC
e986e26 Merge branch 'master' of git://repo.or.cz/git-gui * 'master' of git://repo.or.cz/git-gui: git-gui: Gracefully handle bad TCL_PATH at compile time 17 May 2007, 23:52:45 UTC
b9e7efb git-gui: Gracefully handle bad TCL_PATH at compile time Petr Baudis pointed out the main git.git repository's Makefile dies now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not set to a working tclsh program path. This breaks people who may have a working build configuration today and suddenly upgrade to the latest git release. The tclIndex is required for git-gui to load its associated lib files, but using the Tcl auto_load procedure to source only the files we need is a performance optimization. We can emulate the auto_load by just source'ing every file in that directory, assuming we source class.tcl first to initialize our crude class system. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 17 May 2007, 22:10:26 UTC
504ceab git-send-email: allow leading white space on mutt aliases mutt version 1.5.14 (perhaps earlier versions too) permits alias files to have white space before the 'alias' keyword. Signed-off-by: Michael Hendricks <michael@ndrix.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 May 2007, 05:33:04 UTC
2eb54ef gitweb: fix another use of undefined value Pasky and Jakub competed fixing these and in the confusion this ended up not being covered. Signed-off-by: Junio C Hamano <junkio@cox.net> 17 May 2007, 04:04:16 UTC
126640a Add a birdview-on-the-source-code section to the user manual In http://thread.gmane.org/gmane.comp.version-control.git/42479, a birdview on the source code was requested. J. Bruce Fields suggested that my reply should be included in the user manual, and there was nothing of an outcry, so here it is, not 2 months later. It includes modifications as suggested by J. Bruce Fields, Karl Hasselström and Daniel Barkalow. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 17 May 2007, 00:36:13 UTC
d26c426 gitweb: Empty patch for merge means trivial merge, not no differences Earlier commit 4280cde95fa4e3fb012eb6d0c239a7777baaf60c made gitweb show "No differences found" message for empty diff, for the HTML output. But for merge commits, either -c format we use or --cc format, empty diff doesn't mean no differences, but trivial merge. Show "Trivial merge" message instead of "No differences found" for merges. While at it reword conditional in the code for easier reading. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 23:13:42 UTC
fdcb769 Merge branch 'maint' * maint: format-patch: add MIME-Version header when we add content-type. Fixed link in user-manual import-tars: Use the "Link indicator" to identify directories git name-rev writes beyond the end of malloc() with large generations Documentation/branch: fix small typo in -D example 16 May 2007, 19:43:05 UTC
7e431ef gitweb: Separate search regexp from search text Separate search text, which is saved in $searchtext global variable, and is used in links, as default value for the textfield in search form, and for pickaxe search, from search regexp, which is saved in $search_regexp global variable, and is used as parameter to --grep, --committer or --author options to git-rev-list, and for searching commit body in gitweb. For now $search_regexp is unconditionallt equal to quotemeta($searchtext), meaning that we always search for fixed string. This fixes bug where 'next page' links for 'search' view didn't work for searchtext containing quotable characters, like `@'. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 19:40:06 UTC
b211c32 gitweb: Do not use absolute font sizes David KÃ¥gedal proposed that gitweb should explicitely request being somewhat smaller than normal, because it has good use for long lines. However gitweb presents a table with several columns, so having wider line is OK for it. Therefore explicit 'font-size: small' would make sense. Apparently many people on the list seem to agree with him. Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 19:40:06 UTC
0ab564b format-patch: add MIME-Version header when we add content-type. When we add Content-Type: header, we should also add MIME-Version: header as well. Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 19:37:25 UTC
61d7256 Fixed link in user-manual link to git-mergetool was broken. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 19:32:29 UTC
df9f91f Merge branch 'maint' of git://repo.or.cz/git/fastimport into maint * 'maint' of git://repo.or.cz/git/fastimport: import-tars: Use the "Link indicator" to identify directories 16 May 2007, 19:13:55 UTC
df8cfac import-tars: Use the "Link indicator" to identify directories Earlier, we used the mode to determine if a name was associated with a directory. This fails, since some tar programs do not set the mode correctly. However, the link indicator _has_ to be set correctly. Noticed by Chris Riddoch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 May 2007, 18:54:22 UTC
8a912bc Ensure return value from xread() is always stored into an ssize_t This patch fixes all calls to xread() where the return value is not stored into an ssize_t. The patch should not have any effect whatsoever, other than putting better/more appropriate type names on variables. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 04:16:03 UTC
2924415 Fix signedness on return value from xread() The return value from xread() is ssize_t. Paolo Teti <paolo.teti@gmail.com> pointed out that in this case, the signed return value was assigned to an unsigned type (size_t). This patch fixes that. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 04:15:54 UTC
cf606e3 git name-rev writes beyond the end of malloc() with large generations When using git name-rev on my kernel tree I triggered a malloc() corruption warning from glibc. apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin *** glibc detected *** malloc(): memory corruption: 0x0bff8950 *** Aborted This comes from name_rev() which is building the name of the revision in a malloc'd string, which it sprintf's into: char *new_name = xmalloc(len + 8); [...] sprintf(new_name, "%.*s~%d^%d", len, tip_name, generation, parent_number); This allocation is only sufficient if the generation number is less than 5 digits, in my case generation was 13432. In reality parent_number can be up to 16 so that also can require two digits, reducing us to 3 digits before we are at risk of blowing this allocation. This patch introduces a decimal_length() which approximates the number of digits a type may hold, it produces the following: Type Longest Value Len Est ---- ------------- --- --- unsigned char 256 3 4 unsigned short 65536 5 6 unsigned long 4294967296 10 11 unsigned long long 18446744073709551616 20 21 char -128 4 4 short -32768 6 6 long -2147483648 11 11 long long -9223372036854775808 20 21 This is then used to size the new_name. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 16 May 2007, 01:14:42 UTC
045fe3c Documentation/branch: fix small typo in -D example Signed-off-by: Quy Tonthat <qtonthat@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 15 May 2007, 03:17:00 UTC
c56f0d9 Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file. Runtime is now independent of the number of modified files. The old implementation executed 'cvs status' for each file touched by the patch to be applied. The new code calls 'cvs status' only once with all touched files and parses cvs's output to collect all available status information. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 15 May 2007, 02:18:55 UTC
af9b54b Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs $Id$ is present already in SVN and CVS; it would mean that people converting their existing repositories won't have to make any changes to the source files should they want to make use of the ident attribute. Given that it's a feature that's meant to calm those very people, it seems obtuse to make them edit every file just to make use of it. I think that bzr uses $Id$; Mercurial has examples hooks for $Id$; monotone has $Id$ on its wishlist. I can't think of a good reason not to stick with the de-facto standard and call ours $Id$ instead of $ident$. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 15 May 2007, 02:03:32 UTC
3545193 Merge branch 'maint' * maint: Prepare for 1.5.1.5 Release Notes gitweb: Add a few comments about %feature hash git-am: Clean up the asciidoc documentation Documentation: format-patch has no --mbox option builtin-log.c: Fix typo in comment Fix git-clone buglet for remote case. 15 May 2007, 01:50:01 UTC
52e7b74 Prepare for 1.5.1.5 Release Notes Hopefully we will have 1.5.2 soonish, to contain all of these, but we should summarize what we have done regardless. Signed-off-by: Junio C Hamano <junkio@cox.net> 15 May 2007, 00:51:12 UTC
b4b20b2 gitweb: Add a few comments about %feature hash Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 15 May 2007, 00:26:46 UTC
870e0d6 git-am: Clean up the asciidoc documentation Add --keep to synopsis. The synopsys used a mix of tabs and spaces, unify to use only spaces. Shuffle options around in synopsys and description for grouping them logically. Add more gitlink references to other commands. Various grammatical fixes and improvements. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 15 May 2007, 00:25:02 UTC
7b1885d Documentation: format-patch has no --mbox option git-applymbox and git-mailinfo refer to a --mbox option of git-format-patch when talking about their -k options. But there is no such option. What -k does to the former two commands is to keep the Subject: lines unmunged, meant to be used on output generated with format-patch -k. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 15 May 2007, 00:23:52 UTC
2dc189a builtin-log.c: Fix typo in comment s/fmt-patch/format-patch/ Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 14 May 2007, 23:52:02 UTC
223fa32 Fix git-clone buglet for remote case. c2f599e09fd0496413d1744b5b89b9b5c223555d introduced a buglet while cloning from a remote URL; we forgot to squelch the unnecessary error message when we try to cd to the given "remote" name, in order to see if it is a local directory. Signed-off-by: Junio C Hamano <junkio@cox.net> 14 May 2007, 21:24:02 UTC
460c699 cvsserver: Don't send mixed messages to clients After we send I HATE YOU we should probably exit and not happily continue with I LOVE YOU and further communication. Most clients will probably just exit and ignore everything we send after the I HATE YOU and it is not a security problem either because we don't really care about the user name anyway. But it is still the right thing to do. [jc: with a minor fixup to its exit code...] Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Acked-by: "Martin Langhoff" <martin.langhoff@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 14 May 2007, 06:57:27 UTC
dfaa61b Documentation/git-add: clarify -u with path limiting Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 14 May 2007, 01:45:15 UTC
331b51d Documentation: Split description of pretty formats of commit log Split description of pretty formats into list of pretty options (--pretty and --encoding) in new file Documentation/pretty-options.txt and description of formats itself as a separate "PRETTY FORMATS" section in pretty-formats.txt While at it correct formatting a bit, to be better laid out in the resulting manpages: git-rev-list(1), git-show(1), git-log(1) and git-diff-tree(1). Those manpages now include pretty options in the same place as it was before, and description of formats just after all options. Inspired by the split into two filesdocumentation for merge strategies: Documentation/merge-options.txt and Documentation/merge-strategies.txt Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 14 May 2007, 01:44:50 UTC
785cdea gitweb: Fix "Use of unitialized value" warnings in empty repository Fix it so gitweb doesn't write "Use of unitialized value..." warnings (which gets written in web server logs) for empty (no commits) repository. In empty repository "last change" (last activity) doesn't make sense; also there is no sense in parsing commits which aren't there. In projects list for empty repositories gitweb now writes "No commits" using "noage" class, instead of leaving cell empty, in the last change column. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 14 May 2007, 01:22:54 UTC
43d151a Merge branch 'maint' * maint: git-svn: don't attempt to minimize URLs by default git-svn: fix segfaults due to initial SVN pool being cleared git-svn: clean up caching of SVN::Ra functions git-svn: don't drop the username from URLs when dcommit is run RPM spec: include files in technical/ to package. Remove stale non-static-inline prototype for tree_entry_extract() git-config: test for 'do not forget "a.b.var" ends "a.var" section'. git-config: do not forget seeing "a.b.var" means we are out of "a.var" section. 13 May 2007, 20:34:40 UTC
f987afa cvsserver: Limit config parser to needed options Change the configuration parser so that it ignores everything except for ^gitcvs.((ext|pserver).)? This greatly reduces the risk of failing while parsing some unknown and irrelevant config option. The bug that triggered this change was that the parsing doesn't handle sections that have a subsection and a variable with the same name. While this bug still remains, all remaining causes can be attributed to user error, since there are no defined variables gitcvs.ext and gitcvs.pserver. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 13 May 2007, 19:14:22 UTC
198a2a8 gitweb: Check if requested object exists Try to avoid "Use of uninitialized value ..." errors caused by bad revision, incorrect filename, wrong object id, bad file etc. (wrong value of 'h', 'hb', 'f', etc. parameters). This avoids polluting web server errors log. Correct git_get_hash_by_path and parse_commit_text (and, in turn, parse_commit) to return undef if object does not exist. Check in git_tag if requested tag exists. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 13 May 2007, 19:12:30 UTC
a2983cb Link to HTML version of external doc if available Currently $ git grep '\([^t]\|^\)'link: user-manual.txt gives four hits that refer to .txt version of the documentation set, but at least "hooks" and "cvs-migration" have HTML variants installed, so refer to them instead. Signed-off-by: Junio C Hamano <junkio@cox.net> 13 May 2007, 19:12:19 UTC
4a1bb4c git-svn: don't attempt to minimize URLs by default For tracking branches and tags, git-svn prefers to connect to the root of the repository or at least the level that houses branches and tags as well as trunk. However, users that are accustomed to tracking a single directory have no use for this feature. As pointed out by Junio, users may not have permissions to connect to connect to a higher-level path in the repository. While the current minimize_url() function detects lack of permissions to certain paths _after_ successful logins, it cannot effectively determine if it is trying to access a login-only portion of a repo when the user expects to connect to a part where anonymous access is allowed. For people used to the git-svnimport switches of --trunk, --tags, --branches, they'll already pass the repository root (or root+subdirectory), so minimize URL isn't of too much use to them, either. For people *not* used to git-svnimport, git-svn also supports: git svn init --minimize-url \ --trunk http://repository-root/foo/trunk \ --branches http://repository-root/foo/branches \ --tags http://repository-root/foo/tags And this is where the new --minimize-url command-line switch comes in to allow for this behavior to continue working. 13 May 2007, 19:10:43 UTC
4c03c3e git-svn: fix segfaults due to initial SVN pool being cleared Some parts of SVN always seem to use it, even if the SVN::Ra object we're using is no longer used and we've created a new one in its place. It's also true that only one SVN::Ra connection can exist at once... Using SVN::Pool->new_default when the SVN::Ra object is created doesn't seem to help very much, either... Hopefully this fixes all segfault problems users have been experiencing over the past few months. Signed-off-by: Eric Wong <normalperson@yhbt.net> 13 May 2007, 19:10:42 UTC
0dc03d6 git-svn: clean up caching of SVN::Ra functions This patch was originally intended to make the Perl GC more sensitive to the SVN::Pool objects and not accidentally clean them up when they shouldn't be (causing segfaults). That didn't work, but this patch makes the code a bit cleaner regardless Put our caches for get_dir and check_path calls directly into the SVN::Ra object so they auto-expire when it is destroyed. dirents returned by get_dir() no longer needs the pool object stored persistently along with the cache data, as they'll be converted to native Perl hash references. Since calling rev_proplist repeatedly per-revision is no longer needed in git-svn, we do not cache calls to it. Signed-off-by: Eric Wong <normalperson@yhbt.net> 13 May 2007, 19:10:42 UTC
645833b git-svn: don't drop the username from URLs when dcommit is run We no longer store usernames in URLs stored in git-svn-id lines for dcommit, so we shouldn't rely on those URLs when connecting to the remote repository to commit. 13 May 2007, 19:10:42 UTC
b24dd51 RPM spec: include files in technical/ to package. Not only that they are interesting to users, some of the files are linked to by the included "Git User's Manual" Signed-off-by: Quy Tonthat <qtonthat@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 13 May 2007, 19:00:28 UTC
0ab311d Remove stale non-static-inline prototype for tree_entry_extract() When 4651ece8 made the function a "static inline", it should have removd the stale prototype but everybody missed that. Thomas Glanzmann noticed this broke compilation with Forte12 compiler on his Sun boxes. Signed-off-by: Junio C Hamano <junkio@cox.net> 13 May 2007, 18:57:00 UTC
b18a2be git-config: test for 'do not forget "a.b.var" ends "a.var" section'. Added test for mentioned bugfix. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 13 May 2007, 07:24:46 UTC
ae9ee41 git-config: do not forget seeing "a.b.var" means we are out of "a.var" section. Earlier code tried to be half-careful and knew the logic that seeing "a.var" after seeing "a.b.var" is a sign of the previous "a.b." section has ended, but forgot it has to handle the other way. Seeing "a.b.var" after seeing "a.var" is a sign that "a." section has ended, so a new "a.var2" variable should be added before the location "a.b.var" appears. Signed-off-by: Junio C Hamano <junkio@cox.net> 13 May 2007, 07:19:58 UTC
24a0d61 Minor fixup to documentation of hooks in git-receive-pack. Small additional changes to the cbb84e5d174cf33fd4dcf3136de50a886ff9a2e2 commit, which introduced documentation to pre-receive and post-receive: - Mention that stdout and stderr are equivalent. - Add one cross-section link and fix one other. - Fix information on advantages of post-receive over post-update. Signed-off-by: Jan Hudec <bulb@ucw.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 22:46:55 UTC
6671525 Merge branch 'maint' * maint: checkout: allow detaching to HEAD even when switching to the tip of a branch Updated documentation of hooks in git-receive-pack. Allow fetching references from any namespace tiny fix in documentation of git-clone Fix an unmatched comment end in arm/sha1_arm.S 12 May 2007, 20:16:21 UTC
fdc99cb checkout: allow detaching to HEAD even when switching to the tip of a branch You cannot currently checkout the tip of an existing branch without moving to the branch. This allows you to detach your HEAD and place it at such a commit, with: $ git checkout master^0 Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 19:35:54 UTC
cbb84e5 Updated documentation of hooks in git-receive-pack. Added documentation of pre-receive and post-receive hooks and updated documentation of update and post-update hooks. [jc: with minor copy-editing] Signed-off-by: Jan Hudec <bulb@ucw.cz> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 18:13:08 UTC
a25907d t9400: Use the repository config and nothing else. git-cvsserver has a bug in its configuration file output parser that makes it choke if the configuration has these: [diff] color = auto [diff.color] whitespace = blue reverse This needs to be fixed, but thanks to that bug, a separate bug in t9400 test script was discovered. The test discarded GIT_CONFIG instead of pointing at the proper one to be used in the exoprted repository. This allowed user's .gitconfig and (if exists) systemwide /etc/gitconfig to affect the outcome of the test, which is a big no-no. The patch fixes the problem in the test. Fixing the git-cvsserver's configuration parser is left as an exercise to motivated volunteers ;-) Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 17:19:13 UTC
96f12b5 Allow fetching references from any namespace not only from the three defined: heads, tags and remotes. Noticed when I tried to fetch the references created by git-p4-import.bat: they are placed into separate namespace (refs/p4import/, to avoid showing them in git-branch output). As canon_refs_list_for_fetch always prepended refs/heads/ it was impossible, and annoying: it worked before. Normally, the p4import references are useless anywhere but in the directory managed by perforce, but in this special case the cloned directory was supposed to be a backup, including the p4import branch: it keeps information about where the imported perforce state came from. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 16:36:06 UTC
02851e0 git-archive: don't die when repository uses subprojects Both archive-tar and archive-zip needed to be taught about subprojects. The tar function died when trying to read the subproject commit object, while the zip function reported "unsupported file mode". This fixes both by representing the subproject as an empty directory. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 16:35:07 UTC
a6e3768 tiny fix in documentation of git-clone path in example was missing '../' Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 16:20:51 UTC
2206537 gitweb: Test if $from_id and $to_id are defined before comparison Get rid of "Use of uninitialized value in string eq at gitweb/gitweb.perl line 2320" warning caused by the fact that "empty" patches, consisting only of extended git diff header and with patch body empty, such as patch for pure rename, does not have "index" line in extended diff header. For such patches $from_id and $to_id, filled from parsing extended diff header, are undefined. But such patches cannot be continuation patches. Test if $from_id and $to_id are defined before comparing them with $diffinfo. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 16:19:08 UTC
7e9116b Fix an unmatched comment end in arm/sha1_arm.S Signed-off-by: Marco Costalba <mcostalba@gmail.com> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 16:16:50 UTC
93c44d4 git-add: allow path limiting with -u Rather than updating all working tree paths, we limit ourselves to paths listed on the command line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 08:01:28 UTC
16a4c61 read-tree -m -u: avoid getting confused by intermediate symlinks. When switching from a branch with both x86_64/boot/Makefile and i386/boot/Makefile to another branch that has x86_64/boot as a symlink pointing at ../i386/boot, the code incorrectly removed i386/boot/Makefile. This was because we first removed everything under x86_64/boot to make room to create a symbolic link x86_64/boot, then removed x86_64/boot/Makefile which no longer exists but now is pointing at i386/boot/Makefile, thanks to the symlink we just created. This fixes it by using the has_symlink_leading_path() function introduced previously for git-apply in the checkout codepath. Earlier, "git checkout" was broken in t4122 test due to this bug, and the test had an extra "git reset --hard" as a workaround, which is removed because it is not needed anymore. Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 05:33:31 UTC
64cab59 apply: do not get confused by symlinks in the middle HPA noticed that git-rebase fails when changes involve symlinks in the middle of the hierarchy. Consider: * The tree state before the patch is applied has arch/x86_64/boot as a symlink pointing at ../i386/boot/ * The patch tries to remove arch/x86_64/boot symlink, and create bunch of files there: .gitignore, Makefile, etc. git-apply tries to be careful while applying patches; it never touches the working tree until it is convinced that the patch would apply cleanly. One of the check it does is that when it knows a path is going to be created by the patch, it runs lstat() on the path to make sure it does not exist. This leads to a false alarm. Because we do not touch the working tree before all the check passes, when we try to make sure that arch/x86_64/boot/.gitignore does not exist yet, we haven't removed the arch/x86_64/boot symlink. The lstat() check ends up seeing arch/i386/boot/.gitignore through the yet-to-be-removed symlink, and says "Hey, you already have a file there, but what you fed me is a patch to create a new file. I am not going to clobber what you have in the working tree." We have similar checks to see a file we are going to modify does exist and match the preimage of the diff, which is done by directly opening and reading the file. For a file we are going to delete, we make sure that it does exist and matches what is going to be removed (a removal patch records the full preimage, so we check what you have in your working tree matches it in full -- otherwise we would risk losing your local changes), which again is done by directly opening and reading the file. These checks need to be adjusted so that they are not fooled by symlinks in the middle. - To make sure something does not exist, first lstat(). If it does not exist, it does not, so be happy. If it _does_, we might be getting fooled by a symlink in the middle, so break leading paths and see if there are symlinks involved. When we are checking for a path a/b/c/d, if any of a, a/b, a/b/c is a symlink, then a/b/c/d does _NOT_ exist, for the purpose of our test. This would fix this particular case you saw, and would not add extra overhead in the usual case. - To make sure something already exists, first lstat(). If it does not exist, barf (up to this, we already do). Even if it does seem to exist, we might be getting fooled by a symlink in the middle, so make sure leading paths are not symlinks. This would make the normal codepath much more expensive for deep trees, which is a bit worrisome. This patch implements the first side of the check "making sure it does not exist". The latter "making sure it exists" check is not done yet, so applying the patch in reverse would still fail, but we have to start from somewhere. Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 05:26:08 UTC
f859c84 Add has_symlink_leading_path() function. When we are applying a patch that creates a blob at a path, or when we are switching from a branch that does not have a blob at the path to another branch that has one, we need to make sure that there is nothing at the path in the working tree, as such a file is a local modification made by the user that would be lost by the operation. Normally, lstat() on the path and making sure ENOENT is returned is good enough for that purpose. However there is a twist. We may be creating a regular file arch/x86_64/boot/Makefile, while removing an existing symbolic link at arch/x86_64/boot that points at existing ../i386/boot directory that has Makefile in it. We always first check without touching filesystem and then perform the actual operation, so when we verify the new file, arch/x86_64/boot/Makefile, does not exist, we haven't removed the symbolic link arc/x86_64/boot symbolic link yet. lstat() on the file sees through the symbolic link and reports the file is there, which is not what we want. The function has_symlink_leading_path() function takes a path, and sees if any of the leading directory component is a symbolic link. When files in a new directory are created, we tend to process them together because both index and tree are sorted. The function takes advantage of this and allows the caller to cache and reuse which symbolic link on the filesystem caused the function to return true. The calling sequence would be: char last_symlink[PATH_MAX]; *last_symlink = '\0'; for each index entry { if (!lose) continue; if (lstat(it)) if (errno == ENOENT) ; /* happy */ else error; else if (has_symlink_leading_path(it, last_symlink)) ; /* happy */ else error; /* would lose local changes */ unlink_entry(it, last_symlink); } Signed-off-by: Junio C Hamano <junkio@cox.net> 12 May 2007, 05:11:07 UTC
211fb4f Minor copyediting on Release Notes for 1.5.2 Signed-off-by: Junio C Hamano <junkio@cox.net> 11 May 2007, 04:59:13 UTC
843142a GIT v1.5.2-rc3 Signed-off-by: Junio C Hamano <junkio@cox.net> 10 May 2007, 22:22:02 UTC
back to top