- 02 3月, 2006 5 次提交
-
-
由 Junio C Hamano 提交于
When both heads deleted, or our side deleted while the other side did not touch, we did not have to update the working tree. However, we forgot to remove existing working tree file when we did not touch and the other side did. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* lt/fix-apply: git-am: --whitespace=x option. git-apply: war on whitespace -- finishing touches. git-apply --whitespace=nowarn apply --whitespace: configuration option. apply: squelch excessive errors and --whitespace=error-all apply --whitespace fixes and enhancements. The war on trailing whitespace
-
由 Josef Weidendorfer 提交于
Moving a directory ending in a slash was not working as the destination was not calculated correctly. E.g. in the git repo, git-mv t/ Documentation gave the error Error: destination 'Documentation' already exists To get rid of this problem, strip trailing slashes from all arguments. The comment in cg-mv made me curious about this issue; Pasky, thanks! As result, the workaround in cg-mv is not needed any more. Also, another bug was shown by cg-mv. When moving files outside of a subdirectory, it typically calls git-mv with something like git-mv Documentation/git.txt Documentation/../git-mv.txt which triggers the following error from git-update-index: Ignoring path Documentation/../git-mv.txt The result is a moved file, removed from git revisioning, but not added again. To fix this, the paths have to be normalized not have ".." in the middle. This was already done in git-mv, but only for a better visual appearance :( Signed-off-by: NJosef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Josef Weidendorfer 提交于
This fixes "git-mv -h" to output the usage without the need to be in a git repository. Additionally: - fix confusing error message when only one arg was given - fix typo in error message Signed-off-by: NJosef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net> (cherry picked from 9a0e6731 commit)
-
- 01 3月, 2006 4 次提交
-
-
由 Mark Wooding 提交于
Combined diffs don't null terminate things in the same way as standard diffs. This is presumably wrong. Signed-off-by: NMark Wooding <mdw@distorted.org.uk> Signed-off-by: NJunio C Hamano <junkio@cox.net> (cherry picked from 6baf0484 commit)
-
由 Mark Wooding 提交于
For some reason, combined diffs don't honour the --full-index flag when emitting patches. Fix this. Signed-off-by: NMark Wooding <mdw@distorted.org.uk> Signed-off-by: NJunio C Hamano <junkio@cox.net> (cherry picked from e70c6b35 commit)
-
由 Junio C Hamano 提交于
We did not check if we have the same file on both sides when computing break score. This is usually not a problem, but if the user said --find-copies-harde with -B, we ended up trying a delta between the same data even when we know the SHA1 hash of both sides match. Signed-off-by: NJunio C Hamano <junkio@cox.net> (cherry picked from aeecd23a commit)
-
由 Junio C Hamano 提交于
This is passed down to git-apply to override the built-in default and per-repository configuration at runtime. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 2月, 2006 6 次提交
-
-
由 Junio C Hamano 提交于
This changes the default --whitespace policy to nowarn when we are only getting --stat, --summary etc. IOW when not applying the patch. When applying the patch, the default is warn (spit out warning message but apply the patch). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Andrew insists --whitespace=warn should be the default, and I tend to agree. This introduces --whitespace=warn, so if your project policy is more lenient, you can squelch them by having apply.whitespace=nowarn in your configuration file. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The new configuration option apply.whitespace can take one of "warn", "error", "error-all", or "strip". When git-apply is run to apply the patch to the index, they are used as the default value if there is no command line --whitespace option. Andrew can now tell people who feed him git trees to update to this version and say: git repo-config apply.whitespace error Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This by default makes --whitespace=warn, error, and strip to warn only the first 5 additions of trailing whitespaces. A new option --whitespace=error-all can be used to view all of them before applying. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
In addition to fixing obvious command line parsing bugs in the previous round, this changes the following: * Adds "--whitespace=strip". This applies after stripping the new trailing whitespaces introduced to the patch. * The output error message format is changed to say "patch-filename:linenumber:contents of the line". This makes it similar to typical compiler error message format, and helps C-x ` (next-error) in Emacs compilation buffer. * --whitespace=error and --whitespace=warn do not stop at the first error. We might want to limit the output to say first 20 such lines to prevent cluttering, but on the other hand if you are willing to hand-fix after inspecting them, getting everything with a single run might be easier to work with. After all, somebody has to do the clean-up work somewhere. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
On Sat, 25 Feb 2006, Andrew Morton wrote: > > I'd suggest a) git will simply refuse to apply such a patch unless given a > special `forcing' flag, b) even when thus forced, it will still warn and c) > with a different flag, it will strip-then-apply, without generating a > warning. This doesn't do the "strip-then-apply" thing, but it allows you to make git-apply generate a warning or error on extraneous whitespace. Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error to make it a fatal error to have whitespace at the end. Totally untested, of course. But it compiles, so it must be fine. HOWEVER! Note that this literally will check every single patch-line with "+" at the beginning. Which means that if you fix a simple typo, and the line had a space at the end before, and you didn't remove it, that's still considered a "new line with whitespace at the end", even though obviously the line wasn't really new. I assume this is what you wanted, and there isn't really any sane alternatives (you could make the warning activate only for _pure_ additions with no deletions at all in that hunk, but that sounds a bit insane). Linus
-
- 27 2月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
These two sample hooks try to detect and use the corresponding commit hook from the same repository. However, they forgot to set up GIT_DIR for their own use, so was not in effect. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 2月, 2006 3 次提交
-
-
由 Junio C Hamano 提交于
* fix: git-am: do not allow empty commits by mistake.
-
由 Junio C Hamano 提交于
* jc/fix-co-candy: checkout - eye candy. * jc/fix-rename-leak: diffcore-rename: plug memory leak. * ar/fix-win: fix t5600-clone-fail-cleanup.sh on windows
-
由 Junio C Hamano 提交于
Running "git-am --resolved" without doing anything can create an empty commit. Prevent it. Thanks for Eric W. Biederman for spotting this. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 23 2月, 2006 16 次提交
-
-
由 Alex Riesen 提交于
In windows you cannot remove current or opened directory, an opened file, a running program, a loaded library, etc... [jc: signoffs? With a minor quoting fix.] Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Spotted by Nicolas Pitre. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This implements "eye candy" similar to the pack-object/unpack-object to entertain users while a large tree is being checked out after a clone or a pull. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Unless --no-tags flag was given, git-fetch tried to always follow remote tags that point at the commits we picked up. It is not very useful to pick up tags from remote unless storing the fetched branch head in a local tracking branch. This is especially true if the fetch is done to merge the remote branch into our current branch as one-shot basis (i.e. "please pull"), and is even harmful if the remote repository has many irrelevant tags. This proposed update disables the automated tag following unless we are storing the a fetched branch head in a local tracking branch. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This updates the progress output to match "every one second or every percent whichever comes early" used by unpack-objects, as discussed on the list. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
If that pack is big, it takes significant time to write and might benefit from some more eye candies as well. This is however disabled when the pack is written to stdout since in that case the output is usually piped into unpack_objects which already does its own progress reporting. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
This provides a stable and simpler progress reporting mechanism that updates progress as often as possible but accurately not updating more than once a second. The deltification phase is also made more interesting to watch (since repacking a big repository and only seeing a dot appear once every many seconds is rather boring and doesn't provide much food for anticipation). Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
"empty ident not allowed" error makes commit-tree fail, so we are already safer in that we would not end up with commit objects that have bogus names on the author or committer fields. However, before commit-tree is called there are already changes made to the index file and the working tree. The operation can be resumed after fixing the environment problem, but when this triggers to a newcomer with unusable gecos, the first question becomes "what did I lose and how would I recover". This patch modifies some Porcelainish commands to verify GIT_COMMITTER_IDENT as soon as we know we are going to make some commits before doing much damage to prevent confusion. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Previous one warned people upfront to encourage fixing their environment early, but some people just use repositories and git tools read-only without making any changes, and in such a case there is not much point insisting on them having a usable ident. This round attempts to move the error until either "git-var" asks for the ident explicitly or "commit-tree" wants to use it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
It appears that some people who did not care about having bogus names in their own commit messages are bitten by the recent change to require a sane environment [*1*]. While it was a good idea to prevent people from using bogus names to create commits and doing sign-offs, the error message is not very informative. This patch attempts to warn things upfront and hint people how to fix their environments. [Footnote] *1* The thread is this one. http://marc.theaimsgroup.com/?t=113868084800004 Especially this message. http://marc.theaimsgroup.com/?m=113932830015032Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This tries to rework the solution for the excess delta chain problem. An earlier commit worked it around ``cheaply'', but repeated repacking risks unbound growth of delta chains. This version counts the length of delta chain we are reusing from the existing pack, and makes sure a base object that has sufficiently long delta chain does not get deltified. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
A new flag -q makes underlying pack-objects less chatty. A new flag -f forces delta to be recomputed from scratch. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This introduces --no-reuse-delta option to disable reusing of existing delta, which is a large part of the optimization introduced by this series. This may become necessary if repeated repacking makes delta chain too long. With this, the output of the command becomes identical to that of the older implementation. But the performance suffers greatly. It still allows reusing non-deltified representations; there is no point uncompressing and recompressing the whole text. It also adds a couple more statistics output, while squelching it under -q flag, which the last round forgot to do. $ time old-git-pack-objects --stdout >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects.................... real 12m8.530s user 11m1.450s sys 0m57.920s $ time git-pack-objects --stdout >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... Total 184141, written 184141 (delta 138297), reused 178833 (delta 134081) real 0m59.549s user 0m56.670s sys 0m2.400s $ time git-pack-objects --stdout --no-reuse-delta >/dev/null <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... Total 184141, written 184141 (delta 134833), reused 47904 (delta 0) real 11m13.830s user 9m45.240s sys 0m44.330s There is one remaining issue when --no-reuse-delta option is not used. It can create delta chains that are deeper than specified. A<--B<--C<--D E F G Suppose we have a delta chain A to D (A is stored in full either in a pack or as a loose object. B is depth1 delta relative to A, C is depth2 delta relative to B...) with loose objects E, F, G. And we are going to pack all of them. B, C and D are left as delta against A, B and C respectively. So A, E, F, and G are examined for deltification, and let's say we decided to keep E expanded, and store the rest as deltas like this: E<--F<--G<--A Oops. We ended up making D a bit too deep, didn't we? B, C and D form a chain on top of A! This is because we did not know what the final depth of A would be, when we checked objects and decided to keep the existing delta. Unfortunately, deferring the decision until just before the deltification is not an option. To be able to make B, C, and D candidates for deltification with the rest, we need to know the type and final unexpanded size of them, but the major part of the optimization comes from the fact that we do not read the delta data to do so -- getting the final size is quite an expensive operation. To prevent this from happening, we should keep A from being deltified. But how would we tell that, cheaply? To do this most precisely, after check_object() runs, each object that is used as the base object of some existing delta needs to be marked with the maximum depth of the objects we decided to keep deltified (in this case, D is depth 3 relative to A, so if no other delta chain that is longer than 3 based on A exists, mark A with 3). Then when attempting to deltify A, we would take that number into account to see if the final delta chain that leads to D becomes too deep. However, this is a bit cumbersome to compute, so we would cheat and reduce the maximum depth for A arbitrarily to depth/4 in this implementation. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When generating a new pack, notice if we have already needed objects in existing packs. If an object is stored deltified, and its base object is also what we are going to pack, then reuse the existing deltified representation unconditionally, bypassing all the expensive find_deltas() and try_deltas() calls. Also, notice if what we are going to write out exactly match what is already in an existing pack (either deltified or just compressed). In such a case, we can just copy it instead of going through the usual uncompressing & recompressing cycle. Without this patch, in linux-2.6 repository with about 1500 loose objects and a single mega pack: $ git-rev-list --objects v2.6.16-rc3 >RL $ wc -l RL 184141 RL $ time git-pack-objects p <RL Generating pack... Done counting 184141 objects. Packing 184141 objects.................... a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2 real 12m4.323s user 11m2.560s sys 0m55.950s With this patch, the same input: $ time ../git.junio/git-pack-objects q <RL Generating pack... Done counting 184141 objects. Packing 184141 objects..................... a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2 Total 184141, written 184141, reused 182441 real 1m2.608s user 0m55.090s sys 0m1.830s Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The real problem triggered an earlier fix was that an alternate entry was pointing at a removed directory. Complaining on object/pack directory that cannot be opendir-ed produces noise in an ancient repository that does not have object/pack directory and has never been packed. Detect the real user error and report it. Also if opendir failed for other reasons (e.g. no read permissions), report that as well. Spotted by Andrew Vasquez <andrew.vasquez@qlogic.com>. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 22 2月, 2006 3 次提交
-
-
由 Carl Worth 提交于
It turns out that the git-push documentation didn't describe what it would do when not given a refspec, (not on the command line, nor in a remotes file). This is fairly important for the user who is trying to understand operations such as: git clone git://something/some/where # hack, hack, hack git push origin I tracked the mystery behavior down to git-send-pack and lifted the relevant portion of its documentation up to git-push, (namely that all refs existing both locally and remotely are updated). Signed-off-by: NCarl Worth <cworth@cworth.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Perl is not C and does not truncate the division result. Arghh! Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Carl Worth 提交于
This adds support to git-add to allow the common -- to separate command-line options and file names. It adds documentation and a new git-add test case as well. [jc: this should apply to 1.2.X maintenance series, so I reworked git-ls-files --error-unmatch test. ] Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 2月, 2006 2 次提交
-
-
由 Martin Mares 提交于
Fixed a couple of bugs in recovering from broken connections: The _line() method now returns undef correctly when the connection is broken instead of falling off the function and returning garbage. Retries are now reported to stderr and the eventual partially downloaded file is discarded instead of being appended to. The "Server gone away" test has been removed, because it was reachable only if the garbage return bug bit. Signed-off-by: NMartin Mares <mj@ucw.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
This fixes a bug when importing where a directory gets removed/renamed but is immediately replaced by a file of the same name in the same changeset. This fix only applies to the accurate (default) strategy the moment. This patch should also fix the fast strategy if/when it is updated to handle the cases that would've triggered this bug. This bug was originally found in git-svn, but I remembered I did the same thing with archimport as well. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-