- 03 12月, 2007 16 次提交
-
-
由 Junio C Hamano 提交于
* js/prune-expire: Add "--expire <time>" option to 'git prune'
-
由 Junio C Hamano 提交于
* js/export-with-assignment: Replace instances of export VAR=VAL with VAR=VAL; export VAR
-
由 Junio C Hamano 提交于
* js/fast-export: Add 'git fast-export', the sister of 'git fast-import'
-
由 Junio C Hamano 提交于
* js/rebase-i-rerere: rebase -i: give rerere a chance
-
由 Junio C Hamano 提交于
* js/pull-rebase: Teach 'git pull' about --rebase
-
由 Junio C Hamano 提交于
* wc/rebase-insn: Mention that git-rm can be an appropriate resolution as well as git-add. revert/cherry-pick: Allow overriding the help text by the calling Porcelain
-
由 Junio C Hamano 提交于
* jc/typebreak: Enable rewrite as well as rename detection in git-status rename: Break filepairs with different types.
-
由 Jeff King 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* jc/color: git-config --get-color: get configured color "color.diff = true" is not "always" anymore.
-
由 Johannes Schindelin 提交于
This program dumps (parts of) a git repository in the format that fast-import understands. For clarity's sake, it does not use the 'inline' method of specifying blobs in the commits, but builds the blobs before building the commits. Since signed tags' signatures will not necessarily be valid (think transformations after the export, or excluding revisions, changing the history), there are 4 modes to handle them: abort (default), ignore, warn and strip. The latter just turns the tags into unsigned ones. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* dc/gitweb: gitweb: the commitdiff is very commonly used, it's needed on search page, too
-
由 Jakub Narebski 提交于
Update list of build configuration variables, add references to gitweb/INSTALL, add description of runtime and per-repository runtime configuration. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Leung 提交于
The current git-stash behaviour is very error prone to typos. For example, if you typed "git-stash llist", git-stash would think that you wanted to save to a stash named "llist", but in fact, you meant "git-stash list". Signed-off-by: NKevin Leung <kevinlsk@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Even though commit-tree would default to the current time if the incoming e-mail message somehow did not record the timestamp, it is safer to catch the breakage sooner. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* maint: t9600: test cvsimport from CVS working tree
-
由 Jeff King 提交于
This test passes with v1.5.3.7, but not with v1.5.3.6. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 12月, 2007 13 次提交
-
-
由 Denis Cheng 提交于
Acked-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
When we consider if a path has been totally rewritten, we did not touch changes from symlinks to files or vice versa. But a change that modifies even the type of a blob surely should count as a complete rewrite. While we are at it, modernise diffcore-break to be aware of gitlinks (we do not want to touch them). Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The categorized list of commands in git(7) and the list of common commands in "git help" output were maintained separately, which was insane. This consolidates them to a single command-list.txt file. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
8951d7c1 (Build in ls-remote) made peek-remote as a synonym to ls-remote by enhancing the latter, but at the same time actually _removed_ it, before we officially gave removal notice. This was bad. Resurrect it for v1.5.4. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* tt/help: Remove hint to use "git help -a" Make the list of common commands more exclusive
-
由 Junio C Hamano 提交于
* jc/move-gitk: Move gitk to its own subdirectory
-
由 Junio C Hamano 提交于
* jc/branch-contains: git-branch --contains: doc and test git-branch --contains=commit parse-options: Allow to hide options from the default usage.
-
由 Junio C Hamano 提交于
* cr/tag-options: git-tag: test that -s implies an annotated tag "git-tag -s" should create a signed annotated tag builtin-tag: accept and process multiple -m just like git-commit Make builtin-tag.c use parse_options.
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 12月, 2007 11 次提交
-
-
由 Steven Grimm 提交于
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: NSteven Grimm <koreth@midwinter.com> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Vineet Kumar 提交于
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: NVineet Kumar <vineet@doorstop.net> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 David D. Kilzer 提交于
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: NDavid D. Kilzer <ddkilzer@kilzer.net> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Andy Whitcroft 提交于
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: NAndy Whitcroft <apw@shadowen.org> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Gustaf Hendeby 提交于
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: NGustaf Hendeby <hendeby@isy.liu.se> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Junio C Hamano 提交于
* 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
-
由 Linus Torvalds 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
Earlier, 'git prune' would prune all loose unreachable objects. This could be quite dangerous, as the objects could be used in an ongoing operation. This patch adds a mode to expire only loose, unreachable objects which are older than a certain time. For example, by git prune --expire 14.days you can prune only those objects which are loose, unreachable and older than 14 days (and thus probably outdated). The implementation uses st.st_mtime rather than st.st_ctime, because it can be tested better, using 'touch -d <time>' (and omitting the test when the platform does not support that command line switch). Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-