* Re: [PATCHv2 8/8] send-email: do not prompt for explicit repo ident
From: Junio C Hamano @ 2012-11-16 5:17 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Thomas Rast, Jonathan Nieder
In-Reply-To: <20121115172845.GA20298@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> That is a good question. That confirmation step does come after they
> have typed their cover letter. However, if they are using --compose,
> they are dumped in their editor with something like:
>
> From Jeff King <peff@peff.net> # This line is ignored.
> GIT: Lines beginning in "GIT:" will be removed.
> GIT: Consider including an overall diffstat or table of contents
> GIT: for the patch you are writing.
> GIT:
> GIT: Clear the body content if you don't wish to send a summary.
> From: Jeff King <peff@peff.net>
> Subject:
> In-Reply-To:
>
> which I think would count as sufficient notice of the address being
> used.
OK. Tentatively I replaced your old series with these 8 patches
including the last one, as I tend to agree with the value the
earlier clean-up in the series gives us in the longer term. As you
and Felipe discussed, we may want to replace the last one with a
simpler "don't bother asking" patch, but I think that is more or
less an orthogonal issue.
Thanks.
^ permalink raw reply
* Crash when pushing large binary file
From: Thomas Gay @ 2012-11-16 5:44 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
Using Git 1.8 on Mac OS X 10.7.5. I just added a large binary file to
my repo, and each time I try to push it, Git crashes. I've attached
the crash log to this email and pasted the console output below.
Counting objects: 27, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
error: unpack-objects died of signal 11 | 76.91 MiB/s
error: pack-objects died of signal 13
error: failed to push some refs to 'ssh://...'
-Tom
[-- Attachment #2: git_2012-11-16-143138_localhost.crash --]
[-- Type: application/octet-stream, Size: 7552 bytes --]
Process: git [5584]
Path: /usr/libexec/git-core/git
Identifier: git
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: git [5583]
Date/Time: 2012-11-16 14:31:38.357 +0900
OS Version: Mac OS X Server 10.7.5 (11G63)
Report Version: 9
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000009fc1cff0
VM Regions Near 0x9fc1cff0:
-->
__TEXT 000000010ceda000-000000010cfef000 [ 1108K] r-x/rwx SM=COW /usr/bin/git [/usr/libexec/git-core/git]
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libcommonCrypto.dylib 0x00007fff867db741 CC_SHA1_Update + 893
1 git 0x000000010cf8fa74 write_sha1_file_prepare + 117
2 git 0x000000010cf8facd write_sha1_file + 59
3 git 0x000000010cf34515 write_object + 77
4 git 0x000000010cf33b57 cmd_unpack_objects + 784
5 git 0x000000010cedb59e handle_internal_command + 330
6 git 0x000000010cedb1df main + 632
7 git 0x000000010cedaeac start + 52
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000004 rcx: 0x0000000000000010 rdx: 0x00007fff6cad9954
rdi: 0x00000000de342aef rsi: 0x000000009fc1cff3 rbp: 0x00007fff6cad9910 rsp: 0x00007fff6cad98f0
r8: 0x00007fff86800380 r9: 0x00007fff6cad9928 r10: 0x000000019fc1cff0 r11: 0x0000000000000000
r12: 0x0000000092a1d000 r13: 0x00007fff6cad99d0 r14: 0x00007fff6cad9944 r15: 0x000000009fc1cff0
rip: 0x00007fff867db741 rfl: 0x0000000000010216 cr2: 0x000000009fc1cff0
Logical CPU: 2
Binary Images:
0x10ceda000 - 0x10cfeeff7 git (??? - ???) <EF0B0F1A-D923-3A67-ACB8-4FE1CD9AB171> /usr/libexec/git-core/git
0x7fff6cada000 - 0x7fff6cb0ebaf dyld (195.6 - ???) <C58DAD8A-4B00-3676-8637-93D6FDE73147> /usr/lib/dyld
0x7fff867b2000 - 0x7fff867d2fff libsystem_kernel.dylib (1699.32.7 - compatibility 1.0.0) <66C9F9BD-C7B3-30D4-B1A0-03C8A6392351> /usr/lib/system/libsystem_kernel.dylib
0x7fff867d3000 - 0x7fff867d3fff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib
0x7fff867d4000 - 0x7fff86816ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <BB770C22-8C57-365A-8716-4A3C36AE7BFB> /usr/lib/system/libcommonCrypto.dylib
0x7fff868f4000 - 0x7fff86902fff libdispatch.dylib (187.10.0 - compatibility 1.0.0) <8E03C652-922A-3399-93DE-9EA0CBFA0039> /usr/lib/system/libdispatch.dylib
0x7fff8696e000 - 0x7fff86977ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib
0x7fff8698b000 - 0x7fff8698ffff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib
0x7fff87317000 - 0x7fff8731cff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib
0x7fff88346000 - 0x7fff88363fff libxpc.dylib (77.19.0 - compatibility 1.0.0) <9F57891B-D7EF-3050-BEDD-21E7C6668248> /usr/lib/system/libxpc.dylib
0x7fff88ab0000 - 0x7fff88ab6ff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib
0x7fff8937f000 - 0x7fff89389ff7 liblaunch.dylib (392.39.0 - compatibility 1.0.0) <8C235D13-2928-30E5-9E12-2CC3D6324AE2> /usr/lib/system/liblaunch.dylib
0x7fff89495000 - 0x7fff894d0fff libsystem_info.dylib (??? - ???) <35F90252-2AE1-32C5-8D34-782C614D9639> /usr/lib/system/libsystem_info.dylib
0x7fff895c0000 - 0x7fff895c1fff libunc.dylib (24.0.0 - compatibility 1.0.0) <337960EE-0A85-3DD0-A760-7134CF4C0AFF> /usr/lib/system/libunc.dylib
0x7fff898fe000 - 0x7fff89903fff libcache.dylib (47.0.0 - compatibility 1.0.0) <1571C3AB-BCB2-38CD-B3B2-C5FC3F927C6A> /usr/lib/system/libcache.dylib
0x7fff89cb3000 - 0x7fff89d90fef libsystem_c.dylib (763.13.0 - compatibility 1.0.0) <41B43515-2806-3FBC-ACF1-A16F35B7E290> /usr/lib/system/libsystem_c.dylib
0x7fff8a069000 - 0x7fff8a06dfff libdyld.dylib (195.6.0 - compatibility 1.0.0) <FFC59565-64BD-3B37-90A4-E2C3A422CFC1> /usr/lib/system/libdyld.dylib
0x7fff8a14e000 - 0x7fff8a155fff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <0AB51EE2-E914-358C-AC19-47BC024BDAE7> /usr/lib/system/libcopyfile.dylib
0x7fff8a20c000 - 0x7fff8a214fff libsystem_dnssd.dylib (??? - ???) <584B321E-5159-37CD-B2E7-82E069C70AFB> /usr/lib/system/libsystem_dnssd.dylib
0x7fff8aa64000 - 0x7fff8aa65ff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib
0x7fff8aee8000 - 0x7fff8af15fe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <DA79E5BA-BBA3-3768-AAD8-B34BA877EF03> /usr/lib/libSystem.B.dylib
0x7fff8af3d000 - 0x7fff8af3eff7 libsystem_sandbox.dylib (??? - ???) <2A09E4DA-F47C-35CB-B70C-E0492BA9F20E> /usr/lib/system/libsystem_sandbox.dylib
0x7fff8d018000 - 0x7fff8d019fff libdnsinfo.dylib (395.11.0 - compatibility 1.0.0) <853BAAA5-270F-3FDC-B025-D448DB72E1C3> /usr/lib/system/libdnsinfo.dylib
0x7fff8f753000 - 0x7fff8f848fff libiconv.2.dylib (7.0.0 - compatibility 7.0.0) <5C40E880-0706-378F-B864-3C2BD922D926> /usr/lib/libiconv.2.dylib
0x7fff8f887000 - 0x7fff8f888ff7 libremovefile.dylib (21.1.0 - compatibility 1.0.0) <739E6C83-AA52-3C6C-A680-B37FE2888A04> /usr/lib/system/libremovefile.dylib
0x7fff8fca8000 - 0x7fff8fcbaff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib
0x7fff8fdf4000 - 0x7fff8fdf9fff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib
0x7fff90962000 - 0x7fff90968fff libmacho.dylib (800.0.0 - compatibility 1.0.0) <165514D7-1BFA-38EF-A151-676DCD21FB64> /usr/lib/system/libmacho.dylib
0x7fff90df5000 - 0x7fff90df7fff libquarantine.dylib (36.7.0 - compatibility 1.0.0) <8D9832F9-E4A9-38C3-B880-E5210B2353C7> /usr/lib/system/libquarantine.dylib
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 78436
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=53.8M resident=14.8M(27%) swapped_out_or_unallocated=39.0M(73%)
Writable regions: Total=2.3G written=2.3G(99%) resident=2.3G(99%) swapped_out=0K(0%) unallocated=18.4M(1%)
REGION TYPE VIRTUAL
=========== =======
MALLOC 2.3G
MALLOC guard page 32K
STACK GUARD 56.0M
Stack 8192K
__DATA 672K
__LINKEDIT 49.2M
__TEXT 4648K
mapped file 4K
shared memory 12K
=========== =======
TOTAL 2.4G
^ permalink raw reply
* Re: Crash when pushing large binary file
From: Nguyen Thai Ngoc Duy @ 2012-11-16 6:25 UTC (permalink / raw)
To: Thomas Gay; +Cc: git
In-Reply-To: <CA+AoP-n07k0r11O6ShOT8jHiX+TL+=p8sZoei+Gi+9gG_YyJqA@mail.gmail.com>
On Fri, Nov 16, 2012 at 12:44 PM, Thomas Gay <tgay@tokyois.com> wrote:
> Using Git 1.8 on Mac OS X 10.7.5. I just added a large binary file to
How large exactly?
> my repo, and each time I try to push it, Git crashes. I've attached
> the crash log to this email and pasted the console output below.
>
> Counting objects: 27, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (16/16), done.
> error: unpack-objects died of signal 11 | 76.91 MiB/s
> error: pack-objects died of signal 13
> error: failed to push some refs to 'ssh://...'
If you set receive.unpacklimit to 1 on the receiving end, does it still crash?
--
Duy
^ permalink raw reply
* Re: Crash when pushing large binary file
From: Thomas Gay @ 2012-11-16 6:54 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8AAd0odtLDiZ+A+MhX1En_G97gF2uoHjVeJvekznY3JSw@mail.gmail.com>
Thanks for the quick reply!
On Fri, Nov 16, 2012 at 3:25 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 12:44 PM, Thomas Gay <tgay@tokyois.com> wrote:
>> Using Git 1.8 on Mac OS X 10.7.5. I just added a large binary file to
>
> How large exactly?
2.46 GB
> If you set receive.unpacklimit to 1 on the receiving end, does it still crash?
Yes. The crash log looks the same too.
-Tom
^ permalink raw reply
* Re: `git mv` has ambiguous error message for non-existing target
From: Patrick Lehner @ 2012-11-16 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vehju8h5j.fsf@alter.siamese.dyndns.org>
But just because mv's error essage isnt very good, does that mean git
mv's error message mustn't be better? That would strike me as an odd
bit of reasoning.
On Fr 16 Nov 2012 02:34:32 CET, Junio C Hamano wrote:
> Patrick Lehner <lehner.patrick@gmx.de> writes:
>
>> To reproduce:
>> - cd into a git repo
>> - assuming "filea.txt" is an existing file in the CWD, and "dirb" is
>> neither a file nor a directory in the CWD, use the command "git mv
>> filea.txt dirb/filea.txt"
>> - this will produce an error message like `fatal: renaming 'filea.sh'
>> failed: No such file or directory`
>>
>> It does not mention that the problem is, in fact, the target directory
>> not existing. This seems to be mostly a problem for users unfamiliar
>> with bash/*nix console commands. Although it is documented that git mv
>> will not create intermediate folders (which is fine, because neither
>> does mv), the error message might lead to believe a problem exists
>> with the source file.
>
> $ rm -fr xxx
> $ >yyy
> $ mv yyy xxx/yyy
> mv: cannot move `yyy' to `xxx/yyy': No such file or directory
>
> It doesn't mention that the problem is with 'xxx' and not 'yyy'
> either.
>
>
^ permalink raw reply
* Re: [PATCH] status: add advice on how to push/pull to tracking branch
From: Matthieu Moy @ 2012-11-16 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmwyi8rjt.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> I don't understand what you mean by "non-current". If you mean a local
>> branch not pointed to by HEAD, then I don't understand the remark, as
>> the message is shown by "git status" (looking more closely, it is also
>> shown by "git checkout", but after switching branch so also showing a
>> message about the current branch) and precisely talks about the current
>> branch.
>
> Ah, Ok, I somehow thought that "branch -v" would also use this
> information, and/or during my absense this function from remote.c
> got linked into "git remote show" ;-)
OK.
> So it is not an issue right now, but we will have to worry about the
> messaging when we start using this to describe a branch that is not
> currently checked out.
(Anyway, we'd have to reword it a bit: saying "Your branch ..." would be
wrong in this case)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Crash when pushing large binary file
From: Nguyen Thai Ngoc Duy @ 2012-11-16 10:11 UTC (permalink / raw)
To: Thomas Gay; +Cc: git
In-Reply-To: <CA+AoP-keNcjGLtxbb9t7sggur1e+XmbMN5apVJfEdfhqU2-JGQ@mail.gmail.com>
On Fri, Nov 16, 2012 at 1:54 PM, Thomas Gay <tgay@tokyois.com> wrote:
>> If you set receive.unpacklimit to 1 on the receiving end, does it still crash?
>
> Yes. The crash log looks the same too.
If it still says "unpack-objects died of signal 11" then it was not
done the right way. The receiving end can use either unpack-objects or
index-pack for storing the objects. I know unpack-objects is not ready
for large blobs (though I cannot explain your crash log, that's why I
still need you to test it this way). I was hoping to force it use
index-pack and see it still crashes. If it does, we have other
problems than unpack-objects not being ready for large blobs. If it
does not, I'd say it's a known issue with a known solution (I was
planning on merging unpack-objects functionality back to index-pack).
We can try again this way. index-pack will be used if the number of
transfer objects exceeds 100 (by default). You are pusing 16 objects,
which is why unpack-objects is used. We can try to push garbage to the
other end to meet the 100 limit, then reset the branch at the other
end later. You can run "git gc" early on the other end to clean up
garbage, or it'll be done automatically at some point in future. Make
sure there is no changes in index and worktree, or adjust you may want
to change the last four commands slightly.
mkdir tmp
for i in `seq 200`;do echo $i > tmp/$i; git add $i; done
git commit -m 'useless stuff'
git push <where?> # should not crash again
git reset --hard HEAD^
git push <same-where?-above>
--
Duy
^ permalink raw reply
* Re: [PATCH v4 0/4] Introduce diff.submodule
From: Ramkumar Ramachandra @ 2012-11-16 10:45 UTC (permalink / raw)
To: Jeff King; +Cc: Git List
In-Reply-To: <20121115163356.GF6157@sigill.intra.peff.net>
Jeff King wrote:
> It may be worth squashing this test into patch 3:
Looks good. Thanks.
> BTW, while writing the test, I noticed two minor nits with your tests:
>
> 1. They can use test_config, which is simpler (you do not need to
> unset yourself after the test) and safer (the unset happens via
> test_when_finished, so it works even if the test fails).
I see. Can you squash this in?
-- 8< --
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index e401814..876800f 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -56,7 +56,7 @@ EOF
"
test_expect_success '--submodule=short overrides diff.submodule' "
- git config diff.submodule log &&
+ test_config diff.submodule log &&
git add sm1 &&
git diff --submodule=short --cached >actual &&
cat >expected <<-EOF &&
@@ -68,7 +68,6 @@ index 0000000..a2c4dab
@@ -0,0 +1 @@
+Subproject commit $fullhead1
EOF
- git config --unset diff.submodule &&
test_cmp expected actual
"
> 2. You can still indent expected output when using <<-.
I know; however, I wanted to be consistent with the surrounding code.
Ram
^ permalink raw reply related
* Re: Local clones aka forks disk size optimization
From: Michael J Gruber @ 2012-11-16 11:25 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Andrew Ardill, Javier Domingo, git@vger.kernel.org
In-Reply-To: <CAMK1S_ioQQWXaOO8Na=7M4QhaaUNQ8ySVM-E_2bk6m4TyvRpeA@mail.gmail.com>
Sitaram Chamarty venit, vidit, dixit 15.11.2012 04:44:
> On Thu, Nov 15, 2012 at 7:04 AM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
>> On 15 November 2012 12:15, Javier Domingo <javierdo1@gmail.com> wrote:
>>> Hi Andrew,
>>>
>>> Doing this would require I got tracked which one comes from which. So
>>> it would imply some logic (and db) over it. With the hardlinking way,
>>> it wouldn't require anything. The idea is that you don't have to do
>>> anything else in the server.
>>>
>>> I understand that it would be imposible to do it for windows users
>>> (but using cygwin), but for *nix ones yes...
>>> Javier Domingo
>>
>> Paraphrasing from git-clone(1):
>>
>> When cloning a repository, if the source repository is specified with
>> /path/to/repo syntax, the default is to clone the repository by making
>> a copy of HEAD and everything under objects and refs directories. The
>> files under .git/objects/ directory are hardlinked to save space when
>> possible. To force copying instead of hardlinking (which may be
>> desirable if you are trying to make a back-up of your repository)
>> --no-hardlinks can be used.
>>
>> So hardlinks should be used where possible, and if they are not try
>> upgrading Git.
>>
>> I think that covers all the use cases you have?
>
> I am not sure it does. My understanding is this:
>
> 'git clone -l' saves space on the initial clone, but subsequent pushes
> end up with the same objects duplicated across all the "forks"
> (assuming most of the forks keep up with some canonical repo).
>
> The alternates mechanism can give you ongoing savings (as long as you
> push to the "main" repo first), but it is dangerous, in the words of
> the git-clone manpage. You have to be confident no one will delete a
> ref from the "main" repo and then do a gc or let it auto-gc.
>
> He's looking for something that addresses both these issues.
>
> As an additional idea, I suspect this is what the namespaces feature
> was created for, but I am not sure, and have never played with it till
> now.
>
> Maybe someone who knows namespaces very well will chip in...
>
I dunno about namespaces, but a safe route with alternates seems to be:
Provide one "main" clone which is bare, pulls automatically, and is
there to stay (no pruning), so that all others can use that as a
reliable alternates source.
Michael
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Andreas Schwab @ 2012-11-16 13:13 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121115212818.GA21558@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> if commitcount > 1:
> do_or_die("rm `git ls-tree --name-only HEAD`")
This will fail on file names containing whitespace or glob meta
characters. Better use "git rm -qr ." here. You don't have to care
about the index since you are doing "git add -A" later anyway.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH 3/4] RelNotes 1.8.1: Grammar thinko
From: Horst H. von Brand @ 2012-11-16 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Horst H. von Brand
In-Reply-To: <1353071153-1453-1-git-send-email-vonbrand@inf.utfsm.cl>
From: "Horst H. von Brand" <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 69baa35..668f1a3 100644
--- a/Documentation/RelNotes/1.8.1.txt
+++ b/Documentation/RelNotes/1.8.1.txt
@@ -132,7 +132,7 @@ details).
(merge 11fbe18 po/maint-refs-replace-docs later to maint).
* Various rfc2047 quoting issues around a non-ASCII name on the
- From: line in the output from format-patch has been corrected.
+ From: line in the output from format-patch have been corrected.
(merge 25dc8da js/format-2047 later to maint).
* Sometimes curl_multi_timeout() function suggested a wrong timeout
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 1/4] RelNotes 1.8.1: Typo
From: Horst H. von Brand @ 2012-11-16 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Horst H. von Brand
From: "Horst H. von Brand" <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 107e5f3..559cd05 100644
--- a/Documentation/RelNotes/1.8.1.txt
+++ b/Documentation/RelNotes/1.8.1.txt
@@ -36,7 +36,7 @@ UI, Workflows & Features
give the default number of context lines in the patch output, to
override the hardcoded default of 3 lines.
- * "git format-patch" leraned the "--notes=<ref>" option to give
+ * "git format-patch" learned the "--notes=<ref>" option to give
notes for the commit after the three-dash lines in its output.
* "git log --grep=<pcre>" learned to honor the "grep.patterntype"
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 4/4] RelNotes 1.8.1: Another grammar thinko
From: Horst H. von Brand @ 2012-11-16 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Horst H. von Brand
In-Reply-To: <1353071153-1453-1-git-send-email-vonbrand@inf.utfsm.cl>
From: "Horst H. von Brand" <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 668f1a3..88179b4 100644
--- a/Documentation/RelNotes/1.8.1.txt
+++ b/Documentation/RelNotes/1.8.1.txt
@@ -136,7 +136,7 @@ details).
(merge 25dc8da js/format-2047 later to maint).
* Sometimes curl_multi_timeout() function suggested a wrong timeout
- value when there is no file descriptors to wait on and the http
+ value when there are no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
A workaround has been added for this.
(merge 7202b81 sz/maint-curl-multi-timeout later to maint).
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 2/4] RelNotes 1.8.1: Awkward wording
From: Horst H. von Brand @ 2012-11-16 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Horst H. von Brand
In-Reply-To: <1353071153-1453-1-git-send-email-vonbrand@inf.utfsm.cl>
From: "Horst H. von Brand" <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/RelNotes/1.8.1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt
index 559cd05..69baa35 100644
--- a/Documentation/RelNotes/1.8.1.txt
+++ b/Documentation/RelNotes/1.8.1.txt
@@ -100,7 +100,7 @@ details).
* "git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle
- it. Work it around by passing a temporary empty file.
+ it. Work around this by passing a temporary empty file.
(merge 3facc60 da/mergetools-p4 later to maint).
* "git log -F -E --grep='<ere>'" failed to use the given <ere>
--
1.8.0.197.g5a90748
^ permalink raw reply related
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Marc Khouzam @ 2012-11-16 14:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: szeder, git
In-Reply-To: <CAMP44s0Guq0nYJEfbvNDyt8Oqaux-cXbTsyro6pxUnEpA4+XOw@mail.gmail.com>
On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>> The current tcsh-completion support for Git, as can be found on the
>> Internet, takes the approach of defining the possible completions
>> explicitly. This has the obvious draw-back to require constant
>> updating as the Git code base evolves.
>>
>> The approach taken by this commit is to to re-use the advanced bash
>> completion script and use its result for tcsh completion. This is
>> achieved by executing (versus sourcing) the bash script and
>> outputting the completion result for tcsh consumption.
>>
>> Three solutions were looked at to implement this approach with (A)
>> being retained:
>>
>> A) Modifications:
>> git-completion.bash and new git-completion.tcsh
>
> As I said, I don't think this is needed. It can be done in a single
> stand-alone script without modifications to git-completion.bash.
>
> This works:
Thank you for taking the time to try things out.
What you suggest below is an improvement on solution (C).
I had chosen (A) instead because (C) creates a third script
which gets generated each time a new shell is started.
It should be safe, but it felt a little wrong.
But I have to admit I was on the fence between the two
solutions.
If you guys don't think it is bad to generate a third script
(that the user may notice in his ${HOME}),
I'll post a new patch (and try once more to get gmail not to
replace the tabs with spaces), using your improved
solution (C).
> set called = ($_)
I fought with this a lot before posting to the list.
It seems that $_ is not set when a double sourcing
happens. Testing the solution as an actual user
showed me that when I start a new shell it
sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
and then $_ is empty for some reason.
I couldn't find another way to figure out where the script
is located, which is why I had to force the user to use
${HOME} for everything.
> set script = "${called[2]}.tmp"
>
> cat <<\EOF > $script
> source "$HOME/.git-completion.sh"
This is nice. Shame on me not to have thought about it.
In my version I actually 'cat' the entire bash script into $script
instead of simply sourcing it.
> # Set COMP_WORDS in a way that can be handled by the bash script.
> COMP_WORDS=($1)
>
> # Set COMP_CWORD to the cursor location as bash would.
> if [ -n "${2-}" ]; then
> COMP_CWORD=$2
> else
Since this code will be part of a tcsh-only script, I don't think
we need to prepare for a possible $2. tcsh won't provide it.
So, I'll remove that logic, which will simplify things slightly.
> # Assume the cursor is at the end of parameter #1.
> # We must check for a space as the last character which will
> # tell us that the previous word is complete and the cursor
> # is on the next word.
> if [ "${1: -1}" == " " ]; then
> # The last character is a space, so our location is at the end
> # of the command-line array
> COMP_CWORD=${#COMP_WORDS[@]}
> else
> # The last character is not a space, so our location is on the
> # last word of the command-line array, so we must decrement the
> # count by 1
> COMP_CWORD=$((${#COMP_WORDS[@]}-1))
> fi
> fi
>
> # Call _git() or _gitk() of the bash script, based on the first
> # element of the command-line
> _${COMP_WORDS[0]}
>
> IFS=$'\n'
> echo "${COMPREPLY[*]}"
> \EOF
>
> complete git 'p/*/`bash ${script} "${COMMAND_LINE}" | sort | uniq`/'
> complete gitk 'p/*/`bash ${script} "${COMMAND_LINE}" | sort | uniq`/'
I am worried about 'sort' and 'uniq' being aliased by the user, so I was
thinking of using '\sort | \uniq'
I'll work on the new version of the solution.
Thanks again
Marc
^ permalink raw reply
* RE: Local clones aka forks disk size optimization
From: Pyeron, Jason J CTR (US) @ 2012-11-16 14:55 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CALZVapmBM78UtjAiNm2VoeWuetCiyxN70mTxbG14SQh5a5RCeQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
> -----Original Message-----
> From: Javier Domingo
> Sent: Wednesday, November 14, 2012 8:15 PM
>
> Hi Andrew,
>
> Doing this would require I got tracked which one comes from which. So
> it would imply some logic (and db) over it. With the hardlinking way,
> it wouldn't require anything. The idea is that you don't have to do
> anything else in the server.
>
> I understand that it would be imposible to do it for windows users
Not true, it is a file system issue not an os issue. FAT does not support hard links, but ext2,3,4 and NTFS do.
> (but using cygwin), but for *nix ones yes...
> Javier Domingo
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 15:33 UTC (permalink / raw)
To: Marc Khouzam; +Cc: szeder, git
In-Reply-To: <CAFj1UpEdft+L5KW+tMy6Lqm1eUkHQgwWuXaC0UTUdqwW=ohk-Q@mail.gmail.com>
On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>>> The current tcsh-completion support for Git, as can be found on the
>>> Internet, takes the approach of defining the possible completions
>>> explicitly. This has the obvious draw-back to require constant
>>> updating as the Git code base evolves.
>>>
>>> The approach taken by this commit is to to re-use the advanced bash
>>> completion script and use its result for tcsh completion. This is
>>> achieved by executing (versus sourcing) the bash script and
>>> outputting the completion result for tcsh consumption.
>>>
>>> Three solutions were looked at to implement this approach with (A)
>>> being retained:
>>>
>>> A) Modifications:
>>> git-completion.bash and new git-completion.tcsh
>>
>> As I said, I don't think this is needed. It can be done in a single
>> stand-alone script without modifications to git-completion.bash.
>>
>> This works:
>
> Thank you for taking the time to try things out.
>
> What you suggest below is an improvement on solution (C).
> I had chosen (A) instead because (C) creates a third script
> which gets generated each time a new shell is started.
We could generate the script only when it's not already present. The
disadvantage is that if this script is updated, the helper one would
not. One way to solve the problem would be to append the current
version of git, and figure a way to query it out. Another would be to
checksum it. But then again, maybe it's more expensive to check the
version or checksum than just write the file again.
Is it possible to just check if this is a login shell?
>> set called = ($_)
>
> I fought with this a lot before posting to the list.
> It seems that $_ is not set when a double sourcing
> happens. Testing the solution as an actual user
> showed me that when I start a new shell it
> sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
> and then $_ is empty for some reason.
>
> I couldn't find another way to figure out where the script
> is located, which is why I had to force the user to use
> ${HOME} for everything.
Ah :(
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Marc Khouzam @ 2012-11-16 15:48 UTC (permalink / raw)
To: Felipe Contreras; +Cc: szeder, git
In-Reply-To: <CAMP44s1RtOj6LKCNJ8SX8KSA8eNCMZ+4D-VfQ+WtXju-KhG8ng@mail.gmail.com>
On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>> On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>>>> The current tcsh-completion support for Git, as can be found on the
>>>> Internet, takes the approach of defining the possible completions
>>>> explicitly. This has the obvious draw-back to require constant
>>>> updating as the Git code base evolves.
>>>>
>>>> The approach taken by this commit is to to re-use the advanced bash
>>>> completion script and use its result for tcsh completion. This is
>>>> achieved by executing (versus sourcing) the bash script and
>>>> outputting the completion result for tcsh consumption.
>>>>
>>>> Three solutions were looked at to implement this approach with (A)
>>>> being retained:
>>>>
>>>> A) Modifications:
>>>> git-completion.bash and new git-completion.tcsh
>>>
>>> As I said, I don't think this is needed. It can be done in a single
>>> stand-alone script without modifications to git-completion.bash.
>>>
>>> This works:
>>
>> Thank you for taking the time to try things out.
>>
>> What you suggest below is an improvement on solution (C).
>> I had chosen (A) instead because (C) creates a third script
>> which gets generated each time a new shell is started.
>
> We could generate the script only when it's not already present. The
> disadvantage is that if this script is updated, the helper one would
> not.
I didn't like that too much either.
> One way to solve the problem would be to append the current
> version of git, and figure a way to query it out. Another would be to
> checksum it. But then again, maybe it's more expensive to check the
> version or checksum than just write the file again.
Yeah, I'm also thinking that re-generating the script is not bad enough
to introduce this complexity.
> Is it possible to just check if this is a login shell?
I think it would be nice to allow the user to manually
source git-completion.tcsh, in case they want to make
manual modifications to it.
I think the most user-friendly option is to actually re-generate the
script each time. It feels wrong, but it works well :)
>>> set called = ($_)
>>
>> I fought with this a lot before posting to the list.
>> It seems that $_ is not set when a double sourcing
>> happens. Testing the solution as an actual user
>> showed me that when I start a new shell it
>> sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
>> and then $_ is empty for some reason.
>>
>> I couldn't find another way to figure out where the script
>> is located, which is why I had to force the user to use
>> ${HOME} for everything.
>
> Ah :(
>
> --
> Felipe Contreras
^ permalink raw reply
* [PATCH v3] tcsh-completion re-using git-completion.bash
From: Marc Khouzam @ 2012-11-16 16:12 UTC (permalink / raw)
To: Felipe Contreras, SZEDER Gábor, git
In-Reply-To: <CAFj1UpHLf2je_+b1e5B_5thZ03UYVmW=CWhAh63kNRCbke0kQw@mail.gmail.com>
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by sourcing the bash script and outputting the completion
result for tcsh consumption.
Three solutions were looked at to implement this approach with (C)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
Here's another version which adds contrib/completion/git-completion.tcsh but
does not modify contrib/completion/git-completion.bash at all.
(Sorry, but I still can't get gmail to stop changing the tabs for spaces)
Thanks in advance.
Marc
contrib/completion/git-completion.tcsh | 63 ++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100644
index 0000000..76395f9
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,63 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam <marc.khouzam@gmail.com>
+# Distributed under the GNU General Public License, version 2.0.
+#
+# When sourced, this script will generate a new script that uses
+# the git-completion.bash script provided by core Git. This new
+# script can be used by tcsh to perform git completion.
+# The current script also issues the necessary tcsh 'complete'
+# commands.
+#
+# To use this completion script:
+#
+# 1) Copy both this file and the bash completion script to ${HOME}.
+# You _must_ use the name ${HOME}/.git-completion.bash for the
+# bash script.
+# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
+# 2) Add the following line to your .tcshrc/.cshrc:
+# source ~/.git-completion.tcsh
+
+set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
+set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+
+cat << EOF > ${__git_tcsh_completion_script}
+#!bash
+#
+# This script is GENERATED and will be overwritten automatically.
+# Do not modify it directly. Instead, modify the git-completion.tcsh
+# script provided by Git core.
+#
+
+source ${__git_tcsh_completion_original_script}
+
+# Set COMP_WORDS in a way that can be handled by the bash script.
+COMP_WORDS=(\$1)
+
+# The cursor is at the end of parameter #1.
+# We must check for a space as the last character which will
+# tell us that the previous word is complete and the cursor
+# is on the next word.
+if [ "\${1: -1}" == " " ]; then
+ # The last character is a space, so our location is at the end
+ # of the command-line array
+ COMP_CWORD=\${#COMP_WORDS[@]}
+else
+ # The last character is not a space, so our location is on the
+ # last word of the command-line array, so we must decrement the
+ # count by 1
+ COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
+fi
+
+# Call _git() or _gitk() of the bash script, based on the first
+# element of the command-line
+_\${COMP_WORDS[0]}
+
+IFS=\$'\n'
+echo "\${COMPREPLY[*]}"
+EOF
+
+complete git 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}" | \sort | \uniq`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}" | \sort | \uniq`/'
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* cloning a namespace downloads all the objects
From: Sitaram Chamarty @ 2012-11-16 16:34 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have a repo on a server, which contains, as namespaces, the contents
of several different repos of varying sizes. When I run a clone
command for the smallest of the namespaces (I have a script that
intercepts the clone and sets GIT_NAMESPACE appropriately), I get the
correct set of refs, but *all* the objects from *all* the namespaces.
And since no refs from the other namespaces have come down, a 'git gc
--prune=now', run immediately after, reduces the size of
".git/objects" to the size I would expect for just that small
namespace.
In effect, it is bringing down data that is not reachable and will be
wiped out on the next gc.
Is this expected?
--
Sitaram
^ permalink raw reply
* Re: cloning a namespace downloads all the objects
From: Junio C Hamano @ 2012-11-16 16:43 UTC (permalink / raw)
To: Josh Triplett; +Cc: Git Mailing List, Sitaram Chamarty
In-Reply-To: <CAMK1S_hdsgXoPcSn__htpGCpmCsAGb9j+m+SvxtO_69eqC92gA@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> Hi,
>
> I have a repo on a server, which contains, as namespaces, the contents
> of several different repos of varying sizes. When I run a clone
> command for the smallest of the namespaces (I have a script that
> intercepts the clone and sets GIT_NAMESPACE appropriately), I get the
> correct set of refs, but *all* the objects from *all* the namespaces.
>
> And since no refs from the other namespaces have come down, a 'git gc
> --prune=now', run immediately after, reduces the size of
> ".git/objects" to the size I would expect for just that small
> namespace.
>
> In effect, it is bringing down data that is not reachable and will be
> wiped out on the next gc.
>
> Is this expected?
I do not think so.
This was done with a series between a1bea2c (ref namespaces:
infrastructure, 2011-07-05) and bf7930c (ref namespaces: tests,
2011-07-21); Josh, care to comment on and to look into it?
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 17:18 UTC (permalink / raw)
To: Marc Khouzam; +Cc: szeder, git
In-Reply-To: <CAFj1UpHLf2je_+b1e5B_5thZ03UYVmW=CWhAh63kNRCbke0kQw@mail.gmail.com>
On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> Is it possible to just check if this is a login shell?
>
> I think it would be nice to allow the user to manually
> source git-completion.tcsh, in case they want to make
> manual modifications to it.
Yeah, they could still do that... because they would be running in a
login shell.
What I meant is that if the user does: tcsh
my_script_that_has_nothing_to_do_with_completion.sh, they would not be
executing this whole script.
> I think the most user-friendly option is to actually re-generate the
> script each time. It feels wrong, but it works well :)
I'm not too strongly opposed to add that function to the bash
completion, but to do it only for tcsh doesn't sound right, specially
when there are other alternatives. Correct me if I'm wrong, but very
few people use tcsh.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v3] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 17:21 UTC (permalink / raw)
To: Marc Khouzam; +Cc: SZEDER Gábor, git
In-Reply-To: <CAFj1UpGmoEiLeHPh8LaUGLktV55YbTthi1wMNjLDn6vFMSdMwQ@mail.gmail.com>
On Fri, Nov 16, 2012 at 5:12 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> diff --git a/contrib/completion/git-completion.tcsh
> b/contrib/completion/git-completion.tcsh
> new file mode 100644
> index 0000000..76395f9
> --- /dev/null
> +++ b/contrib/completion/git-completion.tcsh
> @@ -0,0 +1,63 @@
> +#!tcsh
> +#
> +# tcsh completion support for core Git.
> +#
> +# Copyright (C) 2012 Marc Khouzam <marc.khouzam@gmail.com>
> +# Distributed under the GNU General Public License, version 2.0.
> +#
> +# When sourced, this script will generate a new script that uses
> +# the git-completion.bash script provided by core Git. This new
> +# script can be used by tcsh to perform git completion.
> +# The current script also issues the necessary tcsh 'complete'
> +# commands.
> +#
> +# To use this completion script:
> +#
> +# 1) Copy both this file and the bash completion script to ${HOME}.
> +# You _must_ use the name ${HOME}/.git-completion.bash for the
> +# bash script.
> +# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
> +# 2) Add the following line to your .tcshrc/.cshrc:
> +# source ~/.git-completion.tcsh
> +
> +set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
> +set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
> +
> +cat << EOF > ${__git_tcsh_completion_script}
> +#!bash
> +#
> +# This script is GENERATED and will be overwritten automatically.
> +# Do not modify it directly. Instead, modify the git-completion.tcsh
> +# script provided by Git core.
> +#
> +
> +source ${__git_tcsh_completion_original_script}
> +
> +# Set COMP_WORDS in a way that can be handled by the bash script.
> +COMP_WORDS=(\$1)
> +
> +# The cursor is at the end of parameter #1.
> +# We must check for a space as the last character which will
> +# tell us that the previous word is complete and the cursor
> +# is on the next word.
> +if [ "\${1: -1}" == " " ]; then
> + # The last character is a space, so our location is at the end
> + # of the command-line array
> + COMP_CWORD=\${#COMP_WORDS[@]}
> +else
> + # The last character is not a space, so our location is on the
> + # last word of the command-line array, so we must decrement the
> + # count by 1
> + COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
> +fi
> +
> +# Call _git() or _gitk() of the bash script, based on the first
> +# element of the command-line
> +_\${COMP_WORDS[0]}
> +
> +IFS=\$'\n'
> +echo "\${COMPREPLY[*]}"
> +EOF
> +
> +complete git 'p/*/`bash ${__git_tcsh_completion_script}
> "${COMMAND_LINE}" | \sort | \uniq`/'
> +complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
> "${COMMAND_LINE}" | \sort | \uniq`/'
This looks good to me. Except that maybe the sort and uniq can be
moved to inside the script.
--
Felipe Contreras
^ permalink raw reply
* Re: cloning a namespace downloads all the objects
From: Jeff King @ 2012-11-16 17:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh Triplett, Git Mailing List, Sitaram Chamarty
In-Reply-To: <7vvcd57b32.fsf@alter.siamese.dyndns.org>
On Fri, Nov 16, 2012 at 08:43:13AM -0800, Junio C Hamano wrote:
> > I have a repo on a server, which contains, as namespaces, the contents
> > of several different repos of varying sizes. When I run a clone
> > command for the smallest of the namespaces (I have a script that
> > intercepts the clone and sets GIT_NAMESPACE appropriately), I get the
> > correct set of refs, but *all* the objects from *all* the namespaces.
> >
> > And since no refs from the other namespaces have come down, a 'git gc
> > --prune=now', run immediately after, reduces the size of
> > ".git/objects" to the size I would expect for just that small
> > namespace.
> >
> > In effect, it is bringing down data that is not reachable and will be
> > wiped out on the next gc.
> >
> > Is this expected?
>
> I do not think so.
>
> This was done with a series between a1bea2c (ref namespaces:
> infrastructure, 2011-07-05) and bf7930c (ref namespaces: tests,
> 2011-07-21); Josh, care to comment on and to look into it?
I'd guess that the "create_full_pack" logic in create_pack_file is to
blame. The client asked for everything we advertised, so we pass "--all"
to pack-objects rather than giving it the specific list of tips.
We'd have to either fix that logic, or teach the pack-objects subprocess
to respect GIT_NAMESPACE when processing --all.
-Peff
^ permalink raw reply
* Auto-repo-repair
From: Enrico Weigelt @ 2012-11-16 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <0c0e34a4-16ab-40a0-9293-af94e34e4290@zcs>
Hi folks,
suppose the following scenario:
I've broken some repo (missing objects), eg by messing something up
w/ alternates, broken filesystem, or whatever. And I've got a bunch
of remotes which (together) contain all of the lost objects.
Now I'd like to run some $magic_command which automatically fetches
all the missing objects and so repair my local repo.
Is this already possible right now ?
thx
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox