summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2007-12-01Merge 1.5.3.7 inLibravatar Junio C Hamano3-1/+47
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-01GIT 1.5.3.7Libravatar Junio C Hamano3-2/+47
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-01Fix typo in t4008 test titleLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30git-svn: Don't create a "master" branch every time rebase is runLibravatar Steven Grimm1-0/+2
If you run "git-svn rebase" while sitting on a topic branch, there is no need to create a "master" branch if one didn't exist already. The branch was created implicitly by the automatic checkout after fetching, which in the case of rebase isn't actually necessary anyway. Signed-off-by: Steven Grimm <koreth@midwinter.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2007-11-30git-svn: add a show-externals command.Libravatar Vineet Kumar1-0/+18
show-externals can be used by scripts to provide svn:externals-like functionality. For example, a script can list all of the externals and then use check out the listed URLs at the appropriate paths, similar to what the svn client does. Said script (or perhaps git-svn itself, in the future) could simply invoke svn export on the paths, or it could go one further, using git-svn clone and even git-submodule together to better integrate externals checkouts. The implementation is shamelessly copied from show-ignores. A more general command to list user-specified properties is probably a better idea. Signed-off-by: Vineet Kumar <vineet@doorstop.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2007-11-30git-svn: Remove unnecessary Git::SVN::Util packageLibravatar David D. Kilzer1-14/+9
Digest::MD5 is loaded regardless of the package in which it's declared, so move its 'use' statement and the md5sum() function into the main package. Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2007-11-30git-svn: add support for pulling author from From: and Signed-off-by:Libravatar Andy Whitcroft1-7/+30
Add support for pulling the real author of a commit from the From: and first Signed-off-by: fields of the SVN commit message. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Acked-by: Eric Wong <normalperson@yhbt.net>
2007-11-30git-svn now reads settings even if called in subdirectoryLibravatar Gustaf Hendeby1-17/+18
Previously, git-svn first read the .git/config file for settings as if current working directory was the repository top-directory, and after that made sure to cd into top-directory. The result was a silent failur to read configuration settings. This patch changes the order these two things are done. Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se> Acked-by: Eric Wong <normalperson@yhbt.net>
2007-11-30Merge branch 'maint'Libravatar Junio C Hamano12-40/+155
* maint: Replace the word 'update-cache' by 'update-index' everywhere cvsimport: fix usage of cvsimport.module t7003-filter-branch: Fix test of a failing --msg-filter. cvsimport: miscellaneous packed-ref fixes cvsimport: use rev-parse to support packed refs Add basic cvsimport tests
2007-11-30Fix a pathological case in git detecting proper renamesLibravatar Linus Torvalds1-0/+13
On Thu, 29 Nov 2007, Jeff King wrote: > > I think it will get worse, because you are simultaneously calculating > all of the similarity scores bit by bit rather than doing a loop. Though > perhaps you mean at the end you will end up with a list of src/dst pairs > sorted by score, and you can loop over that. Well, after thinking about this a bit, I think there's a solution that may work well with the current thing too: instead of looping just *once* over the list of rename pairs, loop twice - and simply refuse to do copies on the first loop. This trivial patch does that, and turns Kumar's test-case into a perfect rename list. It's not pretty, it's not smart, but it seems to work. There's something to be said for keeping it simple and stupid. And it should not be nearly as expensive as it may _look_. Yes, the loop is "(i = 0; i < num_create * num_src; i++)", but the important part is that the whole array is sorted by rename score, and we have a if (mx[i].score < minimum_score) break; in it, so uthe loop actually would tend to terminate rather quickly. Anyway, Kumar, the thing to take away from this is: - git really doesn't even *care* about the whole "rename detection" internally, and any commits you have done with renames are totally independent of the heuristics we then use to *show* the renames. - the rename detection really is for just two reasons: (a) keep humans happy, and keep the diffs small and (b) help automatic merging across renames. So getting renames right is certainly good, but it's more of a "politeness" issue than a "correctness" issue, although the merge portion of it does matter a lot sometimes. - the important thing here is that you can commit your changes and not worry about them being somehow "corrupted" by lack of rename detection, even if you commit them with a version of git that doesn't do rename detection the way you expected it. The rename detection is an "after-the-fact" thing, not something that actually gets saved in the repository, which is why we can change the heuristics _after_ seeing examples, and the examples magically correct themselves! - try out the two patches I've posted, and see if they work for you. They pass the test-suite, and the output for your example commit looks sane, but hey, if you have other test-cases, try them out. Here's Kumar's pretty diffstat with both my patches: Makefile | 6 +++--- board/{cds => freescale}/common/cadmus.c | 0 board/{cds => freescale}/common/cadmus.h | 0 board/{cds => freescale}/common/eeprom.c | 0 board/{cds => freescale}/common/eeprom.h | 0 board/{cds => freescale}/common/ft_board.c | 0 board/{cds => freescale}/common/via.c | 0 board/{cds => freescale}/common/via.h | 0 board/{cds => freescale}/mpc8541cds/Makefile | 0 board/{cds => freescale}/mpc8541cds/config.mk | 0 board/{cds => freescale}/mpc8541cds/init.S | 0 board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0 board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 ++-- board/{cds => freescale}/mpc8548cds/Makefile | 0 board/{cds => freescale}/mpc8548cds/config.mk | 0 board/{cds => freescale}/mpc8548cds/init.S | 0 board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0 board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 ++-- board/{cds => freescale}/mpc8555cds/Makefile | 0 board/{cds => freescale}/mpc8555cds/config.mk | 0 board/{cds => freescale}/mpc8555cds/init.S | 0 board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0 board/{cds => freescale}/mpc8555cds/u-boot.lds | 4 ++-- 23 files changed, 9 insertions(+), 9 deletions(-) and here it is before: Makefile | 6 +- board/cds/mpc8548cds/Makefile | 60 ----- board/cds/mpc8555cds/Makefile | 60 ----- board/cds/mpc8555cds/init.S | 255 -------------------- board/cds/mpc8555cds/u-boot.lds | 150 ------------ board/{cds => freescale}/common/cadmus.c | 0 board/{cds => freescale}/common/cadmus.h | 0 board/{cds => freescale}/common/eeprom.c | 0 board/{cds => freescale}/common/eeprom.h | 0 board/{cds => freescale}/common/ft_board.c | 0 board/{cds => freescale}/common/via.c | 0 board/{cds => freescale}/common/via.h | 0 board/{cds => freescale}/mpc8541cds/Makefile | 0 board/{cds => freescale}/mpc8541cds/config.mk | 0 board/{cds => freescale}/mpc8541cds/init.S | 0 board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0 board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 +- .../mpc8541cds => freescale/mpc8548cds}/Makefile | 0 board/{cds => freescale}/mpc8548cds/config.mk | 0 board/{cds => freescale}/mpc8548cds/init.S | 0 board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0 board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 +- .../mpc8541cds => freescale/mpc8555cds}/Makefile | 0 board/{cds => freescale}/mpc8555cds/config.mk | 0 .../mpc8541cds => freescale/mpc8555cds}/init.S | 0 board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0 .../mpc8541cds => freescale/mpc8555cds}/u-boot.lds | 4 +- 27 files changed, 9 insertions(+), 534 deletions(-) so it certainly makes the diffs prettier. Linus Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30Fix a pathological case in git detecting proper renamesLibravatar Linus Torvalds1-9/+16
Kumar Gala had a case in the u-boot archive with multiple renames of files with identical contents, and git would turn those into multiple "copy" operations of one of the sources, and just deleting the other sources. This patch makes the git exact rename detection prefer to spread out the renames over the multiple sources, rather than do multiple copies of one source. NOTE! The changes are a bit larger than required, because I also renamed the variables named "one" and "two" to "target" and "source" respectively. That makes the logic easier to follow, especially as the "one" was illogically the target and not the soruce, for purely historical reasons (this piece of code used to traverse over sources and targets in the wrong order, and when we fixed that, we didn't fix the names back then. So I fixed them now). The important part of this change is just the trivial score calculations for when files have identical contents: /* Give higher scores to sources that haven't been used already */ score = !source->rename_used; score += basename_same(source, target); and when we have multiple choices we'll now pick the choice that gets the best rename score, rather than only looking at whether the basename matched. It's worth noting a few gotchas: - this scoring is currently only done for the "exact match" case. In particular, in Kumar's example, even after this patch, the inexact match case is still done as a copy+delete rather than as two renames: delete mode 100644 board/cds/mpc8555cds/u-boot.lds copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%) rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%) because apparently the "cds/mpc8541cds/u-boot.lds" copy looked a bit more similar to both end results. That said, I *suspect* we just have the exact same issue there - the similarity analysis just gave identical (or at least very _close_ to identical) similarity points, and we do not have any logic to prefer multiple renames over a copy/delete there. That is a separate patch. - When you have identical contents and identical basenames, the actual entry that is chosen is still picked fairly "at random" for the first one (but the subsequent ones will prefer entries that haven't already been used). It's not actually really random, in that it actually depends on the relative alphabetical order of the files (which in turn will have impacted the order that the entries got hashed!), so it gives consistent results that can be explained. But I wanted to point it out as an issue for when anybody actually does cross-renames. In Kumar's case the choice is the right one (and for a single normal directory rename it should always be, since the relative alphabetical sorting of the files will be identical), and we now get: rename board/{cds => freescale}/mpc8541cds/init.S (100%) rename board/{cds => freescale}/mpc8548cds/init.S (100%) which is the "expected" answer. However, it might still be better to change the pedantic "exact same basename" on/off choice into a more graduated "how similar are the pathnames" scoring situation, in order to be more likely to get the exact rename choice that people *expect* to see, rather than other alternatives that may *technically* be equally good, but are surprising to a human. It's also unclear whether we should consider "basenames are equal" or "have already used this as a source" to be more important. This gives them equal weight, but I suspect we might want to just multiple the "basenames are equal" weight by two, or something, to prefer equal basenames even if that causes a copy/delete pair. I dunno. Anyway, what I'm just saying in a really long-winded manner is that I think this is right as-is, but it's not the complete solution, and it may want some further tweaking in the future. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30Replace the word 'update-cache' by 'update-index' everywhereLibravatar Johannes Schindelin9-9/+9
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30cvsimport: fix usage of cvsimport.moduleLibravatar Jeff King2-4/+25
There were two problems: 1. We only look at the config variable if there is no module given on the command line. We checked this by comparing @ARGV == 0. However, at the time of the comparison, we have not yet parsed the dashed options, meaning that "git cvsimport" would read the variable but "git cvsimport -a" would not. This is fixed by simply moving the check after the call to getopt. 2. If the config variable did not exist, we were adding an empty string to @ARGV. The rest of the script, rather than barfing for insufficient input, would then try to import the module '', leading to rather confusing error messages. Based on patch from Emanuele Giaquinta. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30receive-pack: allow deletion of corrupt refsLibravatar Johannes Schindelin2-3/+46
Occasionally, in some setups (*cough* forks on repo.or.cz *cough*) some refs go stale, e.g. when the forkee rebased and lost some objects needed by the fork. The quick & dirty way to deal with those refs is to delete them and push them again. However, git-push first would first fetch the current commit name for the ref, would receive a null sha1 since the ref does not point to a valid object, then tell receive-pack that it should delete the ref with this commit name. delete_ref() would be subsequently be called, and check that resolve_ref() (which does _not_ check for validity of the object) returns the same commit name. Which would fail. The proper fix is to avoid corrupting repositories, but in the meantime this is a good fix in any case. Incidentally, some instances of "cd .." in the test cases were fixed, so that subsequent test cases run in t/trash/ irrespective of the outcome of the previous test cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30Merge branch 'jk/maint-cvsimport-fix' into maintLibravatar Junio C Hamano2-26/+120
* jk/maint-cvsimport-fix: cvsimport: miscellaneous packed-ref fixes cvsimport: use rev-parse to support packed refs Add basic cvsimport tests
2007-11-30t7003-filter-branch: Fix test of a failing --msg-filter.Libravatar Johannes Sixt1-1/+1
The test passed for the wrong reason: If the script given to --msg-filter fails, it is expected that git-filter-branch aborts. But the test forgot to tell the branch name to rewrite, and so git-filter-branch failed due to incorrect usage. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30Add config_int() method to the Git perl moduleLibravatar Jakub Narebski1-0/+31
Integer variables can have optional 'k', 'm' or 'g' suffix. config_int() method will return simple decimal number, taking care of those suffixes. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30Error out when user doesn't have access permission to the repositoryLibravatar André Goddard Rosa2-7/+24
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
2007-11-29per-directory-exclude: lazily read .gitignore filesLibravatar Junio C Hamano3-69/+72
Operations that walk directories or trees, which potentially need to consult the .gitignore files, used to always try to open the .gitignore file every time they entered a new directory, even when they ended up not needing to call excluded() function to see if a path in the directory is ignored. This was done by push/pop exclude_per_directory() functions that managed the data in a stack. This changes the directory walking API to remove the need to call these two functions. Instead, the directory walk data structure caches the data used by excluded() function the last time, and lazily reuses it as much as possible. Among the data the last check used, the ones from deeper directories that the path we are checking is outside are discarded, data from the common leading directories are reused, and then the directories between the common directory and the directory the path being checked is in are checked for .gitignore file. This is very similar to the way gitattributes are handled. This API change also fixes "ls-files -c -i", which called excluded() without setting up the gitignore data via the old push/pop functions. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-29dir.c: minor clean-upLibravatar Junio C Hamano1-9/+4
Replace handcrafted reallocation with ALLOC_GROW(). Reindent "file_exists()" helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28Merge branch 'maint'Libravatar Junio C Hamano7-18/+25
* maint: scripts: do not get confused with HEAD in work tree Improve description of git-branch -d and -D in man page.
2007-11-28scripts: do not get confused with HEAD in work treeLibravatar Junio C Hamano6-11/+11
When you have a file called HEAD in your work tree, many commands that our scripts feed "HEAD" to would complain about the rev vs path ambiguity. A solution is to form command line more carefully by appending -- to them, which makes it clear that we mean HEAD rev not HEAD file. This patch would apply to maint. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28bash completion: add diff optionsLibravatar Johannes Schindelin1-0/+14
I use "git diff" (the porcelain) really often, and am almost as often annoyed that the completions do not know how to complete something simple as --cached. Now they do. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28git checkout's reflog: even when detaching the HEAD, say from whereLibravatar Johannes Schindelin1-2/+3
When checking out another ref, the reflogs already record from which branch you switched. Do that also when switching to a detached HEAD. While at it, record also when coming _from_ a detached HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28sha1_file.c: Fix size_t related printf format warningsLibravatar Steffen Prohaska1-4/+6
The old way of fixing warnings did not succeed on MinGW. MinGW does not support C99 printf format strings for size_t [1]. But gcc on MinGW issues warnings if C99 printf format is not used. Hence, the old stragegy to avoid warnings fails. [1] http://www.mingw.org/MinGWiki/index.php/C99 This commits passes arguments of type size_t through a tiny helper functions that casts to the type expected by the format string. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28Revert "t5516: test update of local refs on push"Libravatar Jeff King1-28/+0
This reverts commit 09fba7a59d38d1cafaf33eadaf1d409c4113b30c. These tests are superseded by the ones in t5404 (added in 6fa92bf3 and 8736a848), which are more extensive and better organized. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28Improve description of git-branch -d and -D in man page.Libravatar Jan Hudec1-7/+14
Some users expect that deleting a remote-tracking branch would prevent fetch from creating it again, so be explcit about that it's not the case. Also be a little more explicit about what fully merged means. Signed-off-by: Jan Hudec <bulb@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28filter-branch: fix dirty way to provide the helpers to commit filtersLibravatar Johannes Schindelin1-6/+8
The helper functions 'map' and 'skip_commit' were provided to commit filters by sourcing filter-branch itself. This was done with a certain environment variable set to indicate that only the functions should be defined, and the script should return then. This was really hacky, and it did not work all that well, since the full path to git-filter-branch was not known at all times. Avoid that by putting the functions into a variable, and eval'ing that variable. The commit filter gets these functions by prepending the variable to the specified commands. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28cvsimport: miscellaneous packed-ref fixesLibravatar Jeff King1-11/+9
These were found with a grep for '$git_dir'; they all replace a direct access of "$git_dir/refs/..." with a call to git-rev-parse or git-update-ref. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28cvsimport: use rev-parse to support packed refsLibravatar Jeff King2-15/+12
Previously, if refs were packed, git-cvsimport would assume that particular refs did not exist. This could lead to, for example, overwriting previous 'origin' commits that were packed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28Add basic cvsimport testsLibravatar Jeff King1-0/+99
We weren't even testing basic things before, so let's at least try importing and updating a trivial repository, which will catch total breakage. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-27git-stash: do not get fooled with "color.diff = true"Libravatar Pascal Obry1-2/+2
When colors are set to "true" on the repository, the git log output will contain control characters to set/reset the colors, even when the output is to a pipe. This makes list_stash() fail as the downstream sed does not see what it is expecting. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-26Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.cLibravatar Steffen Prohaska4-4/+4
Using the helper function to test for absolute paths makes porting easier. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-26Fix typo in draft 1.5.4 release notesLibravatar Wincent Colaiuta1-1/+1
Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-25Merge branch 'maint'Libravatar Junio C Hamano2-25/+202
* maint: user-manual: recovering from corruption user-manual: clarify language about "modifying" old commits user-manual: failed push to public repository user-manual: define "branch" and "working tree" at start git-checkout: describe detached head correctly
2007-11-25Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maintLibravatar Junio C Hamano1-24/+201
* 'maint' of git://linux-nfs.org/~bfields/git: user-manual: recovering from corruption user-manual: clarify language about "modifying" old commits user-manual: failed push to public repository user-manual: define "branch" and "working tree" at start
2007-11-25user-manual: recovering from corruptionLibravatar J. Bruce Fields1-1/+130
Some instructions on dealing with corruption of the object database. Most of this text is from an example by Linus, identified by Nicolas Pitre <nico@cam.org> with a little further editing by me. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
2007-11-25Print the real filename that we failed to open.Libravatar André Goddard Rosa3-5/+5
When we fail to open a temporary file to be renamed to something else, we reported the final filename, not the temporary file we failed to open. Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-25user-manual: clarify language about "modifying" old commitsLibravatar J. Bruce Fields1-9/+11
It's important to remember that git doesn't really allowing "editing" or "modifying" commits, only replacing them by new commits. Redo some of the language to make this clearer. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
2007-11-25revert/cherry-pick: do not mention the original refLibravatar Junio C Hamano1-13/+1
When you cherry-pick or revert a commit, naming it with an annotated tag, we added a comment, attempting to repeat what we got from the end user, to the message. But this was inconsistent. When we got "cherry-pick branch", we recorded the object name (40-letter SHA-1) without saying anything like "original was 'branch'". There was no need to. Also recent rewrite to use parse-options made it impossible to parrot the original command line without "unparsing". This removes the code that implements the misguided "we dereferenced the tag so record that in the commit message" behaviour. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-25user-manual: failed push to public repositoryLibravatar J. Bruce Fields1-9/+49
More details on the case of a failed push to a public (non-shared) repository. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
2007-11-25user-manual: define "branch" and "working tree" at startLibravatar J. Bruce Fields1-6/+12
Some explanation here might help. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
2007-11-25git-checkout: describe detached head correctlyLibravatar Junio C Hamano1-1/+1
When you have a file called HEAD in the work tree, the code to report where the HEAD is at when "git checkout $commit^0" is done triggered unnecessary ambiguity checking. Explicitly mark the command line with "--" and make it clear that we are talking about a revision. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-24Update draft release notes for 1.5.4Libravatar Junio C Hamano1-4/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-24Merge branch 'maint'Libravatar Junio C Hamano0-0/+0
* maint: Fix rev-list when showing objects involving submodules test format-patch -s: make sure MIME content type is shown as needed format-patch -s: add MIME encoding header if signer's name requires so
2007-11-24Merge branch 'rv/maint-index-commit' into maintLibravatar Junio C Hamano2-1/+33
* rv/maint-index-commit: Make GIT_INDEX_FILE apply to git-commit
2007-11-24Merge branch 'lt/maint-rev-list-gitlink' into maintLibravatar Junio C Hamano4-3/+59
* lt/maint-rev-list-gitlink: Fix rev-list when showing objects involving submodules
2007-11-24Merge branch 'jc/maint-add-sync-stat' into maintLibravatar Junio C Hamano10-38/+92
* jc/maint-add-sync-stat: t2200: test more cases of "add -u" git-add: make the entry stat-clean after re-adding the same contents ce_match_stat, run_diff_files: use symbolic constants for readability
2007-11-24Merge branch 'jc/maint-format-patch-encoding' into maintLibravatar Junio C Hamano8-9/+65
* jc/maint-format-patch-encoding: test format-patch -s: make sure MIME content type is shown as needed format-patch -s: add MIME encoding header if signer's name requires so
2007-11-24Merge branch 'bs/maint-t7005' into maintLibravatar Junio C Hamano1-3/+2
* bs/maint-t7005: t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH