[PATCH] zsh completion: 5.0.3 compat, use emulate
The bash completion pulled into zsh was being pulled in _as_ zsh, but
used patterns which relied on falling through as unhandled. In zsh
5.0.3 this no longer works, resulting in:
__git_complete_remote_or_refspec:33: bad pattern: +*
Fix by telling zsh to emulate sh while sourcing the bash config file,
which stickily preserves compatibility options in the function context.
This usage of emulate came in with zsh 4.3.10, released 2009-06-01.
Signed-off-by: Phil Pennock p...@spodhuis.org
---
nb: I am not on the git mailing-list, please keep me CC'd.
I have read SubmittingPatches but let me know if I've missed something.
Fix applies (unmodified) to both master and maint.
Thanks.
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index fac5e71..d898b65 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -39,7 +39,7 @@ if [ -z $script ]; then
test -f $e script=$e break
done
fi
-ZSH_VERSION='' . $script
+emulate sh -c 'ZSH_VERSION= . $script'
__gitcomp ()
{
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log --no-walk --tags produces strange result for certain user
Hi everybody, I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray To reproduce: # git clone https://github.com/spray/spray # cd spray # git log --no-walk --tags --pretty=%H %d --decorate=full | tail -3 3273edafcd9f9701d62e061c5257c0a09e2e1fb7 (tag: refs/tags/v0.8.0-RC1) ff3a2946bc54da76ddb47e82c81419cc7ae3db6b (tag: refs/tags/v0.7.0) 8b4043428b90b7f45b7241b3c2c032cf785479ce So here the last hash doesn't have a decoration. Thanks for any help. Kirill. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2013, #03; Thu, 12)
On Sun, 15 Dec 2013, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
[Stalled]
* nv/commit-gpgsign-config (2013-11-06) 1 commit
- Add the commit.gpgsign option to sign all commits
Introduce commit.gpgsign configuration variable to force every
commit to be GPG signed.
Needs tests, perhaps?
Ok, I'll add some tests.
Besides, we would need at least something like this to make sure
that people have a way to selectively disable configured default
when necessary, perhaps like this.
This looks like a good idea.
-- 8 --
Subject: [PATCH] commit-tree: add and document --no-gpg-sign
Document how to override commit.gpgsign configuration that is set to
true per git commit invocation (parse-options machinery lets us
say --no-gpg-sign to do so).
git commit-tree does not use parse-options, so manually add the
corresponding option for now.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-commit-tree.txt | 5 +
Documentation/git-commit.txt | 4
builtin/commit-tree.c | 5 +
3 files changed, 14 insertions(+)
diff --git a/Documentation/git-commit-tree.txt
b/Documentation/git-commit-tree.txt
index cafdc96..a469eab 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -55,8 +55,13 @@ OPTIONS
from the standard input.
-S[keyid]::
+--gpg-sign[=keyid]::
GPG-sign commit.
Looking at the code, commit-tree does not currently support the
--gpg-sign= option, only the short one -S.
If we want to add it for consistency with the --no-gpg-sign option, it
can be added with this change :
diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c
index 1646d5b25e4f..b380d486c89a 100644
--- a/builtin/commit-tree.c
+++ b/builtin/commit-tree.c
@@ -71,6 +71,11 @@ int cmd_commit_tree(int argc, const char **argv, const char
*prefix)
continue;
}
+ if (!memcmp(arg, --gpg-sign=, 11)) {
+ sign_commit = arg + 11;
+ continue;
+ }
+
if (!strcmp(arg, -m)) {
if (argc = ++i)
usage(commit_tree_usage);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] test the commit.gpgsign config option
The tests are checking that : - when commit.gpgsign is true, git commit creates signed commits - when commit.gpgsign is false, git commit creates unsigned commits - when commit.gpgsign is true, git commit --no-gpg-sign creates unsigned commits - when commit.gpgsign is true, git rebase -f creates signed commits Signed-off-by: Nicolas Vigier bo...@mars-attacks.org --- t/t7510-signed-commit.sh | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh index 1d3c56fe61fa..537bfba76ecf 100755 --- a/t/t7510-signed-commit.sh +++ b/t/t7510-signed-commit.sh @@ -25,12 +25,29 @@ test_expect_success GPG 'create signed commits' ' git tag fourth-unsigned test_tick git commit --amend -S -m fourth signed - git tag fourth-signed + git tag fourth-signed + + git config commit.gpgsign true + echo 5 file test_tick git commit -a -m fifth signed + git tag fifth-signed + + git config commit.gpgsign false + echo 6 file test_tick git commit -a -m sixth + git tag sixth-unsigned + + git config commit.gpgsign true + echo 7 file test_tick git commit -a -m seventh --no-gpg-sign + git tag seventh-unsigned + + test_tick git rebase -f HEAD^^ git tag sixth-signed HEAD^ + git tag seventh-signed + + git config --unset commit.gpgsign ' test_expect_success GPG 'show signatures' ' ( - for commit in initial second merge master + for commit in initial second merge fourth-signed fifth-signed sixth-signed master do git show --pretty=short --show-signature $commit actual grep Good signature from actual || exit 1 @@ -39,7 +56,7 @@ test_expect_success GPG 'show signatures' ' done ) ( - for commit in merge^2 fourth-unsigned + for commit in merge^2 fourth-unsigned sixth-unsigned seventh-unsigned do git show --pretty=short --show-signature $commit actual grep Good signature from actual exit 1 @@ -52,7 +69,7 @@ test_expect_success GPG 'show signatures' ' test_expect_success GPG 'detect fudged signature' ' git cat-file commit master raw - sed -e s/fourth signed/4th forged/ raw forged1 + sed -e s/seventh/7th forged/ raw forged1 git hash-object -w -t commit forged1 forged1.commit git show --pretty=short --show-signature $(cat forged1.commit) actual1 grep BAD signature from actual1 -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git fsck fails on malloc of 80 G
I have a large repository (17 GiB of disk used), although no single file in the repository is over 1 GiB. (I have pack.packSizeLimit set to 1g.) I don't know how many files are in the repository, but it shouldn't exceed several tens of commits each containing several tens of thousands of files. Due to Git crashing while performing an operation, I want to verify that the repository is consistent. However, when I run git fsck it fails, apparently because it is trying to allocate 80 G of memory. (I can still do adds, commits, etc.) # git fsck Checking object directories: 100% (256/256), done. fatal: Out of memory, malloc failed (tried to allocate 80530636801 bytes) # I don't know if this is due to an outright bug or not. But it seems to me that git fsck should not need to allocate any more memory than the size (1 GiB) of a single pack file. And given its purpose, git fsck should be one of the *most* robust Git tools! Dale -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] diff: move no-index detection to builtin/diff.c
Thomas Gummerer t.gumme...@gmail.com writes:
What happens if I run 'git diff --no-index /tmp git.c git.c' from
within a git repository? With this, I fear I will get
Thanks, I've missed that one. It only happens when run outside a git
repository, but the same comments still apply. Will fix and send a
re-roll.
Please don't, as the last round has already been pushed on 'next'.
An incremental change on top would also illustrate more clearly what
breakage needed to be fixed, which would be another good thing. It
could even come with a new test that makes sure that the above
command line is diagnosed correctly as a mistake ;-).
Thanks.
Not a git repository
To compare two paths outside a working tree:
usage: git diff [--no-index] path path
instead of the expected
usage: git diff --no-index path path
Something like
if (no_index)
;
else if (nongit)
no_index = DIFF_NO_INDEX_IMPLICIT;
else if (argc != i + 2)
;
else if (!path_inside_repo(prefix, argv[i]) ||
!path_inside_repo(prefix, argv[i + 1]))
no_index = DIFF_NO_INDEX_IMPLICIT;
should work. Or:
if (!no_index) {
/*
* Treat git diff with ...
*/
if (nongit || ...)
no_index = DIFF_NO_INDEX_IMPLICIT;
}
Or the '!no_index ' condition inserted some other way.
- /* If this is a no-index diff, just run it and exit there. */
- diff_no_index(rev, argc, argv, nongit, prefix);
+ if (no_index) {
+ if (argc != i + 2) {
[...]
+ /* Give the usage message for non-repository usage and
exit. */
+ usagef(git diff %s path path,
+ no_index == DIFF_NO_INDEX_EXPLICIT ?
+ --no-index : [--no-index]);
+
+ }
+ /* If this is a no-index diff, just run it and exit there. */
+ diff_no_index(rev, argc, argv, prefix);
+ }
Perhaps, to avoid some nesting:
/* A no-index diff takes exactly two path arguments. */
if (no_index argc != i + 2) {
...
usagef(...);
}
if (no_index)
/* Just run the diff and exit. */
diff_no_index(...);
Jonathan
Thanks, will change in the re-roll.
--
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] diff: Let git diff -O read orderfile from any file, failing when appropriate
Samuel Bronson naes...@gmail.com writes:
The -O flag really shouldn't silently fail to do anything when given a
path that it can't read from.
However, it should be able to read from un-mappable files, such as
pipes/fifos, /dev/null (as we document in the next patch), or in fact
*any* empty file (since Linux 2.6.12).
Could you enlighten the commit log readers a bit better here? Those
who know the change in 2.6.12 (i.e. 'mmapping with length 0 must
fail', says SUSv3, so we fail) you have in mind would know what you
mean by in fact any empty file even if you did not have (since
Linux 2.6.12), but those who do not know it would not be helped
with just (since Linux 2.6.12).
(Especially since we will be
documenting -O/dev/null to override diff.orderfile when we add that.)
(Note: -O/dev/null did have the right effect, since the existing error
handling essentially worked out to silently ignore the orderfile.)
So lets toss all of that logic to get the file mmapped and just use
strbuf_read_file() instead, which gives us decent error handling
practically for free.
Sounds good. In the longer term, we may want to move this
file-scope static to per-infocation struct diff_options and clean
up the storage used to hold the list of path patterns after we are
done with the diff, but that is outside the scope of this series.
Thanks.
Signed-off-by: Samuel Bronson naes...@gmail.com
---
diffcore-order.c | 23 ---
t/t4056-diff-order.sh | 23 +++
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/diffcore-order.c b/diffcore-order.c
index 23e9385..a63f332 100644
--- a/diffcore-order.c
+++ b/diffcore-order.c
@@ -10,28 +10,21 @@ static int order_cnt;
static void prepare_order(const char *orderfile)
{
- int fd, cnt, pass;
+ int cnt, pass;
+ struct strbuf sb = STRBUF_INIT;
void *map;
char *cp, *endp;
- struct stat st;
- size_t sz;
+ ssize_t sz;
if (order)
return;
- fd = open(orderfile, O_RDONLY);
- if (fd 0)
- return;
- if (fstat(fd, st)) {
- close(fd);
- return;
- }
- sz = xsize_t(st.st_size);
- map = mmap(NULL, sz, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
- close(fd);
- if (map == MAP_FAILED)
- return;
+ sz = strbuf_read_file(sb, orderfile, 0);
+ if (sz 0)
+ die_errno(_(failed to read orderfile '%s'), orderfile);
+ map = strbuf_detach(sb, NULL);
endp = (char *) map + sz;
+
for (pass = 0; pass 2; pass++) {
cnt = 0;
cp = map;
diff --git a/t/t4056-diff-order.sh b/t/t4056-diff-order.sh
index 398b3f6..eb471e7 100755
--- a/t/t4056-diff-order.sh
+++ b/t/t4056-diff-order.sh
@@ -61,12 +61,35 @@ test_expect_success no order (=tree object order) '
test_cmp expect_none actual
'
+test_expect_success 'missing orderfile' '
+ rm -f bogus_file
+ test_must_fail git diff -Obogus_file --name-only HEAD^..HEAD
+'
+
+test_expect_success 'unreadable orderfile' '
+ touch unreadable_file
+ chmod -r unreadable_file
+ test_must_fail git diff -Ounreadable_file --name-only HEAD^..HEAD
+'
+
+test_expect_success 'orderfile is a directory' '
+ test_must_fail git diff -O/ --name-only HEAD^..HEAD
+'
+
for i in 1 2
do
test_expect_success orderfile using option ($i) '
git diff -Oorder_file_$i --name-only HEAD^..HEAD actual
test_cmp expect_$i actual
'
+
+ test_expect_success PIPE orderfile is fifo ($i) '
+ rm -f order_fifo
+ mkfifo order_fifo
+ cat order_file_$i order_fifo
+ git diff -O order_fifo --name-only HEAD^..HEAD actual
+ test_cmp expect_$i actual
+'
done
test_done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 3/3] diff: Add diff.orderfile configuration variable
Samuel Bronson naes...@gmail.com writes: diff.orderfile acts as a default for the -O command line option. [sb: split up aw's original patch; reworked tests and docs] [FIXME: Relative paths should presumably be interpreted relative to repository root; how should this be accomplished?] Do you mean something like this? $ cd docs $ edit orderfile $ git diff -Oordefile $ cd subdir $ git diff -O../orderfile Path-like parameters and values given by the end user should be relative to the directory where the end user is (i.e. both -O parameters in the above example name docs/orderfile). All Git processes, even the ones that are capable of being run from a subdirectory, are supposed to first chdir to the top level of the working tree before doing anything else, and adjust the path-like things they get from the end user from the command line accordingly. By the time diffcore_order() to prepare_order() callchain is called, we certainly should have passed that chdir already, so the value of the option needs to be prepended with the prefix when parsed. The value specified for the diff.orderfile configuration can just be a path relative to the top level of the working tree, I think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected cherry-pick behaviour
From: Philip Oakley philipoak...@iee.org From: Junio C Hamano gits...@pobox.com, Saturday, December 14, 2013 7:39 PM Philip Oakley philipoak...@iee.org writes: Would this be a good use of the * Magic pathspecs like :(icase) that was recently released (v1.8.5 2Dec13) so that the merge stages can be named. Because the pathspec mechahism is for you to tell an operation that works on a collection of paths (e.g. all the paths in the HEAD, all the paths at stage #1 in the index) to narrow the set it operates on down to only those that match, I do not think it is a good match at all to what you are trying to do. My point was that the :1: syntax already was a path at stage #1 in the index indicator, and that it would be good to have a memorable name for the :1:2:3: stages as per Antoine's query. Could someone point me at where is this syntax decoded? My initial hunt around the code base didn't find the relevant location. It maybe that my referring to it as a 'magic pathspec' was a mistake, but the difficulty of remembering which number is ours:theirs:base still stands. (for general info; the :stage: format is defined in 'git revision (7)' as the last method for Specifying Revisions) Philip -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pack-objects: name pack files after trailer hash
On Mon, Dec 16, 2013 at 08:41:38AM +0100, Michael Haggerty wrote:
The old naming scheme is documented in
Documentation/git-pack-objects.txt, under OPTIONS - base-name:
base-name::
Write into a pair of files (.pack and .idx), using
base-name to determine the name of the created file.
When this option is used, the two files are written in
base-name-SHA-1.{pack,idx} files. SHA-1 is a hash
of the sorted object names to make the resulting filename
based on the pack content, and written to the standard
output of the command.
The documentation should either be updated or the description of the
naming scheme should be removed altogether.
Thanks. I looked in Documentation/technical for anything to update, but
didn't imagine we would be advertising the format in the user-facing
documentation. :)
The original patch is in next, so here's one on top. I just updated the
description. I was tempted to explicitly say something like this is
opaque and meaningless to you, don't rely on it, but I don't know that
there is any need.
-- 8 --
Subject: docs: update pack-objects base-name description
As of 1190a1a, the SHA-1 used to determine the filename is
now calculated differently. Update the documentation to
reflect this.
Noticed-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Jeff King p...@peff.net
---
On top of jk/name-pack-after-byte-representations, naturally.
Documentation/git-pack-objects.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/git-pack-objects.txt
b/Documentation/git-pack-objects.txt
index d94edcd..c69affc 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -51,8 +51,7 @@ base-name::
base-name to determine the name of the created file.
When this option is used, the two files are written in
base-name-SHA-1.{pack,idx} files. SHA-1 is a hash
- of the sorted object names to make the resulting filename
- based on the pack content, and written to the standard
+ of the bytes of the packfile, and is written to the standard
output of the command.
--stdout::
--
1.8.5.524.g6743da6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Looking for pre-commit hook to check whitespace errors but not for all files
Paul Menzel paulepan...@users.sourceforge.net writes: 1. Only the files actually committed should be checked. That means running `git commit -a`, abort that and then running `git commit some/file` should only check `some/file` for whitespace errors. Doesn't hooks/pre-commit.sample we ship already gets this right? $ git init foobar cd foobar $ mv .git/hooks/pre-commit.sample .git/hooks/pre-commit $ for i in foo bar; do echo $i $i.txt; done $ git commit -m initial $ for i in foo bar; do echo $i $i.txt; done $ git commit -a bar.txt:1: trailing whitespace. +bar foo.txt:1: trailing whitespace. +foo $ git commit foo.txt foo.txt:1: trailing whitespace. +foo 2. There are certain files that are allowed to have whitespace errors. As John Keeping alraedy pointed out, you can use the attributes mechanism to mark what kind of payload each path has to control this kind of thing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git fsck fails on malloc of 80 G
On Mon, Dec 16, 2013 at 11:05:32AM -0500, Dale R. Worley wrote: # git fsck Checking object directories: 100% (256/256), done. fatal: Out of memory, malloc failed (tried to allocate 80530636801 bytes) # Can you give you give us a backtrace from the die() call? It would help to know what it was trying to allocate 80G for. I don't know if this is due to an outright bug or not. But it seems to me that git fsck should not need to allocate any more memory than the size (1 GiB) of a single pack file. And given its purpose, git fsck should be one of the *most* robust Git tools! Agreed. Fsck tends to be more robust, but there are still many code paths that can die(). One of the problems I ran into recently is that corrupt data can cause it to make a large allocation; we notice the bogus data as soon as we try to start filling the buffer, but sometimes the bogus allocation is large enough to kill the process. That was fixed by b039718, which is in master but not yet any released version. You might see whether that helps. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree: My Status
Adam Spiers g...@adamspiers.org writes: Somebody take the ownership of the area, if David Green who earlier volunteered to do so and worked on it needs help reviewing, helping polishing and giving thumbs-up on the patches, perhaps? I *may* be able to help a bit in the coming weeks, given that it's reasonably likely I'll be using git-subtree for professional reasons. However I'm not clear from the above whether you're suggesting that someone should take over ownership from David, or merely help him? I'll leave that between you and David, and possibly other people who are interested in advancing git subtree who may volunteer. And in either case, what would be your criteria and process for accepting patches, given that ultimately you're still in control of the repository? I'd imagine for the first few rounds of patchsets I'll be picky about styles and design, but once whoever eventually becomes the volunteer subarea maintainer (perhaps you) demonsrates that s/he has good enough motivation and taste to keep the codebase clean and user experience consistent, I'd delegate more and more decision what to include and reject to that subarea maintainer, just like any material in the contrib/ area. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pack-objects: name pack files after trailer hash
Jeff King wrote:
The original patch is in next, so here's one on top. I just updated the
description.
Thanks.
I was tempted to explicitly say something like this is
opaque and meaningless to you, don't rely on it, but I don't know that
there is any need.
[...]
On top of jk/name-pack-after-byte-representations, naturally.
I think there is --- if someone starts caring about the SHA-1 used,
they won't be able to act on old packfiles that were created before
this change. How about something like the following instead?
-- 8 --
From: Jeff King p...@peff.net
Subject: pack-objects doc: treat output filename as opaque
After 1190a1a (pack-objects: name pack files after trailer hash,
2013-12-05), the SHA-1 used to determine the filename is calculated
differently. Update the documentation to not guarantee anything more
than that the SHA-1 depends on the pack content somehow.
Hopefully this will discourage readers from depending on the old or
the new calculation.
Reported-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/git-pack-objects.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/git-pack-objects.txt
b/Documentation/git-pack-objects.txt
index d94edcd..cdab9ed 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -51,8 +51,7 @@ base-name::
base-name to determine the name of the created file.
When this option is used, the two files are written in
base-name-SHA-1.{pack,idx} files. SHA-1 is a hash
- of the sorted object names to make the resulting filename
- based on the pack content, and written to the standard
+ based on the pack content and is written to the standard
output of the command.
--stdout::
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 3/3] diff: Add diff.orderfile configuration variable
On Mon, Dec 16, 2013 at 1:53 PM, Junio C Hamano gits...@pobox.com wrote: Samuel Bronson naes...@gmail.com writes: Path-like parameters and values given by the end user should be relative to the directory where the end user is (i.e. both -O parameters in the above example name docs/orderfile). All Git processes, even the ones that are capable of being run from a subdirectory, are supposed to first chdir to the top level of the working tree before doing anything else, and adjust the path-like things they get from the end user from the command line accordingly. By the time diffcore_order() to prepare_order() callchain is called, we certainly should have passed that chdir already, so the value of the option needs to be prepended with the prefix when parsed. The value specified for the diff.orderfile configuration can just be a path relative to the top level of the working tree, I think. Oh, cool. So I'll just change the git_config_string() call to use git_config_pathname(), since the user might easily want to use ~ notation there, especially in a user-level setting ... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pack-objects: name pack files after trailer hash
On Mon, Dec 16, 2013 at 11:19:33AM -0800, Jonathan Nieder wrote:
I was tempted to explicitly say something like this is
opaque and meaningless to you, don't rely on it, but I don't know that
there is any need.
[...]
On top of jk/name-pack-after-byte-representations, naturally.
I think there is --- if someone starts caring about the SHA-1 used,
they won't be able to act on old packfiles that were created before
this change. How about something like the following instead?
Right, my point was that I do not think anybody has ever cared, and I do
not see them starting now. But that is just my intuition.
diff --git a/Documentation/git-pack-objects.txt
b/Documentation/git-pack-objects.txt
index d94edcd..cdab9ed 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -51,8 +51,7 @@ base-name::
base-name to determine the name of the created file.
When this option is used, the two files are written in
base-name-SHA-1.{pack,idx} files. SHA-1 is a hash
- of the sorted object names to make the resulting filename
- based on the pack content, and written to the standard
+ based on the pack content and is written to the standard
I'm fine with that. I was worried it would get clunky, but the way you
have worded it is good.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pack-objects: name pack files after trailer hash
Jeff King p...@peff.net writes:
I was tempted to explicitly say something like this is
opaque and meaningless to you, don't rely on it, but I don't know that
there is any need.
Thanks.
When we did the original naming, it was envisioned that we may use
the name for fsck to make sure that the pack contains what it
contains in the name, but it never materialized. The most prominent
and useful characteristic of the new naming scheme is that two
packfiles with the same name must be identical, and we may want to
start using it some time later once everybody repacked their packs
with the updated pack-objects.
But until that time comes, some packs in existing repositories will
hash to their names while others do not, so spelling out how the new
names are derived without saying older pack-objects used to name
their output differently may add more confusion than it is worth.
base-name to determine the name of the created file.
When this option is used, the two files are written in
base-name-SHA-1.{pack,idx} files. SHA-1 is a hash
+ of the bytes of the packfile, and is written to the standard
hash of the bytes of the packfile tempts one to do
$ sha1sum .git/objects/pack/pack-*.pack
but that is not what we expect. I wonder if there are better ways to
phrase it (or alternatively perhaps we want to make that expectation
hold by updating our code to hash)?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pack-objects: name pack files after trailer hash
On Mon, Dec 16, 2013 at 11:33:11AM -0800, Junio C Hamano wrote:
base-name to determine the name of the created file.
When this option is used, the two files are written in
base-name-SHA-1.{pack,idx} files. SHA-1 is a hash
+ of the bytes of the packfile, and is written to the standard
hash of the bytes of the packfile tempts one to do
$ sha1sum .git/objects/pack/pack-*.pack
but that is not what we expect. I wonder if there are better ways to
phrase it (or alternatively perhaps we want to make that expectation
hold by updating our code to hash)?
Yeah, I wondered about that, but didn't think it was worth the verbosity
to explain that the true derivation. I think Jonathan's suggestion takes
care of it, though.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pack-objects: name pack files after trailer hash
Jeff King p...@peff.net writes:
On Mon, Dec 16, 2013 at 11:19:33AM -0800, Jonathan Nieder wrote:
I was tempted to explicitly say something like this is
opaque and meaningless to you, don't rely on it, but I don't know that
there is any need.
[...]
On top of jk/name-pack-after-byte-representations, naturally.
I think there is --- if someone starts caring about the SHA-1 used,
they won't be able to act on old packfiles that were created before
this change. How about something like the following instead?
Right, my point was that I do not think anybody has ever cared, and I do
not see them starting now. But that is just my intuition.
diff --git a/Documentation/git-pack-objects.txt
b/Documentation/git-pack-objects.txt
index d94edcd..cdab9ed 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -51,8 +51,7 @@ base-name::
base-name to determine the name of the created file.
When this option is used, the two files are written in
base-name-SHA-1.{pack,idx} files. SHA-1 is a hash
-of the sorted object names to make the resulting filename
-based on the pack content, and written to the standard
+based on the pack content and is written to the standard
I'm fine with that. I was worried it would get clunky, but the way you
have worded it is good.
Our mails crossed; I think the above is good.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] diff: add test for --no-index executed outside repo
Thomas Gummerer t.gumme...@gmail.com writes: 470faf9 diff: move no-index detection to builtin/diff.c breaks the error message for git diff --no-index, when the command is executed outside of a git repository and the wrong number of arguments are given. 6df5762 diff: don't read index when --no-index is given fixes the problem. Add a test to guard against similar breakages in the future. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Thanks, I've missed that one. It only happens when run outside a git repository, but the same comments still apply. Will fix and send a re-roll. Please don't, as the last round has already been pushed on 'next'. Sorry about that, should have checked first. An incremental change on top would also illustrate more clearly what breakage needed to be fixed, which would be another good thing. It could even come with a new test that makes sure that the above command line is diagnosed correctly as a mistake ;-). The breakage is actually fixed with the second patch as described in the commit message above, so here is just a test against future breakages. This test only works when the test root is outside of a git repository, as otherwise nongit will not be set. Is there another way to write it? Perhaps use CEILING, like this (untested)? mkdir -p test-outside/non/git ( GIT_CEILING_DIRECTORIES=$TRASH_DIRECTORY/test-outside export GIT_CEILING_DIRECTORIES cd test-outside/non/git do whatever non-git thing here ) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] difftool: Change prompt to display the number of files in the diff queue
On Fri, Dec 06, 2013 at 10:38:46AM +1100, Zoltan Klinger wrote: @@ -2928,7 +2933,14 @@ static void run_external_diff(const char *pgm, } *arg = NULL; fflush(NULL); - retval = run_command_v_opt(spawn_arg, RUN_USING_SHELL); + + env[0] = env_counter; + snprintf(env_counter, sizeof(env_counter), GIT_DIFF_PATH_COUNTER=%d, + ++o-diff_path_counter); I don't think we have a particular rule, but our usual style is to line up the continued line of arguments with the open-paren of the function, like: foo(arg1, arg2, arg3, arg4); @@ -3317,6 +3329,8 @@ void diff_setup_done(struct diff_options *options) options-output_format = DIFF_FORMAT_NO_OUTPUT; DIFF_OPT_SET(options, EXIT_WITH_STATUS); } + +options-diff_path_counter = 0; It's hard to see with the email quoting, but this is a 4-space indent rather than the usual 1-tab (which should be 8-wide on the terminals of all True Believers). Both are minor, but worth fixing IMHO (especially the second one). Looks like it's too late for squashing, so here's a patch that can go on top (doing it now is still of value, though, as it's less likely to create conflicts since nobody is building on top yet). -- 8 -- Subject: diff.c: fix some recent whitespace style violations These were introduced by ee7fb0b. Signed-off-by: Jeff King p...@peff.net --- On top of zk/difftool-counts. diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index a7d5a47..d69cc1b 100644 --- a/diff.c +++ b/diff.c @@ -2936,7 +2936,7 @@ static void run_external_diff(const char *pgm, env[0] = env_counter; snprintf(env_counter, sizeof(env_counter), GIT_DIFF_PATH_COUNTER=%d, - ++o-diff_path_counter); +++o-diff_path_counter); env[1] = env_total; snprintf(env_total, sizeof(env_total), GIT_DIFF_PATH_TOTAL=%d, q-nr); @@ -3330,7 +3330,7 @@ void diff_setup_done(struct diff_options *options) DIFF_OPT_SET(options, EXIT_WITH_STATUS); } -options-diff_path_counter = 0; + options-diff_path_counter = 0; } static int opt_arg(const char *arg, int arg_short, const char *arg_long, int *val) -- 1.8.5.1.399.g900e7cd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/3] diff: Add diff.orderfile configuration variable
The original purpose of this patch [series] was to allow specifying the -O option for git diff in the config. In this version, I've revised the commit message for patch 2, changed patch 3 to use git_config_pathname() instead of git_config_string(), and removed the FIXME from patch 3's commit message. Samuel Bronson (3): diff: Tests for git diff -O diff: Let git diff -O read orderfile from any file, fail properly diff: Add diff.orderfile configuration variable Documentation/diff-config.txt | 5 ++ Documentation/diff-options.txt | 3 ++ diff.c | 5 ++ diffcore-order.c | 23 - t/t4056-diff-order.sh | 105 + 5 files changed, 126 insertions(+), 15 deletions(-) create mode 100755 t/t4056-diff-order.sh -- 1.8.4.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] diff: Let git diff -O read orderfile from any file, fail properly
The -O flag really shouldn't silently fail to do anything when given a
path that it can't read from.
However, it should be able to read from un-mmappable files, such as:
* pipes/fifos
* /dev/null: It's a character device (at least on Linux)
* ANY empty file:
Quoting Linux mmap(2), SUSv3 specifies that mmap() should fail if
length is 0. However, in kernels before 2.6.12, mmap() succeeded in
this case: no mapping was created and the call returned addr. Since
kernel 2.6.12, mmap() fails with the error EINVAL for this case.
We especially want -O/dev/null to work, since we will be documenting
it as the way to cancel diff.orderfile when we add that.
(Note: -O/dev/null did have the right effect, since the existing error
handling essentially worked out to silently ignore the orderfile. But
this was probably more coincidence than anything else.)
So, lets toss all of that logic to get the file mmapped and just use
strbuf_read_file() instead, which gives us decent error handling
practically for free.
Signed-off-by: Samuel Bronson naes...@gmail.com
---
diffcore-order.c | 23 ---
t/t4056-diff-order.sh | 23 +++
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/diffcore-order.c b/diffcore-order.c
index 23e9385..a63f332 100644
--- a/diffcore-order.c
+++ b/diffcore-order.c
@@ -10,28 +10,21 @@ static int order_cnt;
static void prepare_order(const char *orderfile)
{
- int fd, cnt, pass;
+ int cnt, pass;
+ struct strbuf sb = STRBUF_INIT;
void *map;
char *cp, *endp;
- struct stat st;
- size_t sz;
+ ssize_t sz;
if (order)
return;
- fd = open(orderfile, O_RDONLY);
- if (fd 0)
- return;
- if (fstat(fd, st)) {
- close(fd);
- return;
- }
- sz = xsize_t(st.st_size);
- map = mmap(NULL, sz, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
- close(fd);
- if (map == MAP_FAILED)
- return;
+ sz = strbuf_read_file(sb, orderfile, 0);
+ if (sz 0)
+ die_errno(_(failed to read orderfile '%s'), orderfile);
+ map = strbuf_detach(sb, NULL);
endp = (char *) map + sz;
+
for (pass = 0; pass 2; pass++) {
cnt = 0;
cp = map;
diff --git a/t/t4056-diff-order.sh b/t/t4056-diff-order.sh
index 398b3f6..eb471e7 100755
--- a/t/t4056-diff-order.sh
+++ b/t/t4056-diff-order.sh
@@ -61,12 +61,35 @@ test_expect_success no order (=tree object order) '
test_cmp expect_none actual
'
+test_expect_success 'missing orderfile' '
+ rm -f bogus_file
+ test_must_fail git diff -Obogus_file --name-only HEAD^..HEAD
+'
+
+test_expect_success 'unreadable orderfile' '
+ touch unreadable_file
+ chmod -r unreadable_file
+ test_must_fail git diff -Ounreadable_file --name-only HEAD^..HEAD
+'
+
+test_expect_success 'orderfile is a directory' '
+ test_must_fail git diff -O/ --name-only HEAD^..HEAD
+'
+
for i in 1 2
do
test_expect_success orderfile using option ($i) '
git diff -Oorder_file_$i --name-only HEAD^..HEAD actual
test_cmp expect_$i actual
'
+
+ test_expect_success PIPE orderfile is fifo ($i) '
+ rm -f order_fifo
+ mkfifo order_fifo
+ cat order_file_$i order_fifo
+ git diff -O order_fifo --name-only HEAD^..HEAD actual
+ test_cmp expect_$i actual
+'
done
test_done
--
1.8.4.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] diff: Tests for git diff -O
Heavily adapted from Anders' patch:
diff: Add diff.orderfile configuration variable
Signed-off-by: Anders Waldenborg and...@0x63.nu
Signed-off-by: Samuel Bronson naes...@gmail.com
---
t/t4056-diff-order.sh | 72 +++
1 file changed, 72 insertions(+)
create mode 100755 t/t4056-diff-order.sh
diff --git a/t/t4056-diff-order.sh b/t/t4056-diff-order.sh
new file mode 100755
index 000..398b3f6
--- /dev/null
+++ b/t/t4056-diff-order.sh
@@ -0,0 +1,72 @@
+#!/bin/sh
+
+test_description='diff order'
+
+. ./test-lib.sh
+
+create_files () {
+ echo $1 a.h
+ echo $1 b.c
+ echo $1 c/Makefile
+ echo $1 d.txt
+ git add a.h b.c c/Makefile d.txt
+ git commit -m$1
+}
+
+test_expect_success 'setup' '
+ mkdir c
+ create_files 1
+ create_files 2
+
+ cat order_file_1 -\EOF
+ *Makefile
+ *.txt
+ *.h
+ *
+ EOF
+
+ cat order_file_2 -\EOF
+ *Makefile
+ *.h
+ *.c
+ *
+ EOF
+
+ cat expect_none -\EOF
+ a.h
+ b.c
+ c/Makefile
+ d.txt
+ EOF
+
+ cat expect_1 -\EOF
+ c/Makefile
+ d.txt
+ a.h
+ b.c
+ EOF
+
+ cat expect_2 -\EOF
+ c/Makefile
+ a.h
+ b.c
+ d.txt
+ EOF
+
+ true# end chain of
+'
+
+test_expect_success no order (=tree object order) '
+ git diff --name-only HEAD^..HEAD actual
+ test_cmp expect_none actual
+'
+
+for i in 1 2
+do
+ test_expect_success orderfile using option ($i) '
+ git diff -Oorder_file_$i --name-only HEAD^..HEAD actual
+ test_cmp expect_$i actual
+'
+done
+
+test_done
--
1.8.4.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] diff: Add diff.orderfile configuration variable
diff.orderfile acts as a default for the -O command line option.
[sb: split up aw's original patch; reworked tests and docs,
treat option as pathname]
Signed-off-by: Anders Waldenborg and...@0x63.nu
Signed-off-by: Samuel Bronson naes...@gmail.com
---
Documentation/diff-config.txt | 5 +
Documentation/diff-options.txt | 3 +++
diff.c | 5 +
t/t4056-diff-order.sh | 10 ++
4 files changed, 23 insertions(+)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 223b931..f07b451 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -98,6 +98,11 @@ diff.mnemonicprefix::
diff.noprefix::
If set, 'git diff' does not show any source or destination prefix.
+diff.orderfile::
+ File indicating how to order files within a diff, using
+ one shell glob pattern per line.
+ Can be overridden by the '-O' option to linkgit:git-diff[1].
+
diff.renameLimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the 'git diff' option '-l'.
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index bbed2cd..9b37b2a 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -432,6 +432,9 @@ endif::git-format-patch[]
-Oorderfile::
Output the patch in the order specified in the
orderfile, which has one shell glob pattern per line.
+ This overrides the `diff.orderfile` configuration variable
+ (see linkgit:git-config[1]). To cancel `diff.orderfile`,
+ use `-O/dev/null`.
ifndef::git-format-patch[]
-R::
diff --git a/diff.c b/diff.c
index 3950e01..0099b99 100644
--- a/diff.c
+++ b/diff.c
@@ -30,6 +30,7 @@ static int diff_use_color_default = -1;
static int diff_context_default = 3;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
+static const char *diff_order_file_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
static int diff_no_prefix;
@@ -201,6 +202,8 @@ int git_diff_ui_config(const char *var, const char *value,
void *cb)
return git_config_string(external_diff_cmd_cfg, var, value);
if (!strcmp(var, diff.wordregex))
return git_config_string(diff_word_regex_cfg, var, value);
+ if (!strcmp(var, diff.orderfile))
+ return git_config_pathname(diff_order_file_cfg, var, value);
if (!strcmp(var, diff.ignoresubmodules))
handle_ignore_submodules_arg(default_diff_options, value);
@@ -3207,6 +3210,8 @@ void diff_setup(struct diff_options *options)
options-detect_rename = diff_detect_rename_default;
options-xdl_opts |= diff_algorithm;
+ options-orderfile = diff_order_file_cfg;
+
if (diff_no_prefix) {
options-a_prefix = options-b_prefix = ;
} else if (!diff_mnemonic_prefix) {
diff --git a/t/t4056-diff-order.sh b/t/t4056-diff-order.sh
index eb471e7..50689d1 100755
--- a/t/t4056-diff-order.sh
+++ b/t/t4056-diff-order.sh
@@ -90,6 +90,16 @@ do
git diff -O order_fifo --name-only HEAD^..HEAD actual
test_cmp expect_$i actual
'
+
+ test_expect_success orderfile using config ($i) '
+ git -c diff.orderfile=order_file_$i diff --name-only HEAD^..HEAD
actual
+ test_cmp expect_$i actual
+'
+
+ test_expect_success cancelling configured orderfile ($i) '
+ git -c diff.orderfile=order_file_$i diff -O/dev/null --name-only
HEAD^..HEAD actual
+ test_cmp expect_none actual
+'
done
test_done
--
1.8.4.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected cherry-pick behaviour
Philip Oakley philipoak...@iee.org writes: From: Philip Oakley philipoak...@iee.org From: Junio C Hamano gits...@pobox.com, Saturday, December 14, 2013 7:39 PM Philip Oakley philipoak...@iee.org writes: Would this be a good use of the * Magic pathspecs like :(icase) that was recently released (v1.8.5 2Dec13) so that the merge stages can be named. Because the pathspec mechahism is for you to tell an operation that works on a collection of paths (e.g. all the paths in the HEAD, all the paths at stage #1 in the index) to narrow the set it operates on down to only those that match, I do not think it is a good match at all to what you are trying to do. My point was that the :1: syntax already was a path at stage #1 in the index indicator, and that it would be good to have a memorable name for the :1:2:3: stages as per Antoine's query. Could someone point me at where is this syntax decoded? sha1_name.c (anything that turns name to object name goes there, I think). Look for this comment: /* * sha1:path -- object name of path in ent sha1 * :path - object name of absolute path in index * :./path - object name of path relative to cwd in index * :[0-3]:path - object name of path in index at stage * :/foo - recent commit matching foo */ I do not think adding :ours:path as a synonym to :2:path adds enough value to make it worthwhilte to worry about breaking the expectation of those who thought ours:path/name will be something they could track if they wanted to. My initial hunt around the code base didn't find the relevant location. It maybe that my referring to it as a 'magic pathspec' was a mistake, but the difficulty of remembering which number is ours:theirs:base still stands. (for general info; the :stage: format is defined in 'git revision (7)' as the last method for Specifying Revisions) Philip -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/21] path.c: rename vsnpath() to git_vsnpath()
Jonathan Nieder jrnie...@gmail.com writes: Duy Nguyen wrote: Ramsay Jones wrote: :-D I renamed this _from_ git_vsnpath() in commit 5b3b8fa2 (path.c: Remove the 'git_' prefix from a file scope function, 04-09-2012), because ... well it's a file scope function! (i.e. the git_ prefix implies greater than file scope). I'm not very good at naming things, so ... [...] OK I go with this. I think it makes sense vsnpath - do_git_path I think this renaming would be still losing clarity --- it loses the information that this is the vsnprintf-like variant of git_path. Do we actually have a convention that functions with git_ prefix should be global? If git_path were not global, would it have to be renamed? If git_vsnpath should be renamed to avoid mistaking it for git's replacement of a hypothetical standard library vsnpath function, shouldn't git_path, git_pathdup, etc be renamed for the same reason as well? its three callers are git_vsnpath - strbuf_git_path (it's updated to take strbuf) git_path git_pathdup Yeah, independently of everything else, a strbuf variant sounds nice. OK, then strbuf_vsnpath_in_gitdir() perhaps? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] diff: add test for --no-index executed outside repo
470faf9 diff: move no-index detection to builtin/diff.c breaks the error message for git diff --no-index, when the command is executed outside of a git repository and the wrong number of arguments are given. 6df5762 diff: don't read index when --no-index is given fixes the problem. Add a test to guard against similar breakages in the future. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- Perhaps use CEILING, like this (untested)? Thanks, this makes sense, here is the new version. t/t4053-diff-no-index.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t4053-diff-no-index.sh b/t/t4053-diff-no-index.sh index 077c775..2ab3c48 100755 --- a/t/t4053-diff-no-index.sh +++ b/t/t4053-diff-no-index.sh @@ -44,4 +44,15 @@ test_expect_success 'git diff outside repo with broken index' ' ) ' +test_expect_success 'git diff --no-index executed outside repo gives correct error message' ' + ( + GIT_CEILING_DIRECTORIES=$TRASH_DIRECTORY/non + export GIT_CEILING_DIRECTORIES + cd non/git + test_must_fail git diff --no-index a 2actual.err + echo usage: git diff --no-index path path expect.err + test_cmp expect.err actual.err + ) +' + test_done -- 1.8.5.4.g8639e57 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] diff: Let git diff -O read orderfile from any file, fail properly
Samuel Bronson naes...@gmail.com writes: for i in 1 2 do test_expect_success orderfile using option ($i) ' git diff -Oorder_file_$i --name-only HEAD^..HEAD actual test_cmp expect_$i actual ' This funny indentation in the previous step needs to be fixed, and the added block below should match. + + test_expect_success PIPE orderfile is fifo ($i) ' + rm -f order_fifo + mkfifo order_fifo + cat order_file_$i order_fifo + git diff -O order_fifo --name-only HEAD^..HEAD actual I think this part can be racy depending on which between cat and git diff are scheduled first, no? Try running this test under load and I think you will see it deadlocked. Besides, the above breaks chain; even if mkfifo breaks (hence not allowing cat to run), git diff will go ahead and run, no? + test_cmp expect_$i actual +' done test_done -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-svn: Support svn:global-ignores property
Aleksey Vasenev margtu-f...@ya.ru wrote:
---
What Thomas said about commit messages.
Note: I hardly use git-svn or SVN anymore and don't pay attention
to SVN changes.
Some style nitpicks:
@@ -1304,16 +1318,20 @@ sub cmd_create_ignore {
# which git won't track
mkpath([$path]) unless -d $path;
my $ignore = $path . '.gitignore';
- my $s = $props-{'svn:ignore'} or return;
+ my $s = get_svn_ignore($props, 'svn:ignore');
+ my $s_global = get_svn_ignore($props, 'svn:global-ignores');
sub(...) convention isn't consistent with the rest of our Perl code.
Do this instead:
my $s = get_svn_ignore($props, 'svn:ignore');
my $s_global = get_svn_ignore($props, 'svn:global-ignores');
+ $s or $s_global or return;
Precedence should be more explicit:
($s || $s_global) or return;
Likewise for cmd_show_ignore. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/21] path.c: rename vsnpath() to git_vsnpath()
On 16/12/13 17:11, Jonathan Nieder wrote: Duy Nguyen wrote: Ramsay Jones wrote: :-D I renamed this _from_ git_vsnpath() in commit 5b3b8fa2 (path.c: Remove the 'git_' prefix from a file scope function, 04-09-2012), because ... well it's a file scope function! (i.e. the git_ prefix implies greater than file scope). I'm not very good at naming things, so ... [...] OK I go with this. I think it makes sense vsnpath - do_git_path I think this renaming would be still losing clarity --- it loses the information that this is the vsnprintf-like variant of git_path. Do we actually have a convention that functions with git_ prefix should be global? Hmm, probably not no. However, any symbol that starts with git_ positively screams global symbol to me. Maybe, I just need to close my ears. ;-) I didn't intend to provoke so much discussion. I was simply pointing out that this symbol had already been renamed, in the exact opposite direction, once before. Please just ignore me. ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log --no-walk --tags produces strange result for certain user
On Mon, Dec 16, 2013 at 03:52:35PM +0400, Kirill Likhodedov wrote: Hi everybody, I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray To reproduce: # git clone https://github.com/spray/spray # cd spray # git log --no-walk --tags --pretty=%H %d --decorate=full | tail -3 3273edafcd9f9701d62e061c5257c0a09e2e1fb7 (tag: refs/tags/v0.8.0-RC1) ff3a2946bc54da76ddb47e82c81419cc7ae3db6b (tag: refs/tags/v0.7.0) 8b4043428b90b7f45b7241b3c2c032cf785479ce So here the last hash doesn't have a decoration. This looks like a bug: vauxhall ok % git describe 8b4043428b90b7f45b7241b3c2c032cf785479ce v0.5.0 I'm looking at it. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH v4 2/3] diff: Let git diff -O read orderfile from any file, fail properly
On Mon, Dec 16, 2013 at 4:09 PM, Junio C Hamano gits...@pobox.com wrote: Samuel Bronson naes...@gmail.com writes: +test_expect_success 'unreadable orderfile' ' + touch unreadable_file + chmod -r unreadable_file - this test probably needs restricted to people with sane filesystems; I think POSIXPERM prerequisite and also SANITY prerequisite are needed, at least. Hmm, yeah, you've got a point; now that I think more carefully, the most FAT can do is something like chmod -w, nothing with the r permissions. Oops. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] log: properly handle decorations with chained tags
git log did not correctly handle decorations when a tag object referenced
another tag object that was no longer a ref, such as when the second tag was
deleted. The commit would not be decorated correctly because parse_object had
not been called on the second tag and therefore its tagged field had not been
filled in, resulting in none of the tags being associated with the relevant
commit.
Call parse_object to fill in this field if it is absent so that the chain of
tags can be dereferenced and the commit can be properly decorated. Include
tests as well to prevent future regressions.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
log-tree.c| 13 ++---
t/t4205-log-pretty-formats.sh | 15 +++
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 642faff..a6b60b7 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -131,9 +131,16 @@ static int add_ref_decoration(const char *refname, const
unsigned char *sha1, in
refname = prettify_refname(refname);
add_name_decoration(type, refname, obj);
while (obj-type == OBJ_TAG) {
- obj = ((struct tag *)obj)-tagged;
- if (!obj)
- break;
+ struct object *tagged = ((struct tag *)obj)-tagged;
+ if (!tagged) {
+ obj = parse_object(obj-sha1);
+ if (!obj)
+ break;
+ tagged = ((struct tag *)obj)-tagged;
+ if (!tagged)
+ break;
+ }
+ obj = tagged;
add_name_decoration(DECORATION_REF_TAG, refname, obj);
}
return 0;
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index fb00041..2a6278b 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -310,4 +310,19 @@ EOF
test_cmp expected actual
'
+test_expect_success 'log decoration properly follows tag chain' '
+ git tag -a tag1 -m tag1
+ git tag -a tag2 -m tag2 tag1
+ git tag -d tag1
+ git commit --amend -m shorter
+ git log --no-walk --tags --pretty=%H %d --decorate=full actual
+ cat EOF expected
+6a908c10688b2503073c39c9ba26322c73902bb5 (tag: refs/tags/tag2)
+9f716384d92283fb915a4eee5073f030638e05f9 (tag: refs/tags/message-one)
+b87e4cccdb77336ea79d89224737be7ea8e95367 (tag: refs/tags/message-two)
+EOF
+ sort actual actual1
+ test_cmp expected actual1
+'
+
test_done
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] diff: Let git diff -O read orderfile from any file, fail properly
On Mon, Dec 16, 2013 at 4:32 PM, Junio C Hamano gits...@pobox.com wrote: Samuel Bronson naes...@gmail.com writes: for i in 1 2 do test_expect_success orderfile using option ($i) ' git diff -Oorder_file_$i --name-only HEAD^..HEAD actual test_cmp expect_$i actual ' This funny indentation in the previous step needs to be fixed, and the added block below should match. Even though this results in oddly-indented --verbose output? + rm -f order_fifo + mkfifo order_fifo + cat order_file_$i order_fifo + git diff -O order_fifo --name-only HEAD^..HEAD actual I think this part can be racy depending on which between cat and git diff are scheduled first, no? Try running this test under load and I think you will see it deadlocked. Besides, the above breaks chain; even if mkfifo breaks (hence not allowing cat to run), git diff will go ahead and run, no? Hmm. Well, what I really wanted to put here was a process substitution: git diff -O (cat order_file_$i) --name-only HEAD^..HEAD actual but I did not see this feature listed in the dash(1) manpage, so I assumed it wasn't allowed by POSIX. And, having looked, I indeed don't see it mentioned in POSIX either. I'm not terribly surprised that I screwed up the translation to FIFOs; how would I really want to do it? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Just like it...
Die Nike Breeze maximale Leitungs ihre endlosen Treck voraus zu bleiben , wenn der Kalender Flips, mit dem nächsten Modell innerhalb Lineup auf Ihre Umwelt Nike Max + 2014. Unnötig zu sagen, es ist ein bisschen früh in der Videospiel sogar zu sprechen über Design auf , so dass vollständig ist , dass an dieser Stelle verfügbar sind, Katalog -Scans. Der Air Max thea gewebt Paket verwendet elektrische Schattierungen leuchten - als Teil einer tief - Brise Sohlen dann Crash - Polsterung im Inneren Akzente feiern, dass die Strahlungstypeinfach gefolgt von städtischen Läufer. schließlich eine obere gewebt sind für eine komfortable Spiel angewendet . Nach einer Vielzahl von Teaser, gestalten? Nike offiziell die Veröffentlichung des kommenden Zement -Paket über ein paar einzigartige Farbvarianten zu erklären , wenn es um maximale Nike Air leichter geht. Später ist erhältlich in gleichzeitig den grauen Colorway unter gelben , rosa und lila Akzenten und einem zweitens in lila durch Leicht grün, grau zusätzlich teal Akzenten, einem gemusterten Wildleder Gebäude sowie Stoff rauscht Nike Basketballschuhe http://www.onlinenikesneakersde.com/ bieten die Packung zusätzliche Persönlichkeit. Als Teil des 2006 Nike dann Hong Kong Streetwear Marke , Klumpen , verbreitet genau das, was wäre wohl das Beste gesucht - Atmosphäre , wenn ein Max ist, als Teil der neuen Speicher. Die Nike Max Atmosphäre ein NL Premium- CLOT habe es Hinweise aus jeder China-Gewohnheiten auch klassische China Medikament , Absicherung Wildleder, Straußen Epidermis und / oder Schlangenhaut durch offensichtliche Kunststoff toeboxes für besondere , Hals brech Silhouette. Acht langjährige Zukunft , Nike und gleichzeitig auch CLOT sind bereit zusammen mit seinem Stock zu - nach oben - ihre Umwelt Nike Max ein CLOT SP - was bietet Oriental Inspirationen eines ursprünglichen Revisionen zusätzlich alle mit Hyperfuse in einer Wasch , moderne Farbgebung . Das minimal - Version Kicks Komponente grau sowie Licht verschmolzen Oberteil , gesprenkelt Sohlen und einfach den Hinweis auf umweltfreundliche , während Einlagen , transparente Laufsohle verweisen Druckpegel Punkt beeinflussten Kunstwerk des Vorgängers . Ein Camo Tape- Pack- Eigenschaften Paar Nike bevorzugten Alltags Lehrer Silhouetten, viele auch 95 Airmax neunzig . Die 1990er Jahre -inspirierten Designs hatten jede sew - kostenlos -Mesh- Obermaterial Nubukleder sowie durch eine einfache, aber trifft Camouflage-Muster entworfen , innen Klangfarben über schwarz gefärbt und grau. Diese besondere Schuhe haben immer noch nicht aus, aber wirklich der einzige Ort, an dem ich zufällig in der Lage sein , sie zu finden , wo alles war holland Globus nike corp positioniert sind, könnte dies schnell planen zu verkaufen gewesen . Kobe 8 Schuhe zu verkaufen , 100 Prozent Viele authentische Nike + -Umgebung maximal 2014 fließt Schuhe bietet höchste Dämpfung und Komfort mit perfekter Effizienz und Pracht . Hyperfuse -Obermaterial mit Flywire dynamische Technologien bringt leichte, bequeme Hilfe, innersleeve Kerb dann atmungsaktives Mesh bieten nahtlose Vorteile. Cushion -Zwischensohle sowie eine komplette Ausmaß Max - Atmosphäre Gerät erstellen weiche Dämpfung für die Top- Reise. Flexkerben inspirieren pro seidige Bewegung. Mit einen fertigen vulkanisierte Zwischensohle für Sicherheit auch beliebt bemerkbar Umwelt -Einheit von Nike in der Ferse bis zu den Sicherheitsmaßnahmen betreffen , sind sie ein Muss ist , um Ihre echte Verbesserung der Sneakerhead -Set. Weitere Funktionen setzen : flach gewebt, Schnürsenkel, hergestellt Overlays über die Unterstützung , die Nike Free 5.0 Herren http://www.onlinenikesneakersde.com/nike-free-5-0 Fuß- Kragen, Nike Branding über die Zunge, Ferse Rand und auch positive Klang Nähen ganz abgefedert. - Nike Dunk Damen Nike Dunk Herren -- View this message in context: http://git.661346.n2.nabble.com/Just-like-it-tp7600911.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
