swh:1:snp:47f1e8bb459169b0feb652a9c3d9cbabd8526d4a

sort by:
Revision Author Date Message Commit Date
ce33288 GIT 1.5.4-rc4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 January 2008, 01:05:11 UTC
105c21d Merge git://repo.or.cz/git-gui * git://repo.or.cz/git-gui: git-gui: Makefile - Handle $DESTDIR on Cygwin git-gui: add french glossary: glossary/fr.po git-gui: Refresh file status description after hunk application git-gui: Allow 'Create New Repository' on existing directories git-gui: Initial french translation git-gui: Improve German translation. git-gui: Updated Swedish translation after mailing list review. git-gui: Fix broken revert confirmation. git-gui: Update German translation git-gui: Update glossary: add term "hunk" 21 January 2008, 00:58:38 UTC
a41acc6 Merge git://git.kernel.org/pub/scm/gitk/gitk * git://git.kernel.org/pub/scm/gitk/gitk: [PATCH] gitk: make Ctrl "+" really increase the font size 21 January 2008, 00:57:56 UTC
3057ded http-push and http-fetch: handle URLs without trailing / The URL to a repository http-push and http-fetch takes should have a trailing slash. Instead of failing the request, add it ourselves before attempting such a request. Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 January 2008, 23:18:34 UTC
325ce39 http-push: clarify the reason of error from the initial PROPFIND request The first thing http-push does is a PROPFIND to see if the other end supports locking. The failure message we give is always reported as "no DAV locking support at the remote repository", regardless of the reason why we ended up not finding the locking support on the other end. This moves the code to report "no DAV locking support" down the codepath so that the message is issued only when we successfully get a response to PROPFIND and the other end say it does not support locking. Other failures, such as connectivity glitches and credential mismatches, have their own error message issued and we will not issue "no DAV locking" error (we do not even know if the remote end supports it). Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 January 2008, 23:17:58 UTC
9bdbaba http-push: fail when info/refs exists and is already locked Failing instead of silently not updating remote refs makes the things clearer for the user when trying to push on a repository while another person do (or while a dandling locks are waiting for a 10 minutes timeout). When silently not updating remote refs, the user does not even know that git has pushed the objects but leaved the refs as they were before (e.g. a new bunch of commits on branch "master" is uploaded, however the branch by itsel still points on the previous head commit). Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 January 2008, 23:17:58 UTC
9116de5 http-push: fix webdav lock leak. Releasing webdav lock even if push fails because of bad (or no) reference on command line. To reproduce the issue that this patch fixes, prepare a test repository availlable over http+webdav, say at http://myhost/myrepo.git/ Then: $ git clone http://myhost/myrepo.git/ $ cd myrepo $ git push http Fetching remote heads... refs/ refs/heads/ refs/tags/ No refs in common and none specified; doing nothing. $ git push http Fetching remote heads... refs/ refs/heads/ refs/tags/ No refs in common and none specified; doing nothing. $ Finally, you look at the web server logs, and will find one LOCK query and no UNLOCK query, of course the second one will be in 423 return code instead of 200: 1.2.3.4 - gb [19/Jan/2008:14:24:56 +0100] "LOCK /myrepo.git/info/refs HTTP/1.1" 200 465 (...) 1.2.3.4 - gb [19/Jan/2008:14:25:10 +0100] "LOCK /myrepo.git/info/refs HTTP/1.1" 423 363 With this patch, there would have be two UNLOCKs in addition of the LOCKs From the user's point of view: - If you realize that you should have typed e.g. "git push http master" instead of "git push http", you will have to wait for 10 minutes for the lock to expire by its own. - Furthermore, if somebody else is dumb enough to type "git push http" while you need to push "master" branch, then you'll need too to wait for 10 minutes too. Signed-off-by: Gr.ANigoire Barbier <gb@gbarbier.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 January 2008, 23:17:58 UTC
0a61779 parse_commit_buffer: tighten checks while parsing This tightens the parsing of a commit object in a couple of ways. - The "tree " header must end with a LF (earlier we did not check this condition). - Make sure parsing of timestamp on the "committer " header does not go beyond the buffer, even when (1) the "author " header does not end with a LF (this means that the commit object is malformed and lacks the committer information) or (2) the "committer " header does not have ">" that is the end of the e-mail address, or (3) the "committer " header does not end with a LF. We however still keep the existing behaviour to return a parsed commit object even when non-structural headers such as committer and author are malformed, so that tools that need to look at commits to clean up a history with such broken commits can still get at the structural data (i.e. the parents chain and the tree object). Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 January 2008, 19:00:57 UTC
a3b811a Update git-completion for new 'remote rm' option Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 January 2008, 07:06:02 UTC
233808d doc typo: s/prior committing/prior to committing/ Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 January 2008, 19:25:37 UTC
fdcf39e Include rev-list options in git-log manpage. Replace the "This manual page describes only the most frequently used options." text with the list of rev-list options in git-log manpage. (The git-diff-tree options are already included.) Move these options to a separate file and include it from both git-rev-list.txt and git-log.txt. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 23:09:08 UTC
f854824 http-push: disable http-push without USE_CURL_MULTI Make http-push always fail when not compiled with USE_CURL_MULTI, since otherwise it corrupts the remote repository (and then fails anyway). Signed-off-by: Grégoire Barbier <gb@gbarbier.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 21:50:06 UTC
c764a0c send-email: add no-validate option Since we are now sanity-checking the contents of patches and refusing to send ones with long lines, this knob provides a way for the user to override the new behavior (if, e.g., he knows his SMTP path will handle it). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 21:33:57 UTC
747bbff send-email: validate patches before sending anything We try to catch errors early so that we don't end up sending half of a broken patch series. Right now the only validation is checking that line-lengths are under the SMTP-mandated limit of 998. The validation parsing is very crude (it just checks each line length without understanding the mailbox format) but should work fine for this simple check. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 21:33:08 UTC
aa54892 send-email: detect invocation errors earlier We never even look at the command line arguments until after we have prompted the user for some information. So running "git send-email" without arguments would prompt for "from" and "to" headers, only to then die with "No patch files specified." Instead, let's try to do as much error checking as possible before getting user input. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 21:29:32 UTC
5a7b1b5 fast-import: Don't use a maybe-clobbered errno value Without this change, each diagnostic could use an errno value clobbered by the close or unlink in rollback_lock_file. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 21:19:37 UTC
1812564 Move sha1_file_to_archive into libgit When the specfile (export-subst) attribute was introduced, it added a dependency from archive-{tar|zip}.c to builtin-archive.c. This broke the support for archive-operations in libgit.a since builtin-archive.o doesn't belong in libgit.a. This patch moves the functions required by libgit.a from builtin-archive.c to the new file archive.c (which becomes part of libgit.a). Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 20:33:50 UTC
472ca78 color unchanged lines as "plain" in "diff --color-words" These were mistakenly being colored in "meta" color. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 09:29:38 UTC
bfa8fcc autoconf: Add checking for unsetenv function Update configure.ac (and config.mak.in) by adding test for unsetenv (NO_UNSETENV). Add comment about NO_UNSETENV to Makefile header, as original commit 731043fd adding compat/unsetenv.c didn't do that. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 07:35:36 UTC
5221ecb core-tutorial typofix Signed-off-by: Thomas Zander <zander@kde.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 06:55:25 UTC
5c66d0d Officially deprecate repo-config. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 06:52:40 UTC
c9ced05 Fix random fast-import errors when compiled with NO_MMAP fast-import was relying on the fact that on most systems mmap() and write() are synchronized by the filesystem's buffer cache. We were relying on the ability to mmap() 20 bytes beyond the current end of the file, then later fill in those bytes with a future write() call, then read them through the previously obtained mmap() address. This isn't always true with some implementations of NFS, but it is especially not true with our NO_MMAP=YesPlease build time option used on some platforms. If fast-import was built with NO_MMAP=YesPlease we used the malloc()+pread() emulation and the subsequent write() call does not update the trailing 20 bytes of a previously obtained "mmap()" (aka malloc'd) address. Under NO_MMAP that behavior causes unpack_entry() in sha1_file.c to be unable to read an object header (or data) that has been unlucky enough to be written to the packfile at a location such that it is in the trailing 20 bytes of a window previously opened on that same packfile. This bug has gone unnoticed for a very long time as it is highly data dependent. Not only does the object have to be placed at the right position, but it also needs to be positioned behind some other object that has been accessed due to a branch cache invalidation. In other words the stars had to align just right, and if you did run into this bug you probably should also have purchased a lottery ticket. Fortunately the workaround is a lot easier than the bug explanation. Before we allow unpack_entry() to read data from a pack window that has also (possibly) been modified through write() we force all existing windows on that packfile to be closed. By closing the windows we ensure that any new access via the emulated mmap() will reread the packfile, updating to the current file content. This comes at a slight performance degredation as we cannot reuse previously cached windows when we update the packfile. But it is a fairly minor difference as the window closes happen at only two points: - When the packfile is finalized and its .idx is generated: At this stage we are getting ready to update the refs and any data access into the packfile is going to be random, and is going after only the branch tips (to ensure they are valid). Our existing windows (if any) are not likely to be positioned at useful locations to access those final tip commits so we probably were closing them before anyway. - When the branch cache missed and we need to reload: At this point fast-import is getting change commands for the next commit and it needs to go re-read a tree object it previously had written out to the packfile. What windows we had (if any) are not likely to cover the tree in question so we probably were closing them before anyway. We do try to avoid unnecessarily closing windows in the second case by checking to see if the packfile size has increased since the last time we called unpack_entry() on that packfile. If the size has not changed then we have not written additional data, and any existing window is still vaild. This nicely handles the cases where fast-import is going through a branch cache reload and needs to read many trees at once. During such an event we are not likely to be updating the packfile so we do not cycle the windows between reads. With this change in place t9301-fast-export.sh (which was broken by c3b0dec509fe136c5417422f31898b5a4e2d5e02) finally works again. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 06:39:20 UTC
fb54abd fast-import.c: don't try to commit marks file if write failed We also move the assignment of -1 to the lock file descriptor up, so that rollback_lock_file() can be called safely after a possible attempt to fclose(). This matches the contents of the 'if' statement just above testing success of fdopen(). Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 January 2008, 06:11:42 UTC
a028557 git-gui: Makefile - Handle $DESTDIR on Cygwin gg_libdir is converted to an absolute Windows path on Cygwin, but a later step attempts to prefix $DESTDIR to install to a staging directory. Explicitly separate the uses of gg_libdir for these two purposes so installation to $DESTDIR will work. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 January 2008, 03:58:24 UTC
a1f8f50 git-gui: add french glossary: glossary/fr.po Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 January 2008, 02:35:01 UTC
b531394 refs.c: rework ref_locks by abstracting from underlying struct lock_file Instead of calling close_lock_file() and commit_lock_file() directly, which take a struct lock_file argument, add two new functions: close_ref() and commit_ref(), which handle calling the previous lock_file functions and modifying the ref_lock structure. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 23:36:10 UTC
4ed7cd3 Improve use of lockfile API Remove remaining double close(2)'s. i.e. close() before commit_locked_index() or commit_lock_file(). Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 23:35:35 UTC
d6cf61b close_lock_file(): new function in the lockfile API The lockfile API is a handy way to obtain a file that is cleaned up if you die(). But sometimes you would need this sequence to work: 1. hold_lock_file_for_update() to get a file descriptor for writing; 2. write the contents out, without being able to decide if the results should be committed or rolled back; 3. do something else that makes the decision --- and this "something else" needs the lockfile not to have an open file descriptor for writing (e.g. Windows do not want a open file to be renamed); 4. call commit_lock_file() or rollback_lock_file() as appropriately. This adds close_lock_file() you can call between step 2 and 3 in the above sequence. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 23:35:03 UTC
0c0478c Document lockfile API We have nice set of placeholders, but nobody stepped in to fill the gap in the API documentation, so I am doing it myself. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 20:42:37 UTC
c3b0dec Be more careful about updating refs This makes write_ref_sha1() more careful: it actually checks the SHA1 of the ref it is updating, and refuses to update a ref with an object that it cannot find. Perhaps more importantly, it also refuses to update a branch head with a non-commit object. I don't quite know *how* the stable series maintainers were able to corrupt their repository to have a HEAD that pointed to a tag rather than a commit object, but they did. Which results in a totally broken repository that cannot be cloned or committed on. So make it harder for people to shoot themselves in the foot like that. The test t1400-update-ref.sh is fixed at the same time, as it assumed that the commands involved in the particular test would not care about corrupted repositories whose refs point at nonexistant bogus objects. That assumption does not hold true anymore. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 19:53:35 UTC
9f6fe82 Correct spelling in diff.c comment Correct a spelling mistake in a comment. Signed-off-by: Bill Lear <rael@zopyra.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 19:37:58 UTC
b98525e Documentation: fix and clarify grammar in git-merge docs. Signed-off-by: Dave Peticolas <dave@krondo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 19:37:57 UTC
6232f62 Make 'git fsck' complain about non-commit branches Since having non-commits in branches is a no-no, and just means you cannot commit on them, let's make fsck tell you when a branch is bad. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 19:37:57 UTC
7c3fd25 Make builtin-commit.c more careful about parenthood When creating the commit object, be a whole lot more careful about making sure that the parent lines really are valid parent lines. Check things like MERGE_HEAD having proper SHA1 lines in it, and double-check that all the parents exist and are actually commits. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 19:37:34 UTC
2862419 treat any file with NUL as binary There are two heuristics in Git to detect whether a file is binary or text. One in xdiff-interface.c (which is taken from GNU diff) relies on existence of the NUL byte at the beginning. However, convert.c used a different heuristic, which relied on the percent of non-printable symbols (less than 1% for text files). Due to differences in detection whether a file is binary or not, it was possible that a file that diff treats as binary could be treated as text by CRLF conversion. This is very confusing for a user who sees that 'git diff' shows the file as binary expects it to be added as binary. This patch makes is_binary to consider any file that contains at least one NUL character as binary, to ensure that the heuristics used for CRLF conversion is tighter than what is used by diff. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 17:10:34 UTC
a41e45e git-gui: Refresh file status description after hunk application If we apply a hunk in either direction this may change the file's status. For example if a file is completely unstaged, and has at least two hunks in it and the user stages one hunk the file will change from "Modified, not staged" to "Portions staged for commit". Resetting the file path causes our trace on this variable to fire; that trace is used to update the file header in the diff viewer to the file's current status. Noticed by Johannes Sixt. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 06:29:39 UTC
d36a8f7 git-gui: Allow 'Create New Repository' on existing directories Often users setup a few source files and get a project rolling before they create a Git repository for it. In such cases the core Git tools allow users to initialize a new repository by simply running `git init` at the desired root level directory. We need to allow the same situation in git-gui; if the user is trying to make a new repository we should let them do that to any location they chose. If the directory already exists and already has files contained within it we still should allow the user to create a repository there. However we still need to disallow creating a repository on top of an existing repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 06:14:42 UTC
daaa958 git-gui: Initial french translation Here are some of the choices made to translate Git Gui to french: - commit -> "commit" (noun) or "commiter" (verb) - stage (index) -> "pré-commit" (noun) or "pré-commiter" (verb) - (re)scan -> "(re)synchroniser" - reset -> "réinitialiser" - checkout -> "emprunt" (noun) or "emprunter" (verb) - revision expression -> "expression de révison" I am not completely happy with these, but it's a start... [sp: Inserted a missing LF in message on line 466] Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 06:01:19 UTC
d71b565 git-gui: Improve German translation. Change translation of "clone" back to "klonen" because "kopieren" is a much broader term than this particular git action. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 05:50:20 UTC
10899a8 git-gui: Updated Swedish translation after mailing list review. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 05:50:10 UTC
d454460 git-gui: Fix broken revert confirmation. I broke this extremely cool feature in 1ac17950, but it is rather easy to fix this. Sorry for that. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 05:44:14 UTC
898ff9e git-gui: Update German translation "revert" translated as "verwerfen". "hunk" translated as "Kontext". Several menu items reworded to be shorter. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 05:42:41 UTC
b3125ad git-gui: Update glossary: add term "hunk" Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 January 2008, 05:42:37 UTC
4439751 git-commit: fix double close(2) that can close a wrong file descriptor The codepath to prepare index files for the temporary and next index file was closing file descriptor it obtained from the lockfile API by hand, without letting the API know that the fd should not be doubly closed. This is not usually a problem (except it may get EBADFD) but if we opened another fd for an entirely unrelated purpose (say, an fd used to mmap a packfile) between the time we close the fd to the index file and the time we commit or rollback the lockfile (causing it to also try closing the recorded fd), the lockfile API will close an incorrect file descriptor that is still used for an entirely unrelated purpose. There's four close(fd) calls in prepare_index() and they're all incorrect. The open fd's are cleaned up in rollback_index_files() and shouldn't be closed manually. The patch below gets rid of the extra close() calls and should fix the problem. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 01:33:53 UTC
1bc7c13 hg-to-git: improve popen calls This patch improves all of the popen calls in hg-to-git.py by specifying the template 'hg log' should use instead of calling 'hg log' and grepping for the desired data. Signed-off-by: Mark Drago <markdrago@gmail.com> Acked-by: Stelian Pop <stelian@popies.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 01:24:29 UTC
3e34526 ls-remote: add -t and -h options. These options are listed in the manpage (aliases for --tags/--heads) but they were not handled. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2008, 01:04:21 UTC
4e67387 Squelch bogus progress output from git-rebase--interactive The command repeats "Rebasing (1/1)" many times even when there is only one task remaining, because mark_action_done() is called to skip comment and empty lines in the TODO file. This should fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2008, 04:04:02 UTC
471a5ce Add using merge subtree How-To Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2008, 02:04:51 UTC
11c57e6 Fix git-rerere documentation rerere.enabled is _not_ on by default. The command is enabled if rr-cache exists even when rerere.enabled is missing, and enabled or disabled by explicitly setting the rerere.enabled variable. 15 January 2008, 00:14:29 UTC
e87e22d Revert "builtin-commit.c: remove useless check added by faulty cut and paste" This reverts commit 16335fdd7ace78a8285ba25fd7a81177a48e7c9b. We are calling overlay_tree_on_cache() which does use CE_UPDATE flag to mark duplicated entries, which is the same as the codepath in git-ls-files with its --with-tree option. Because the pathname ce->name is given to path_list_insert() which does not allow duplicates, there is no breakage either way from the correctness point of view in this codepath, unlike the one in ls-files. But avoiding unnecessary processing with a single bit check is certainly better. 14 January 2008, 21:54:24 UTC
c60b528 Make default pre-commit hook less noisy This hook thought to have found a conflict marker any time it saw a 7-character combination of any of the characters '<>=' at the beginning of a line, whereas it should only look for the *same* character to appear repeatedly. Also, restrict it to match exactly 7 times, to avoid matching the underlining with '='-characters often used in documentation. Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 January 2008, 21:52:27 UTC
cfc44a1 cvsimport: remove last use of repo-config from git standard tools git cvsimport was the last tool to use repo-config instead of config. Update it to use plain git config. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 January 2008, 05:48:22 UTC
22fa97d Remove usage of git- (dash) commands from email hook Switch all git command calls to use the git (space) command format, and remove the use of git-repo-config in place of git config. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 January 2008, 05:48:20 UTC
16335fd builtin-commit.c: remove useless check added by faulty cut and paste 2888605c649ccd423232161186d72c0e6c458a48 (builtin-commit: fix partial-commit support) mindlessly cut and pasted from builtin-ls-files.c, and included a part that was meant to exclude redundant path after "ls-files --with-tree" overlayed the HEAD commit on top of the index. This logic does not apply to what git-commit does and should not have been copied, even though it would not hurt. Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 January 2008, 23:20:31 UTC
646f3a1 [PATCH] gitk: make Ctrl "+" really increase the font size Only Ctrl "=" was bound to increase the font size, probably because English keyboards have the plus on the same key as the equal sign. However, not the whole world is English, and at least with some other keyboard layouts, Ctrl "+" did not work as documented. Noticed by Stephan Hennig. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Paul Mackerras <paulus@samba.org> 13 January 2008, 21:55:04 UTC
fa9dcf8 Fix performance regression for partial commits When running "git commit paths" to create a partial commit, we used to carefully build the temporary index so that we do not lose the cached stat information. The rewrite of the command in C lost it by carelessly using read_tree(). This resurrects the earlier behaviour to keep the cached stat information as much as possible by using one-tree merge logic. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 January 2008, 08:30:56 UTC
a8db80c git-clean: fix off-by-one memory access when given no arguments The "seen" variable is used by match_pathspec, and must have as many elements as there are in the given pathspec. We create the pathspec either from the command line arguments _or_ from just the current prefix. Thus allocating "seen" based upon just argc is wrong, since if argc == 0, then we still have one pathspec, the prefix, but we don't allocate any space in "seen". Signed-off-by: Jeff King <peff@peff.net> Tested-by: İsmail Dönmez <ismail@pardus.org.tr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 January 2008, 19:10:09 UTC
98fa5b6 git-svn: handle leading/trailing whitespace from svnsync revprops Repositories generated by svnsync cannot be relied on to have properly set revprops without newlines in UUIDs and URLs. There may be broken versions of svnsync out there that append extra newlines to UUIDs, or the revprops could've been changed by repository administrators at any time, too. At least one repository we've come across has an embedded newline erroneously set in the svnsync-uuid prop. This is bad because the trailing newline is taken as another record by the Git.pm library, and the wantarray detection causes tmp_config() to return an array with an empty-but-existing second element. We will now strip leading and trailing whitespace both before setting and after reading the uuid and url for svnsync values. We will also force tmp_config to return a single scalar when reading existing values. SVN UUIDs should never have whitespace in them, and SVN repository URLs should be URI-escaped, so neither of those values we ever see in git-svn should actually have whitespace in them. Thanks to Dennis Schridde for the bug report and Junio for helping diagnose this. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 January 2008, 18:58:06 UTC
145d082 GIT 1.5.4-rc3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 January 2008, 05:40:55 UTC
a5d7e3a RPM spec: include gitk message files. Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 January 2008, 05:40:25 UTC
d3c2d9e git-relink.txt: describe more clearly how hard linking occurs Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 January 2008, 02:06:55 UTC
80cd9cf Document some default values in config.txt This documents the default values of gc.auto, gc.autopacklimit fetch.unpacklimit, receive.unpacklimit and transfer.unpacklimit. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 January 2008, 00:06:43 UTC
887ad79 Merge ../gitk * ../gitk: gitk: Update German translation. gitk: Fix typo in user message. gitk: Fix the Makefile to cope with systems lacking msgfmt 11 January 2008, 08:51:30 UTC
7d8856d gitk: Update German translation. Now 100% complete (163 strings). Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 January 2008, 08:51:13 UTC
55e3443 gitk: Fix typo in user message. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 January 2008, 08:51:13 UTC
66e15a6 gitk: Fix the Makefile to cope with systems lacking msgfmt The po2msg.sh script and the .gitignore in the po directory have been shamelessly copied from the current git-gui. This enables the top level "make NO_MSGFMT" to work consistently for git across the git-gui and gitk sub-projects. This is the same effective patch that has previously been posted as a git.git patch which more succinctly described the copying of po/.gitignore and po/po2msg.sh from git-gui. Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 January 2008, 08:51:08 UTC
8c3c7b2 pack-objects: remove redundant and wrong call to deflateEnd() We somehow called deflateEnd() on a stream that we have called deflateEnd() on already. In fact, the second deflateEnd() has always been returning Z_STREAM_ERROR. We just never checked the error return from that particular deflateEnd(). The first one returns 0 for success. We might want to tighten the check even more to check that. Noticed by Marco. Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 January 2008, 07:27:39 UTC
95693d4 bundle, fast-import: detect write failure I noticed some unchecked writes. This fixes them. * bundle.c (create_bundle): Die upon write failure. * fast-import.c (keep_pack): Die upon write or close failure. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 January 2008, 09:08:11 UTC
35cda06 Trim leading / off of paths in git-svn prop_walk prop_walk adds a leading / to all subdirectory paths. Unfortunately this causes a problem when the remote repo lives in a subdirectory itself, as the leading / causes subsequent PROPFIND calls to be executed on the wrong path. Trimming the / before calling the PROPFIND fixes this problem. Signed-off-by: Kevin Ballard <kevin@sb.org> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 22:56:49 UTC
08359b0 shortlog: mention the "-e" option in the usage Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 20:25:27 UTC
fe2128a Change git-gc documentation to reflect gc.packrefs implementation. 56752391a8c0c591853b276e4fa0b45c34ced181 (Make "git gc" pack all refs by default) changed the default of gc.packrefs to true, to pack all refs by default in any repository. IOW, the users need to disable it explicitly if they want to by setting the config variable, since 1.5.3. However, we forgot to update the documentation. This fixes it. Signed-off-by: Florian La Roche <laroche@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 20:25:24 UTC
13e4760 recv_sideband: Do not use ANSI escape sequence on dumb terminals. The "clear to end of line" sequence is used to nicely output the progress indicator without leaving garbage on the terminal. However, this works only on ANSI capable terminals. We use the same check as in color.c to find out whether the terminal supports this feature and use a workaround (a few spaces in a row) if it does not. [jc: as an old fashoned git myself, and given the fact that the possible prefix and suffix are small number of short constant strings, I actually prefer a simpler-and-more-stupid approach. This is with Nico's clean-up.] Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 20:23:59 UTC
f85fd3f Merge branch 'master' of git://git.kernel.org/pub/scm/gitk/gitk * 'master' of git://git.kernel.org/pub/scm/gitk/gitk: [PATCH] gitk: use user-configured background in view definition dialog [PATCH] gitk: Update German translation [PATCH] gitk: Update and fix Makefile gitk: Restore some widget options whose defaults changed in Tk 8.5 gitk: Recode de.po to UTF-8 [PATCH] gitk i18n: Recode gitk from latin1 to utf8 so that the (c) copyright character is valid utf8. [PATCH] gitk i18n: More markup -- various options menus [PATCH] gitk i18n: Initial German translation [PATCH] gitk i18n: Markup several strings for translation [PATCH] gitk i18n: Import msgcat for message string translation; load translation catalogs [PATCH] gitk i18n: Add Makefile with rules for po file creation and installation 09 January 2008, 06:41:15 UTC
f0c8426 [PATCH] gitk: use user-configured background in view definition dialog Have the text fields in the view definition dialog (View->New view...) use the background color as configured through the preferences, instead of hard-coded 'white'. This was suggested by Paul Wise through http://bugs.debian.org/457124 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Paul Mackerras <paulus@samba.org> 09 January 2008, 03:19:47 UTC
9e8ad09 [PATCH] gitk: Update German translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org> 09 January 2008, 03:13:22 UTC
73c4f22 [PATCH] gitk: Update and fix Makefile This Makefile uses the template provided at git.git/gitk-git/Makefile by Junio and adds the rules for the i18n files. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org> 09 January 2008, 03:12:18 UTC
ef40b3e git.el: Make status refresh faster. Don't set the needs-refresh flag when inserting a new file info, since ewoc refreshes it upon insert already; this makes a full refresh twice as fast. Also make git-fileinfo-prettyprint a little faster by not retrieving permission values twice. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 00:17:44 UTC
58152a0 git.el: Refresh files from their real state upon commit. Instead of just setting the state to up-to-date, retrieve the full state again, so that the file type can be displayed properly. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 00:17:44 UTC
87e3d81 git.el: Make sure we never insert the same file twice. Skip non-zero stage files during git-ls-files -c, they are handled later. Also fix git-insert-info-list to merge duplicate file names. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 00:17:44 UTC
d8c3794 "git-apply --check" should not report "fixed" When running "git apply --check" while --whitespace=fix is enabled (either from the command line or via the configuration), we reported that "N line(s) applied after _fixing_", but --check by itself does not apply and this message was alarming. We could even reword the message to say "N line(s) would have been applied after fixing...", but this patch does not go that far. Instead, we just make it use the "N lines add whitespace errors" warning, which happens to be a good diagnostic message a user would expect from the --check option. Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 January 2008, 00:15:01 UTC
e708af6 Merge in GIT 1.5.3.8 Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 January 2008, 08:58:33 UTC
aadd4ef GIT 1.5.3.8 Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 January 2008, 06:41:43 UTC
983a9ee Documentation: config: add 'help.*' and 'instaweb.*' variables. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 January 2008, 06:23:58 UTC
2e8fd78 Allow git-mergetool to handle paths with a leading space Signed-off-by: Rogan Dawes <rogan@dawes.za.net> 08 January 2008, 05:00:54 UTC
eee8a17 git-svn: clarify the "Ignoring error from SVN" piece I've heard of several users puzzled by this, and it sometimes it appears as if git-svn is doing nothing on slower connections and larger repositories. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 January 2008, 00:25:31 UTC
f5530b8 git-svn: support for funky branch and project names over HTTP(S) SVN requires that paths be URI-escaped for HTTP(S) repositories. file:// and svn:// repositories do not need these rules. Additionally, accessing individual paths inside repositories (check_path() and get_log() do NOT require escapes to function and in fact it breaks things). Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 23:18:37 UTC
7ec4395 slightly better auto gc message Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 22:02:25 UTC
f1cdcc7 Documentation: typofix Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 22:02:00 UTC
b2e62a7 Update draft release notes for 1.5.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 06:46:13 UTC
2370781 diff: do not chomp hunk-header in the middle of a character We truncate hunk-header line at 80 bytes, but that 80th byte could be in the middle of a character, which is bad. This uses pick_one_utf8_char() function to make sure we do not cut a character in the middle. This assumes that the internal representation of the text is UTF-8. This needs to be extended in the future but the optimal direction has not been decided yet. Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 06:44:44 UTC
44b25b8 utf8_width(): allow non NUL-terminated input The original interface assumed that the input string is always terminated with a NUL, but that wasn't too useful. Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 04:53:46 UTC
396ccf1 utf8: pick_one_utf8_char() utf8_width() function was doing two different things. To pick a valid character from UTF-8 stream, and compute the display width of that character. This splits the former to a separate function pick_one_utf8_char(). Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 04:27:35 UTC
40f162b git.el: Display file types and type changes. Handle the T status from git-diff-index to display type changes between file/symlink/subproject. Also always show the file type for symlink and subprojects to indicate that they are not normal files. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
5e3cb7e git.el: Retrieve the permissions for up-to-date files. This allows displaying correctly the executable flag for the initial commit, and will make it possible to show the file type for up-to-date symlinks and subprojects. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
8b30aa5 git.el: Support for getting diffs from inside the log-edit buffer. Take advantage of the new log-edit feature that allows to show a diff with C-c C-d while editing the log message. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
4261633 Make the git metapackage require the same version of the subpackages. Without explicit version deps in the rpm spec file, 'yum update git' effectively does nothing. Require explicit versions of the subpackages, so that they get pulled in on an update. Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
64cc1c0 tree-walk: don't parse incorrect entries The current code can access memory outside of the tree buffer in the case of malformed tree entries. This patch prevents this by: * The rest of the buffer must be at least 24 bytes (at least 1 byte mode, 1 blank, at least one byte path name, 1 NUL, 20 bytes sha1). * Check that the last NUL (21 bytes before the end) is present. This ensures that strlen() and get_mode() calls stay within the buffer. * The mode may not be empty. We have only to reject a blank at the begin, as the rest is handled by if (c < '0' || c > '7'). * The blank is ensured by get_mode(). * The path must contain at least one character. Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
47ee06f Document the color.interactive semantics There are two possible confusions with the color.interactive description: 1. the short name "interactive" implies that it covers all interactive commands; let's explicitly make it so, even though there are no other interactive commands which currently use it 2. Not all parts of "git add --interactive" are controlled by color.interactive (specifically, the diffs require tweaking color.diff). So let's clarify that it applies only to displays and prompts. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
f87e310 add--interactive: allow diff colors without interactive colors Users with color.diff set to true/auto will not see color in "git add -i" unless they also set color.interactive. This changes the semantics of color.interactive to control only the coloring of the interaction aspect of the command and let color.diff to control the color of hunk picker, which would arguably be more convenient. Old $use_color variable is now renamed to $menu_use_color to make it clear that it is about coloring the interaction. The "colored" subroutine now checks if the passed color is defined, instead of checking $use_color variable, to decide if the lines should be colored. The various variables that define colors for different parts of the output are set or unset depending on the setting of color.interactive and color.diff configuration variables. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
50e3d1e add--interactive: remove unused diff colors When color support was added, we colored the diffs ourselves. However, 4af756f3 changed this to simply run "git diff-files" twice, keeping the colored output separately. This makes the internal diff color variables obsolete with one exception: when splitting hunks, we have to manually recreate the fragment for each part of the split. Thus we keep $fraginfo_color around to do that correctly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2008, 02:41:44 UTC
back to top