swh:1:snp:6df5a50b8107b6bbe1e51d0239d816a7503c536a

sort by:
Revision Author Date Message Commit Date
89815ca GIT 1.5.1 Signed-off-by: Junio C Hamano <junkio@cox.net> 04 April 2007, 05:47:01 UTC
045f575 Merge 1.5.0.7 in Signed-off-by: Junio C Hamano <junkio@cox.net> 04 April 2007, 04:52:14 UTC
9694ec4 GIT 1.5.0.7 Not that this release really matters, as we will be doing 1.5.1 tomorrow. This commit is to tie the loose ends and merge all of "maint" branch into "master" in preparation. Signed-off-by: Junio C Hamano <junkio@cox.net> 04 April 2007, 02:27:41 UTC
0448352 Documentation: A few minor fixes to Git User's Manual Mainly consistent usage of "git command" and not "git-command" syntax Signed-off-by: Jakub Narebski <jnareb@gmail.com> Acked-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net> 04 April 2007, 02:04:56 UTC
bbf4b41 Plug memory leak in index-pack collision checking codepath. 04 April 2007, 02:04:56 UTC
eb33596 rerere should not repeat the earlier hunks in later ones When a file has more then one conflicting hunks, it repeated the contents of previous hunks in output for later ones. Signed-off-by: Junio C Hamano <junkio@cox.net> 04 April 2007, 02:01:36 UTC
a8f4ef7 Hopefully final update to the draft Release Notes, preparing for 1.5.1 Signed-off-by: Junio C Hamano <junkio@cox.net> 02 April 2007, 20:29:38 UTC
d8b6a1a cvsserver: Don't lie about binary mode in asciidoc documentation The git-cvsserver documentation claims that the server will set -k modes if appropriate which is not really the case. On the other hand the available gitcvs.allbinary variable is not documented at all. Fix both these issues by rewording the related paragraph. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 23:00:27 UTC
d6bad66 git-svn: fail on rebase if we are unable to find a ref to rebase against If we're on an invalid HEAD, we should detect this and avoid attempting to continue. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 22:22:59 UTC
a97e407 Keep rename/rename conflicts of intermediate merges while doing recursive merge This patch leaves the base name in the resulting intermediate tree, to propagate the conflict from intermediate merges up to the top-level merge. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 20:39:15 UTC
4f01748 contrib/workdir: add a simple script to create a working directory Add a simple script to create a working directory that uses symlinks to point at an exisiting repository. This allows having different branches in different working directories but all from the same repository. Based on a description from Junio of how he creates multiple working directories[1]. With the following caveat: "This risks confusion for an uninitiated if you update a ref that is checked out in another working tree, but modulo that caveat it works reasonably well." [1] http://article.gmane.org/gmane.comp.version-control.git/41513/ Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 08:26:28 UTC
4557e0d Reimplement emailing part of hooks--update in contrib/hooks/post-receive-email The update hook is no longer the correct place to generate emails; there is now the hooks/post-receive script which is run automatically after a ref has been updated. This patch is to make use of that new location, and to address some faults in the old update hook. The primary problem in the conversion was that in the update hook, the ref has not actually been changed, but is about to be. In the post-receive hook the ref has already been updated. That meant that where we previously had lines like: git rev-list --not --all would now give the wrong list because "--all" in the post-receive hook includes the ref that we are making the email for. This made it more difficult to show only the new revisions added by this update. The solution is not pretty; however it does work and doesn't need any changes to git-rev-list itself. It also fixes (more accurately: reduces the likelihood of) a nasty race when another update occurs while this script is running. The solution, in short, looks like this (see the source code for a longer explanation) git rev-parse --not --all | grep -v $(git rev-parse $refname) | git rev-list --pretty --stdin $oldrev..$newrev This uses git-rev-parse followed by grep to filter out the revision of the ref in question before it gets to rev-list and inhibits the output of itself. By using $(git rev-parse $revname) rather than $newrev as the filter, it also takes care of the situation where another update to the same ref has been made since $refname was $newrev. The second problem that is addressed is that of tags inhibiting the correct output of an update email. Consider this, with somebranch and sometag pointing at the same revision: git push origin somebranch git push origin sometag That would work fine; the push of the branch would generate an email containing all the new commits introduced by the update, then the push of the tag would generate the shortlog formatted tag email. Now consider: git push origin sometag git push origin somebranch When some branch comes to run its "--not --all" line, it will find sometag, and filter those commits from the email - leaving nothing. That meant that those commits would not show (in full) on any email. The fix is to not use "--all", and instead use "--branches" in the git-rev-parse command. Other changes * Lose the monstrous one-giant-script layout and put things in easy to digest functions. This makes it much easier to find the place you need to change if you wanted to customise the output. I've also tried to write more verbose comments for the same reason. The hook script is big, mainly because of all the different cases that it has to handle, so being easy to navigate is important. * All uses of "git-command" changed to "git command", to cope better if a user decided not to install all the hard links to git; * Cleaned up some of the English in the email * The fact that the receive hook makes the ref available also allows me to use Shawn Pearce's fantastic suggestion that an annotated tag can be parsed with git-for-each-ref. This removes the potentially non-portable use of "<<<" heredocs and the nasty messing around with "date" to convert numbers of seconds UTC to a real date * Deletions are now caught and notified (briefly) * To help with debugging, I've retained the command line mode from the update hook; but made it so that the output is not emailed, it's just printed to the screen. This could then be redirected if the user wanted * Removed the "Hello" from the beginning of the email - it's just noise, and no one seriously has their day made happier by "friendly" programs * The fact that it doesn't rely on repository state as an indicator any more means that it's far more stable in its output; hopefully the same arguments will always generate the same email - even if the repository changes in the future. This means you can easily recreate an email should you want to. * Included Jim Meyering's envelope sender option for the sendmail call * The hook is now so big that it was inappropriate to copy it to every repository by keeping it in the templates directory. Instead, I've put a comment saying to look in contrib/hooks, and given an example of calling the script from that template hook. The advantage of calling the script residing at some fixed location is that if a future package of git included a bug fixed version of the script, that would be picked up automatically, and the user would not have to notice and manually copy the new hook to every repository that uses it. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 08:21:18 UTC
a6a15a9 git-svn: avoid respewing similar error messages for missing paths We ignore errors if the path we're tracking did not exist for a particular revision range, but we still print out warnings telling the user about that. As pointed out by Seth Falcon, this amounts to a lot of warnings that could confuse and worry users. I'm not entirely comfortable completely silencing the warnings, but showing one warning per path that we track should be reasonable. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 08:11:13 UTC
46efd2d Rename warn() to warning() to fix symbol conflicts on BSD and Mac OS This fixes a problem reported by Randal Schwartz: >I finally tracked down all the (albeit inconsequential) errors I was getting >on both OpenBSD and OSX. It's the warn() function in usage.c. There's >warn(3) in BSD-style distros. It'd take a "great rename" to change it, but if >someone with better C skills than I have could do that, my linker and I would >appreciate it. It was annoying to me, too, when I was doing some mergetool testing on Mac OS X, so here's a fix. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: "Randal L. Schwartz" <merlyn@stonehenge.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 08:11:11 UTC
86747c1 git-mailinfo fixes for patch munging Don't translate the patch to UTF-8, instead preserve the data as is. This also reverts a test case that was included in the original patch series. Also allow overwriting the authorship and title information we gather from RFC2822 mail headers with additional in-body headers, which was pointed out by Linus. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 07:59:19 UTC
5ae917a gitweb: Support comparing blobs (files) with different names Fix the bug that caused "blobdiff" view called with new style URI for a rename with change diff to be show as new (added) file diff. New style URI for "blobdiff" for rename means with $hash_base ('hb') and $hash_parent_base ('hpb') paramaters denoting tree-ish (usually commit) of a blobs being compared, together with both $file_name ('f') and $file_parent ('fp') parameters. It is done by adding $file_parent ('fp') to the path limiter, meaning that diff command becomes: git diff-tree [options] hpb hb -- fp f Other option would be finding hash of a blob using git_get_hash_by_path subroutine and comparing blobs using git-diff, or using extended SHA-1 syntax and compare blobs using git-diff: git diff [options] hpb:fp hp:f Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 31 March 2007, 07:47:48 UTC
aa45321 Do not bother documenting fetch--tool Signed-off-by: Junio C Hamano <junkio@cox.net> 30 March 2007, 08:03:09 UTC
a208362 Update draft release notes for 1.5.1 Signed-off-by: Junio C Hamano <junkio@cox.net> 30 March 2007, 07:56:36 UTC
e881192 Merge branch 'maint' * maint: git-upload-pack: make sure we close unused pipe ends Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES. Documentation/git-svnimport.txt: fix typo. 30 March 2007, 06:44:30 UTC
b275a0c git-quiltimport /bin/sh-ism fix Bryan Wu reported /usr/local/bin/git-quiltimport: 114: Syntax error: Missing '))' Most bourne-ish shells I have here accept x=$((echo x)|cat) but all bourne-ish shells I have here accept x=$( (echo x)|cat) because $(( might mean arithmetic expansion. Signed-off-by: Francis Daly <francis@daoine.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 30 March 2007, 06:11:33 UTC
6f01e6b Bisect: Improve error message in "bisect_next_check". So we can remove the specific message in "bisect_run". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 30 March 2007, 06:10:21 UTC
18acb3e Merge branch 'master' of git://repo.or.cz/git/mergetool.git * 'master' of git://repo.or.cz/git/mergetool.git: mergetool: Clean up description of files and prompts for merge resolutions mergetool: Make git-rm quiet when resolving a deleted file conflict mergetool: Add support for Apple Mac OS X's opendiff command mergetool: Fix abort command when resolving symlinks and deleted files mergetool: Remove spurious error message if merge.tool config option not set mergetool: factor out common code mergetool: portability fix: don't use reserved word function mergetool: portability fix: don't assume true is in /bin mergetool: Don't error out in the merge case where the local file is deleted mergetool: Replace use of "echo -n" with printf(1) to be more portable Fix minor formatting issue in man page for git-mergetool 30 March 2007, 06:09:40 UTC
27090aa mergetool: Clean up description of files and prompts for merge resolutions This fixes complaints from Junio for how messages and prompts are printed when resolving symlink and deleted file merges. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 30 March 2007, 02:46:16 UTC
1346c99 mergetool: Make git-rm quiet when resolving a deleted file conflict Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:29:54 UTC
365cf97 mergetool: Add support for Apple Mac OS X's opendiff command Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:29:53 UTC
5a174f1 mergetool: Fix abort command when resolving symlinks and deleted files Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:29:52 UTC
b7b36f9 mergetool: Remove spurious error message if merge.tool config option not set Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:29:48 UTC
ddc0c49 mergetool: factor out common code Create common function check_unchanged(), save_backup() and remove_backup(). Also fix some minor whitespace issues while we're at it. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:29:33 UTC
262c981 mergetool: portability fix: don't use reserved word function Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:23:01 UTC
d1dc695 mergetool: portability fix: don't assume true is in /bin Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:22:50 UTC
ce5b6d7 mergetool: Don't error out in the merge case where the local file is deleted If the file we are trying to merge resolve is in git-ls-files -u, then skip the file existence test. If the file isn't reported in git-ls-files, then check to see if the file exists or not to give an appropriate error message. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:22:48 UTC
20fa04e mergetool: Replace use of "echo -n" with printf(1) to be more portable Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 16:22:44 UTC
e15b484 Fix minor formatting issue in man page for git-mergetool Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> 29 March 2007, 14:06:28 UTC
3ac53e0 git-upload-pack: make sure we close unused pipe ends Right now, we don't close the read end of the pipe when git-upload-pack runs git-pack-object, so we hang forever (why don't we get SIGALRM?) instead of dying with SIGPIPE if the latter dies, which seems to be the norm if the client disconnects. Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for pointing out where this close() needed to go. This patch has been tested on kernel.org for several weeks and appear to resolve the problem of git-upload-pack processes hanging around forever. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from commit 465b3518a9ad5080a4b652ef35fb13c61a93e7a4) 29 March 2007, 08:41:23 UTC
c2c6d93 Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES. Please see http://bugs.debian.org/404795: In git-rev-parse(1), there is an example commit tree, which is used twice. The explanation for this tree is very clear: B and C are commit *parents* to A. However, when the tree is reused as an example in the SPECIFYING RANGES, the manpage author screws up and uses A as a commit *parent* to B and C! I.e., he inverts the tree. And the fact that for this example you need to read the tree backwards is not explained anywhere (and it would be confusing even if it was). Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 March 2007, 08:38:28 UTC
3e63e0d Documentation/git-svnimport.txt: fix typo. This was noticed by Frederik Schwarzer. SVN's repository by default has trunk, tags/, and branch_es_/. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 29 March 2007, 08:38:11 UTC
7685227 GIT 1.5.1-rc3 28 March 2007, 22:58:09 UTC
43a8e4f Update main git.html page to point at 1.5.0.6 documentation Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 22:40:17 UTC
0a98f9d Merge branch 'maint' to synchronize with 1.5.0.6 28 March 2007, 22:39:57 UTC
9529a25 GIT 1.5.0.6 28 March 2007, 22:28:14 UTC
d0e50cb commit: fix pretty-printing of messages with "\nencoding " The function replace_encoding_header is given the whole commit buffer, including the commit message. When looking for the encoding header, if none was found in the header, it would locate any line in the commit message matching "\nencoding " and remove it. Instead, we now make sure to search only to the end of the header. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 22:06:18 UTC
75c962c t4118: be nice to non-GNU sed Elias Pipping: > I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes > t4118 fail. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Ack'd-by: Elias Pipping <pipping@macports.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 21:54:30 UTC
03bcaac t/t6006: add tests for a slightly more complex commit messages Especially this tests i18n messages and encoding header. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 21:28:00 UTC
6a5ea2d Fix "--pretty=format:" encoding item It printed the header "encoding " instead of just showing the encoding, as all other items do. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 21:27:43 UTC
542e165 Fix "--pretty=format:" for parent related items. There are two breakages in the %P/%p interpolation. It appended an excess SP at the end of the list, and it gave uninitialized contents of a buffer on the stack for root commits. This fixes it, while updating the t6006 test which expected the wrong output. Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 20:44:04 UTC
9c880b3 http-fetch: remove path_len from struct alt_base, it was computed but never used Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 11:44:23 UTC
2afea3b http-fetch: don't use double-slash as directory separator in URLs Please see http://bugs.debian.org/409887 http-fetch expected the URL given at the command line to have a trailing slash anyway, and then added '/objects...' when requesting objects files from the http server. Now it doesn't require the trailing slash in <url> anymore, and strips trailing slashes if given nonetheless. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 11:44:16 UTC
d3e41eb git-commit: "read-tree -m HEAD" is not the right way to read-tree quickly It still looks at the working tree and checks for locally modified paths. When are preparing a temporary index from HEAD, we do not want any of that. Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 10:34:55 UTC
fa21b60 Add some basic tests of rev-list --pretty=format These could stand to be a little more complex, but it should at least catch obvious problems (like the recently fixed %ct bug). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 01:57:01 UTC
465b351 git-upload-pack: make sure we close unused pipe ends Right now, we don't close the read end of the pipe when git-upload-pack runs git-pack-object, so we hang forever (why don't we get SIGALRM?) instead of dying with SIGPIPE if the latter dies, which seems to be the norm if the client disconnects. Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for pointing out where this close() needed to go. This patch has been tested on kernel.org for several weeks and appear to resolve the problem of git-upload-pack processes hanging around forever. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 00:05:12 UTC
4621af3 --pretty=format: fix broken %ct and %at interpolation A pointer arithmetic error in fill_person caused random data from the commit object to be included with the timestamp, which looked something like: $ git-rev-list --pretty=format:%ct origin/next | head commit 98453bdb3db10db26099749bc4f2dc029bed9aa9 1174977948 -0700 Merge branch 'master' into next * master: Bisect: Use commit c0ce981f5ebfd02463ff697b2fca52c7a54b0625 1174889646 -0700 Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 28 March 2007, 00:04:26 UTC
c6e0caa use xrealloc in help.c Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 23:57:57 UTC
aa4cfa8 read-tree: use xcalloc Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 23:57:26 UTC
608d48b Fix "getaddrinfo()" buglet At least in Linux glibc, "getaddrinfo()" has a very irritating feature (or bug, who knows..). Namely if you pass it in an empty string for the service name, it will happily and quietly consider it identical to a NULL port pointer, and return port number zero and no errors. Which obviously will not work. Maybe that's what it's really expected to do, although the man-page for getaddrinfo() certainly implies that it's a bug. So when somebody passes me a "please pull" request pointing to something like the following git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git (note the extraneous colon at the end of the host name), git would happily try to connect to port 0, which would generally just cause the remote to not even answer, and the "connect()" will take a long time to time out. So to work around the glibc feature/bug, just notice this empty port case automatically. Also, add the port information to the error information when it fails to look up (maybe it's the host-name that fails, maybe it's the port-name - we should print out both). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 20:00:13 UTC
66d5871 Makefile: remove test-chmtime program in target clean. While running 'make test', the test-chmtime program is created, and should be cleaned up on 'make clean'. Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:58:46 UTC
f73bbb2 gitweb: Cleanup and uniquify die_error calls Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:58:23 UTC
e82973c sha1_file.c (write_sha1_file): Detect close failure This is in the same spirit as earlier fix to write_sha1_from_fd(). Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:56:01 UTC
b704e58 git.el: Display some information about the HEAD commit. Use git-log --pretty=oneline to print a short description of the current HEAD (and merge heads if any) in the buffer header. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:52:41 UTC
89d5892 Document git-log --first-parent Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:51:13 UTC
8302012 Bisect: add checks at the beginning of "git bisect run". We may be able to "run" with only one good revision given and then verify that the result of the first run is bad. And perhaps also the other way around. But for now let's check that we have at least one bad and one good revision before we start to run. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:48:30 UTC
0d31546 sha1_file.c (write_sha1_from_fd): Detect close failure. I stumbled across this in the context of the fchmod 0444 patch. At first, I was going to unlink and call error like the two subsequent tests do, but a failed write (above) provokes a "die", so I made this do the same. This is testing for a write failure, after all. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:43:49 UTC
e4d9516 git-rm: don't remove newly added file without -f Given this set of commands: $ echo "newly added file" >new $ git add new $ git rm new the file "new" was previously removed from the working directory and the index. Because it was not in HEAD, it is available only by searching for unreachable objects. Instead, we now err on the safe side and refuse to remove a file which is not referenced by HEAD. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 27 March 2007, 19:43:39 UTC
c0ce981 Bisect: Use "git-show-ref --verify" when reseting. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 06:14:06 UTC
52c813f gitweb: Add example of config file and how to generate projects list to gitweb/INSTALL Add simple example of config file (turning on and allowing override of a few %features). Also example config file and script to generate list of projects in a format that can be used as GITWEB_LIST / $projects_list. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 05:22:33 UTC
b6da18b GIT 1.5.1-rc2 Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 01:01:50 UTC
0b59451 git-svn: fix rel_path() when not connected to the repository root This should fix fetching for people who did not use "git svn --minimize" or cannot connect to the repository root due to the lack of permissions. I'm not sure what I was on when I made the change to the rel_path() function in 4e9f6cc78e5d955bd0faffe76ae9aea6590189f1 that made it die() when we weren't connected to the repository root :x Thanks to Sven Verdoolaege for reporting this bug. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 01:01:28 UTC
3301521 use xmalloc in git.c and help.c Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 01:00:23 UTC
3a81b9f Merge branch 'jc/fpl' * jc/fpl: git-log --first-parent: show only the first parent log 26 March 2007, 00:47:07 UTC
620d3f4 Update README to point at a few key periodical messages to the list They give a good starting point to new people who want to get involved. This owes suggestions by Martin Langhoff and Steven Grimm. Signed-off-by: Junio C Hamano <junkio@cox.net> 26 March 2007, 00:42:32 UTC
2603fa5 Merge branch 'maint' * maint: user-manual: introduce "branch" and "branch head" differently glossary: clean up cross-references glossary: stop generating automatically user-manual: Use def_ instead of ref_ for glossary references. user-manual.txt: fix a tiny typo. user-manual: run xsltproc without --nonet option 25 March 2007, 22:08:11 UTC
fd2a759 Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint * 'maint' of git://linux-nfs.org/~bfields/git: user-manual: introduce "branch" and "branch head" differently glossary: clean up cross-references glossary: stop generating automatically user-manual: Use def_ instead of ref_ for glossary references. user-manual.txt: fix a tiny typo. user-manual: run xsltproc without --nonet option 25 March 2007, 22:07:27 UTC
c5a07b3 Merge branch 'js/remote-show-push' * js/remote-show-push: Teach git-remote to list pushed branches. 25 March 2007, 08:45:06 UTC
12d6697 Merge branch 'maint' * maint: gitweb: Add some installation notes in gitweb/INSTALL gitweb: Fix not marking signoff lines in "log" view gitweb: Don't escape attributes in CGI.pm HTML methods gitweb: Change to use explicitly function call cgi->escapHTML() 25 March 2007, 07:21:40 UTC
06aff47 Use diff* with --exit-code in git-am, git-rebase and git-merge-ours This simplifies the shell code, reduces its memory footprint, and speeds things up. The performance improvements should be noticable when git-rebase works on big commits. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 06:01:36 UTC
2a18c26 Document --quiet option to git-diff Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:32:55 UTC
b5b8d81 write_sha1_from_fd() should make new objects read-only ... like it is done everywhere else. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:32:41 UTC
0e55181 make it more obvious that temporary files are temporary files When some operations are interrupted (or "die()'d" or crashed) then the partial object/pack/index file may remain around. Make it more obvious in their name that those files are temporary stuff and can be cleaned up if no operation is in progress. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:32:39 UTC
46d409d update-hook: remove e-mail sending hook. The update hook's only job is to decide is a particular update is allowed or not. It was not the right place to send out update notification e-mails from to begin with, as the final stage of updating refs can fail after this hook runs. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:30:53 UTC
cd67c8e gitweb: Add some installation notes in gitweb/INSTALL Add some installation and configuration notes for gitweb in gitweb/INSTALL. Make use of filling gitweb configuration by Makefile. It does not cover (yet?) all the configuration variables and options. Some of contents duplicates information in gitweb/README file (it is referred from gitweb/INSTALL). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:26:33 UTC
4ae89b7 gitweb: Fix not marking signoff lines in "log" view The CSS selector for signoff lines style was too strict: in the "log" view the commit message is not encompassed in container "page_body" div. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:25:55 UTC
346d5e1 gitweb: Don't escape attributes in CGI.pm HTML methods There is no need to escape HTML tag's attributes in CGI.pm HTML methods (like CGI::a()), because CGI.pm does attribute escaping automatically. $cgi->a({ ... -attribute => atribute_value }, tag_contents) is translated to <a ... attribute="attribute_value">tag_contents</a> The rules for escaping attribute values (which are string contents) are different. For example you have to take care about escaping embedded '"' and "'" characters; CGI::a() does that for us automatically. CGI::a() does not HTML escape tag_contents; we would need to write <a href="URL">some <b>bold</b> text</a> for example. So we use esc_html (or esc_path) to escape tag_contents as needed. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:25:47 UTC
290b146 gitweb: Change to use explicitly function call cgi->escapHTML() Change to use explicitly function call cgi->escapHTML(). This fix the problem on some systems that escapeHTML() is not functioning, as default CGI is not setting 'escape' parameter. Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 March 2007, 05:25:40 UTC
2499857 git-am documentation: describe what is taken from where. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 10:08:54 UTC
e43b010 git-revert: Revert revert message to old behaviour When converting from the shell script, based on a misreading of the sed invocation, the builtin included the abbreviated commit name, and did _not_ include the quotes around the oneline message. This fixes it. [jc: with a fix for the typo/thinko spotted by Linus, and also removing the unwanted abbrev at the beginning.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 09:50:22 UTC
b08bbae Merge branch 'maint' * maint: gitweb: Fix "next" link in commit view 24 March 2007, 06:29:37 UTC
6cea055 Documentation: bisect: make a comment fit better in the man page. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:29:29 UTC
1207f9e Documentation: bisect: add some titles to some paragraphs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:29:09 UTC
fed820a Documentation: bisect: reformat more paragraphs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:26:11 UTC
cc070d1 Documentation: bisect: reword one paragraph. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:26:02 UTC
7891a28 Documentation: bisect: reformat some paragraphs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 06:25:54 UTC
a4e9d71 Fix path-limited "rev-list --bisect" termination condition. In a path-limited bisection, when the $bad commit is not changing the limited path, and the number of suspects is 1, the code miscounted and returned $bad from find_bisection(), which is not marked with TREECHANGE. This is of course filtered by the output routine, resulting in an empty output, in turn causing git-bisect driver to say "$bad was both good and bad". Illustration. Suppose you have these four commits, and only C changes path P. You know D is bad and A is good. A---B---C*--D git-bisect driver runs this to find a bisection point: $ git rev-list --bisect A..D -- P which calls find_bisection() with B, C and D. The set of commits that is given to this function is the same set of commits as rev-list without --bisect option and pathspec returns. Among them, only C is marked with TREECHANGE. Let's call the set of commits given to find_bisection() that are marked with TREECHANGE (or all of them if no path limiter is in effect) "the bisect set". In the above example, the size of the bisect set is 1 (contains only "C"). For each commit in its input, find_bisection() computes the number of commits it can reach in the bisect set. For a commit in the bisect set, this number includes itself, so the number is 1 or more. This number is called "depth", and computed by count_distance() function. When you have a bisect set of N commits, and a commit has depth D, how good is your bisection if you returned that commit? How good this bisection is can be measured by how many commits are effectively tested "together" by testing one commit. Currently you have (N-1) untested commits (the tip of the bisect set, although it is included in the bisect set, is already known to be bad). If the commit with depth D turns out to be bad, then your next bisect set will have D commits and you will have (D-1) untested commits left, which means you tested (N-1)-(D-1) = (N-D) commits with this bisection. If it turns out to be good, then your next bisect set will have (N-D) commits, and you will have (N-D-1) untested commits left, which means you tested (N-1)-(N-D-1) = D commits with this bisection. Therefore, the goodness of this bisection is is min(N-D, D), and find_bisection() function tries to find a commit that maximizes this, by initializing "closest" variable to 0 and whenever a commit with the goodness that is larger than the current "closest" is found, that commit and its goodness are remembered by updating "closest" variable. The "the commit with the best goodness so far" is kept in "best" variable, and is initialized to a commit that happens to be at the beginning of the list of commits given to this function (which may or may not be in the bisect set when path-limit is in use). However, when N is 1, then the sole tree-changing commit has depth of 1, and min(N-D, D) evaluates to 0. This is not larger than the initial value of "closest", and the "so far the best one" commit is never replaced in the loop. When path-limit is not in use, this is not a problem, as any commit in the input set is tree-changing. But when path-limit is in use, and when the starting "bad" commit does not change the specified path, it is not correct to return it. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 March 2007, 00:20:43 UTC
f9308a1 gitweb: Fix "next" link in commit view Fix copy'n'paste error in commit c9d193df which caused that "next" link for merge commits in "commit" view (merge: _commit_ _commit_ ...) was to "commitdiff" view instead of being to "commit" view. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 21:54:52 UTC
12cb813 git-bisect.sh: properly dq $GIT_DIR Otherwise you would be in trouble if your GIT_DIR has IFS letters in it. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 20:29:55 UTC
673e583 git-bisect: typofix The branch you are on while bisecting is always "bisect", and checking for "refs/heads/bisect*" is wrong. Only check if it is exactly "refs/heads/bisect". Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 20:15:21 UTC
abba9db checkout: report where the new HEAD is upon detaching HEAD After "git reset" moves the HEAD around, it reports which commit you are on, which gives the user a warm fuzzy feeling of assurance. Give the same assurance from git-checkout when moving the detached HEAD around. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 09:48:09 UTC
a17c410 Bisect: implement "git bisect run <cmd>..." to automatically bisect. This idea was suggested by Bill Lear (Message-ID: <17920.38942.364466.642979@lisa.zopyra.com>) and I think it is a very good one. This patch adds a new test file for "git bisect run", but there is currently only one basic test. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 08:54:47 UTC
cc65343 Bisect: convert revs given to good and bad to commits Without this the rev could be (e.g.) a tag and then the condition to end the bisect might fail and you have to check the already known to be bad revision once more. Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 08:48:29 UTC
3007a78 t4118: be nice to non-GNU sed Elias Pipping: > I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes > t4118 fail. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Ack'd-by: Elias Pipping <pipping@macports.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 01:08:37 UTC
cc96fd0 git-apply: Do not free the wrong buffer when we convert the data for writeout When we write out the result of patch application, we sometimes need to munge the data (e.g. under core.autocrlf). After doing so, what we should free is the temporary buffer that holds the converted data returned from convert_to_working_tree(), not the original one. This patch also moves the call to open() up in the function, as the caller expects us to fail cheaply if leading directories need to be created (and then the caller creates them and calls us again). For that calling pattern, attempting conversion before opening the file adds unnecessary overhead. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 March 2007, 00:32:51 UTC
00cec84 Merge git://git2.kernel.org/pub/scm/gitk/gitk * git://git2.kernel.org/pub/scm/gitk/gitk: [PATCH] prefer "git COMMAND" over "git-COMMAND" in gitk 22 March 2007, 10:05:34 UTC
back to top