* 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: 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
* [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
* [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 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 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
* 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
* 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: [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: 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] 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: `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: 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: 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
* 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: [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
* Re: [PATCH] wildmatch: correct isprint and isspace
From: Nguyen Thai Ngoc Duy @ 2012-11-16 4:19 UTC (permalink / raw)
To: Jan H. Schönherr
Cc: git, Junio C Hamano, rene.scharfe, Johannes Sixt, torvalds
In-Reply-To: <50A522B5.7080206@cs.tu-berlin.de>
On Fri, Nov 16, 2012 at 12:13 AM, "Jan H. Schönherr"
<schnhrr@cs.tu-berlin.de> wrote:
>> #define isprint(x) (sane_istest(x, GIT_ALPHA | GIT_DIGIT | GIT_SPACE | \
>> GIT_PUNCT | GIT_REGEX_SPECIAL | GIT_GLOB_SPECIAL | \
>> - GIT_PATHSPEC_MAGIC))
>> + GIT_PATHSPEC_MAGIC) && \
>> + (x) >= 32)
>
> May I suggest the current is_print() implementation in master:
>
> #define isprint(x) ((x) >= 0x20 && (x) <= 0x7e)
>
>
> To summarize my opinion:
>
> I no longer see a reason to correct isspace() (unless somebody with an actual
> use case complains), and a more POSIXly isprint() is already in master.
>
> => Nothing to do. :)
Yeah. I remember to remind myself to check "the implementation in
master" you mentioned but I probably failed at that. Just checked that
isprint() is already in master, and your comment about isspace() use
in wildmatch.c makes sense too. So I'm all for doing nothing.
--
Duy
^ permalink raw reply
* Re: [PATCH] Unify appending signoff in format-patch, commit and sequencer
From: Nguyen Thai Ngoc Duy @ 2012-11-16 4:13 UTC (permalink / raw)
To: Brandon Casey; +Cc: git@vger.kernel.org
In-Reply-To: <CA+sFfMcfGbGDeXKZD1o4pmhbrJ1E5WgV3qrQBPT3eH=W54tNGw@mail.gmail.com>
On Fri, Nov 16, 2012 at 3:42 AM, Brandon Casey <drafnel@gmail.com> wrote:
>> Interestingly this patch triggers the fault that it fixes.
>> I was surprised that there was no blank line before my S-o-b
>> and thought I broke something. It turns out I used unmodified
>> format-patch and it mistook the S-o-b quote as true S-o-b line.
>> The modified one puts the blank line back.
>
> Heh, yeah I noticed this bug yesterday when I submitted my changes
> affecting the same area of code (sequence.c). Glad I didn't waste too
> much time fixing it.
>
> Have you looked at this:
>
> http://thread.gmane.org/gmane.comp.version-control.git/209781
>
> That series doesn't duplicate your work, but the two series's should
> be resolved.
Thanks I'm watching that discussion now and probably will rebase on
top of yours once it's finalized. I actually wrote this patch a while
ago, just waiting for nd/builtin-to-libgit to graduate because of some
linking issues this patch causes. I can wait a bit longer until yours
graduates.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/5] t/t3511: demonstrate breakage in cherry-pick -s
From: Brandon Casey @ 2012-11-16 2:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Brandon Casey
In-Reply-To: <7v8va28g1c.fsf@alter.siamese.dyndns.org>
On Thu, Nov 15, 2012 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> The cherry-pick -s functionality is currently broken in two ways.
>>
>> 1. handling of rfc2822 continuation lines has a bug, and the
>> continuation lines are not handled correctly.
>
> This is not limited to you, but people should think twice when
> writing "has a bug" and "are not handled correctly" in their log
> message. Did you write what the expected and actual behaviours?
Yeah, I wasn't clear here. The "bug" was that the incorrect index
variable was being used, which caused the wrong line to be examined to
see if it was an rfc2822 continuation line. I could have mentioned
that.
>> +rfc2822_mesg="$non_rfc2822_mesg
>> +
>> +Signed-off-by: A.U. Thor
>> + <author@example.com>
>> +Signed-off-by: B.U. Thor <buthor@example.com>"
>
> The S-o-b: lines are meant to record people's contact info in human
> readable forms, and folding the lines like the above makes it a lot
> harder to read. They typically do not have to be folded.
Well, I wasn't adding functionality here, I was only fixing what I
noticed was broken when I started touching this code.
> Besides, the footer lines are *not* RFC2822 headers (and are not
> used as such when send-email comes up with Cc: list) in the first
> place; have we ever said anything about supporting the RFC2822 line
> folding in the commit footer? If not (and I am reasonably sure we
> never have), I personally think we should actively *discourage* line
> folding there.
That's fine with me. I can't think of a reason that would make it
necessary to support line continuation.
>> i.e. we should produce this:
>>
>> Signed-off-by: A.U. Thor <author@example.com>
>> (cherry picked from )
>> Signed-off-by: C O Mmitter <committer@example.com>
>>
>> not
>>
>> Signed-off-by: A.U. Thor <author@example.com>
>> (cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
>>
>> Signed-off-by: C O Mmitter <committer@example.com>
>
> I can buy that, but then this makes it very clear that these footer
> lines are not shaped like RFC2822 headers, no?
The lines that are _not_ "(cherry picked from ...)" lines do follow
the format defined by rfc2822 for header lines (mostly). That's
probably why the author of the function in sequencer.c that checks for
a s-o-b footer named it "ends_rfc2822_footer".
I'll remove the *broken* existing code that was intended to support
continuation lines and submit a new patch.
-Brandon
^ permalink raw reply
* Re: [PATCH 6/5] sequencer.c: refrain from adding duplicate s-o-b lines
From: Junio C Hamano @ 2012-11-16 2:03 UTC (permalink / raw)
To: Brandon Casey; +Cc: pclouds, git, Brandon Casey
In-Reply-To: <1353021875-7552-1-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> Detect whether the s-o-b already exists in the commit footer and refrain
> from adding a duplicate.
If you are trying to forbid
git cherry-pick -s $other
from adding s-o-b: A when $other ends with these two existing s-o-b:
s-o-b: A
s-o-b: B
then I think that is a wrong thing to do.
In such a case, the resulting commit should gain another s-o-b from
A to record the provenance as a chain of events. A originally wrote
the patch, B forwarded it (possibly with his own tweaks), and then A
picked it up and recorded the result to the history, possibly with a
final tweak or two.
^ permalink raw reply
* Re: [PATCH 2/5] t/t3511: demonstrate breakage in cherry-pick -s
From: Junio C Hamano @ 2012-11-16 1:58 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Brandon Casey
In-Reply-To: <1352943474-15573-2-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> The cherry-pick -s functionality is currently broken in two ways.
>
> 1. handling of rfc2822 continuation lines has a bug, and the
> continuation lines are not handled correctly.
This is not limited to you, but people should think twice when
writing "has a bug" and "are not handled correctly" in their log
message. Did you write what the expected and actual behaviours?
> +rfc2822_mesg="$non_rfc2822_mesg
> +
> +Signed-off-by: A.U. Thor
> + <author@example.com>
> +Signed-off-by: B.U. Thor <buthor@example.com>"
The S-o-b: lines are meant to record people's contact info in human
readable forms, and folding the lines like the above makes it a lot
harder to read. They typically do not have to be folded.
Besides, the footer lines are *not* RFC2822 headers (and are not
used as such when send-email comes up with Cc: list) in the first
place; have we ever said anything about supporting the RFC2822 line
folding in the commit footer? If not (and I am reasonably sure we
never have), I personally think we should actively *discourage* line
folding there.
> i.e. we should produce this:
>
> Signed-off-by: A.U. Thor <author@example.com>
> (cherry picked from )
> Signed-off-by: C O Mmitter <committer@example.com>
>
> not
>
> Signed-off-by: A.U. Thor <author@example.com>
> (cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
>
> Signed-off-by: C O Mmitter <committer@example.com>
I can buy that, but then this makes it very clear that these footer
lines are not shaped like RFC2822 headers, no?
Thanks.
^ permalink raw reply
* Re: [PATCH] tcsh-completion re-using git-completion.bash
From: Felipe Contreras @ 2012-11-16 1:41 UTC (permalink / raw)
To: Marc Khouzam; +Cc: szeder, git
In-Reply-To: <1352980269-15569-1-git-send-email-marc.khouzam@gmail.com>
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:
set called = ($_)
set script = "${called[2]}.tmp"
cat <<\EOF > $script
source "$HOME/.git-completion.sh"
# 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
# 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`/'
--
Felipe Contreras
^ permalink raw reply
* Re: `git mv` has ambiguous error message for non-existing target
From: Junio C Hamano @ 2012-11-16 1:34 UTC (permalink / raw)
To: Patrick Lehner; +Cc: git
In-Reply-To: <50A53A80.4080203@gmx.de>
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: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Mark Levedahl @ 2012-11-15 23:34 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Ramsay Jones, Jeff King, git
In-Reply-To: <50A54406.5080309@web.de>
On 11/15/2012 02:35 PM, Torsten Bögershausen wrote:
> On 11/15/2012 08:05 PM, Ramsay Jones wrote:
>>
>> Did the cygwin project not bump an api version number somewhere?
>>
>> ATB,
>> Ramsay Jones
> Ramsay,
> you can run uname -r to see the version number.
>
> I myself haven't fully understood all the consequences,
> somewhere between 1.7.7 and 1.7.17 the include files had been changed.
>
> If this has consequences for using e.g. winsock2.dll, I want to know
> myself ;-)
>
> /Torsten
>
>
uname -r gives the version of the dll, not of any particular package,
and all of the various components are versioned independently. The
win32api is spread across several packages, and the recent update
changed the names, There is no api number advertised. You could check
the names of currently installed packages if you assume those names
won't change, but any such method is going to be fragile (and very
unsupported).
Mark
^ permalink raw reply
* [PATCH 6/5] sequencer.c: refrain from adding duplicate s-o-b lines
From: Brandon Casey @ 2012-11-15 23:24 UTC (permalink / raw)
To: pclouds; +Cc: git, Brandon Casey, Brandon Casey
In-Reply-To: <1352943474-15573-5-git-send-email-drafnel@gmail.com>
Detect whether the s-o-b already exists in the commit footer and refrain
from adding a duplicate.
Update t3511 to test new behavior.
Signed-off-by: Brandon Casey <bcasey@nvidia.com>
---
Hi Duy,
How about this patch on top of my series as a base for your patch to
unify the code paths that append signoff in format-patch, commit, and
sequencer?
-Brandon
sequencer.c | 28 ++++++++++++++++++----------
t/t3511-cherry-pick-x.sh | 20 ++++++++++++++++++--
2 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 7ad1163..546dacb 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -42,13 +42,15 @@ static int is_cherry_pick_from_line(const char *buf, int len)
!prefixcmp(buf, cherry_picked_prefix);
}
-static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
+static int ends_rfc2822_footer(struct strbuf *sb, struct strbuf *sob,
+ int ignore_footer)
{
int hit = 0;
int i, k;
int len = sb->len - ignore_footer;
int last_was_rfc2822 = 0;
const char *buf = sb->buf;
+ int found_sob = 0;
for (i = len - 1; i > 0; i--) {
if (hit && buf[i] == '\n')
@@ -66,12 +68,15 @@ static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
if (last_was_rfc2822 && (buf[i] == ' ' || buf[i] == '\t'))
continue;
+ if ((last_was_rfc2822 = is_rfc2822_line(buf+i, k-i)) &&
+ sob && !found_sob &&
+ !strncasecmp(buf+i, sob->buf, sob->len))
+ found_sob = 1;
- if (!((last_was_rfc2822 = is_rfc2822_line(buf+i, k-i)) ||
- is_cherry_pick_from_line(buf+i, k-i)))
+ if (!(last_was_rfc2822 || is_cherry_pick_from_line(buf+i, k-i)))
return 0;
}
- return 1;
+ return 1 + found_sob;
}
static void remove_sequencer_state(void)
@@ -547,7 +552,7 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
}
if (opts->record_origin) {
- if (!ends_rfc2822_footer(&msgbuf, 0))
+ if (!ends_rfc2822_footer(&msgbuf, NULL, 0))
strbuf_addch(&msgbuf, '\n');
strbuf_addstr(&msgbuf, cherry_picked_prefix);
strbuf_addstr(&msgbuf, sha1_to_hex(commit->object.sha1));
@@ -1077,6 +1082,7 @@ int sequencer_pick_revisions(struct replay_opts *opts)
void append_signoff(struct strbuf *msgbuf, int ignore_footer)
{
struct strbuf sob = STRBUF_INIT;
+ int has_footer = 0;
int i;
strbuf_addstr(&sob, sign_off_header);
@@ -1085,10 +1091,12 @@ void append_signoff(struct strbuf *msgbuf, int ignore_footer)
strbuf_addch(&sob, '\n');
for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1] != '\n'; i--)
; /* do nothing */
- if (prefixcmp(msgbuf->buf + i, sob.buf)) {
- if (!i || !ends_rfc2822_footer(msgbuf, ignore_footer))
- strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, "\n", 1);
- strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, sob.buf, sob.len);
- }
+ if (!i || !(has_footer =
+ ends_rfc2822_footer(msgbuf, &sob, ignore_footer)))
+ strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
+ "\n", 1);
+ if (has_footer != 2)
+ strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, sob.buf,
+ sob.len);
strbuf_release(&sob);
}
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
index af7a87c..a15b199 100755
--- a/t/t3511-cherry-pick-x.sh
+++ b/t/t3511-cherry-pick-x.sh
@@ -11,9 +11,10 @@ pristine_detach () {
git clean -d -f -f -q -x
}
-non_rfc2822_mesg='base with footer
+non_rfc2822_mesg="base with footer
-Commit message body is here.'
+Commit message body is here.
+Not an s-o-b Signed-off-by: $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"
rfc2822_mesg="$non_rfc2822_mesg
@@ -25,6 +26,9 @@ rfc2822_cherry_mesg="$rfc2822_mesg
(cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709)
Tested-by: C.U. Thor <cuthor@example.com>"
+rfc2822_cherry_sob_mesg="$rfc2822_cherry_mesg
+Signed-off-by: $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>
+Signed-off-by: C.U. Thor <cuthor@example.com>"
test_expect_success setup '
git config advice.detachedhead false &&
@@ -36,6 +40,8 @@ test_expect_success setup '
test_commit "$rfc2822_mesg" foo b rfc2822-base &&
git reset --hard initial &&
test_commit "$rfc2822_cherry_mesg" foo b rfc2822-cherry-base &&
+ git reset --hard initial &&
+ test_commit "$rfc2822_cherry_sob_mesg" foo b rfc2822-cherry-sob-base &&
pristine_detach initial &&
test_commit conflicting unrelated
'
@@ -151,4 +157,14 @@ test_expect_success 'cherry-pick treats -x -s "(cherry picked from..." line as p
test_cmp expect actual
'
+test_expect_success 'cherry-pick -s detects committer s-o-b already exists' '
+ pristine_detach initial &&
+ git cherry-pick -s rfc2822-cherry-sob-base &&
+ cat <<-EOF >expect &&
+ $rfc2822_cherry_sob_mesg
+ EOF
+ git log -1 --pretty=format:%B >actual &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.0
^ permalink raw reply related
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