Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
Hm, being one day offline and there are lots of ideas and new patches, I like that. I run these test under msys and cygwin on latest pu (a3dc223ff234481356c): ./t0001-init.sh ./t0004-unwritable.sh ./t0061-run-command.sh ./t0070-fundamental.sh ./t1004-read-tree-m-u-wf.sh ./t1300-repo-config.sh ./t1301-shared-repo.sh ./t1308-config-set.sh ./t2026-prune-linked-checkouts.sh ./t3600-rm.sh ./t3700-add.sh ./t4039-diff-assume-unchanged.sh ./t4056-diff-order.sh ./t5537-fetch-shallow.sh ./t7300-clean.sh ./t7503-pre-commit-hook.sh ./t7504-commit-msg-hook.sh ./t7508-status.sh (msys passes or skips all) Without digging further, these fail on my cygwin: $ grep not ok p.txt not ok 29 - init notices EPERM not ok 2 - write-tree should notice unwritable repository not ok 3 - commit should notice unwritable repository not ok 4 - update-index should notice unwritable repository not ok 5 - add should notice unwritable repository not ok 3 - mktemp to unwritable directory prints filename not ok 13 - funny symlink in work tree, un-unlink-able not ok 23 - proper error on non-accessible files not ok 4 - prune directories with unreadable gitdir not ok 15 - Test that git rm -f fails if its rm fails not ok 16 - When the rm in git rm -f fails, it should not remove the file from the index not ok 20 - Re-add foo and baz not ok 21 - Modify foo -- rm should refuse not ok 22 - Modified foo -- rm -f should work not ok 23 - Re-add foo and baz for HEAD tests not ok 24 - foo is different in index from HEAD -- rm should refuse not ok 23 - git add should fail atomically upon an unreadable file not ok 24 - git add --ignore-errors not ok 25 - git add (add.ignore-errors) not ok 26 - git add (add.ignore-errors = false) not ok 27 - --no-ignore-errors overrides config not ok 4 - unreadable orderfile not ok 28 - removal failure not ok 61 - status succeeds in a read-only repository If we remove POSIXPERM from CYGWIN, all tests pass ;-) but some are skipped : ok 26 - init creates a new deep directory (umask vs. shared) ok 3 - run_command reports EACCES ok 4 - unreadable directory in PATH ok 113 - preserves existing permissions ok 2 - shared=1 does not clear bits preset by umask 002 ok 3 - shared=1 does not clear bits preset by umask 022 ok 5 - update-server-info honors core.sharedRepository ok 6 - shared = 0660 (r--r-) ro ok 7 - shared = 0660 (rw-rw) rw ok 8 - shared = 0640 (r--r-) ro ok 9 - shared = 0640 (rw-r-) rw ok 10 - shared = 0600 (r) ro ok 11 - shared = 0600 (rw---) rw ok 12 - shared = 0666 (r--r--r--) ro ok 13 - shared = 0666 (rw-rw-rw-) rw ok 14 - shared = 0664 (r--r--r--) ro ok 15 - shared = 0664 (rw-rw-r--) rw ok 16 - info/refs respects umask in unshared repo ok 17 - git reflog expire honors core.sharedRepository ok 18 - forced modes ok 4 - find-copies-harder is not confused by mode bits ok 10 - shallow fetch from a read-only repo ok 32 - git clean -d with an unreadable empty directory ok 7 - with non-executable hook ok 8 - --no-verify with non-executable hook ok 13 - with non-executable hook ok 14 - with non-executable hook (editor) ok 15 - --no-verify with non-executable hook ok 16 - --no-verify with non-executable hook (editor) I'm not sure what is the best way forward, it seems as if CYGIN is half POSIX now. -- 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] git-p4: support exclude in 'git p4 sync'
The git-p4 'clone' subcommand has long had the option to specify parts of the repo to be excluded, on the command line. But this has not been present in 'sync', which makes it less than useful: as soon as you do a sync, the excluded parts start being repopulated as those directories are changed. (You can achieve the same effect by using a client specification to do the exclusion, but that's then an extra step). The code for doing the exclusion is actually all present in the base 'P4Sync' class: this change turns that on by moving the definition of the command-line switch. It also updates the documentation and adds a test-case. Thanks, Luke And yes, I'm back to using version control systems other than git :-( Luke Diamand (1): git-p4: support excluding paths on sync Documentation/git-p4.txt |6 ++-- git-p4.py | 18 ++-- t/t9817-git-p4-exclude.sh | 71 + 3 files changed, 83 insertions(+), 12 deletions(-) create mode 100755 t/t9817-git-p4-exclude.sh -- 1.7.10.4 -- 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] git-p4: support excluding paths on sync
The clone subcommand has long had support for excluding subdirectories, but sync has not. This is a nuisance, since as soon as you do a sync, any changed files that were initially excluded start showing up. Move the exclude command-line option into the parent class; the actual behavior was already present there so it simply had to be exposed. Signed-off-by: Luke Diamand l...@diamand.org --- Documentation/git-p4.txt |6 ++-- git-p4.py | 18 ++-- t/t9817-git-p4-exclude.sh | 71 + 3 files changed, 83 insertions(+), 12 deletions(-) create mode 100755 t/t9817-git-p4-exclude.sh diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 6ab5f94..a1664b9 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -241,6 +241,9 @@ Git repository: Use a client spec to find the list of interesting files in p4. See the CLIENT SPEC section below. +-/ path:: + Exclude selected depot paths when cloning or syncing. + Clone options ~ These options can be used in an initial 'clone', along with the 'sync' @@ -254,9 +257,6 @@ options described above. --bare:: Perform a bare clone. See linkgit:git-clone[1]. --/ path:: - Exclude selected depot paths when cloning. - Submit options ~~ These options can be used to modify 'git p4 submit' behavior. diff --git a/git-p4.py b/git-p4.py index ff132b2..38029a4 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1916,6 +1916,9 @@ class P4Sync(Command, P4UserMap): help=Keep entire BRANCH/DIR/SUBDIR prefix during import), optparse.make_option(--use-client-spec, dest=useClientSpec, action='store_true', help=Only sync files that are included in the Perforce Client Spec) +optparse.make_option(-/, dest=cloneExclude, + action=append, type=string, + help=exclude depot path), ] self.description = Imports from Perforce into a git repository.\n example: @@ -1950,6 +1953,12 @@ class P4Sync(Command, P4UserMap): if gitConfig(git-p4.syncFromOrigin) == false: self.syncWithOrigin = False +# This is required for the append cloneExclude action +def ensure_value(self, attr, value): +if not hasattr(self, attr) or getattr(self, attr) is None: +setattr(self, attr, value) +return getattr(self, attr) + # Force a checkpoint in fast-import and wait for it to finish def checkpoint(self): self.gitStream.write(checkpoint\n\n) @@ -3101,9 +3110,6 @@ class P4Clone(P4Sync): optparse.make_option(--destination, dest=cloneDestination, action='store', default=None, help=where to leave result of the clone), -optparse.make_option(-/, dest=cloneExclude, - action=append, type=string, - help=exclude depot path), optparse.make_option(--bare, dest=cloneBare, action=store_true, default=False), ] @@ -3111,12 +3117,6 @@ class P4Clone(P4Sync): self.needsGit = False self.cloneBare = False -# This is required for the append cloneExclude action -def ensure_value(self, attr, value): -if not hasattr(self, attr) or getattr(self, attr) is None: -setattr(self, attr, value) -return getattr(self, attr) - def defaultDestination(self, args): ## TODO: use common prefix of args? depotPath = args[0] diff --git a/t/t9817-git-p4-exclude.sh b/t/t9817-git-p4-exclude.sh new file mode 100755 index 000..aac568e --- /dev/null +++ b/t/t9817-git-p4-exclude.sh @@ -0,0 +1,71 @@ +#!/bin/sh + +test_description='git p4 tests for excluded paths during clone and sync' + +. ./lib-git-p4.sh + +test_expect_success 'start p4d' ' + start_p4d +' + +# Create a repo with the structure: +# +#//depot/wanted/foo +#//depot/discard/foo +# +# Check that we can exclude a subdirectory with both +# clone and sync operations. + +test_expect_success 'create exclude repo' ' + ( + cd $cli + mkdir -p wanted discard + echo wanted wanted/foo + echo discard discard/foo + p4 add wanted/foo discard/foo + p4 submit -d initial revision + ) +' + +test_expect_success 'check the repo was created correctly' ' + test_when_finished cleanup_git + git p4 clone --dest=$git //depot/...@all + ( + cd $git + test_path_is_file wanted/foo + test_path_is_file discard/foo + ) +' + +test_expect_success 'clone, excluding part of repo' ' + test_when_finished cleanup_git + git p4 clone
[PATCH] .clang-format: introduce the use of clang-format
Instead of manually eyeballing style in reviews, just ask all contributors to run their patches through [git-]clang-format. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- The idea is to introduce the community to this new toy I found called clang-format. Whether or not it's actually going to be used doesn't bother me too much. I'm not 100% sure of the style, but I'll leave you to tweak that using http://clang.llvm.org/docs/ClangFormatStyleOptions.html The current code isn't terribly conformant, but I suppose that'll change with time. .clang-format | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 .clang-format diff --git a/.clang-format b/.clang-format new file mode 100644 index 000..63a53e0 --- /dev/null +++ b/.clang-format @@ -0,0 +1,7 @@ +BasedOnStyle: LLVM +IndentWidth: 8 +UseTab: Always +BreakBeforeBraces: Linux +AllowShortBlocksOnASingleLine: false +AllowShortIfStatementsOnASingleLine: false +IndentCaseLabels: false \ No newline at end of file -- 2.2.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] Documentation/git-branch.txt: add short option to git branch synopsis
s/short/long/ Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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
.gitattributes on branch behaves unexpected. Should it be more stateless?
Hi, I am asking myself if git and .gitattributes should be more stateless? i.e. whatever you have done before is irrelevant, when you reach status XYZ with your git repo, it is EXACTLY and BINARY the same all the time and everywhere. It took some time for me to figure out, that depending on HOW you clone, the resulting local repo may differ. I did not expect this. I assumed that when I clone, it is a clone (meaning: 100% identical). And that the things I have done in my local repo before, don't have any relevance at all. ** How to reproduce ** 1) create a repo, add a file with LF ending, add a .gitattributes telling git to do a CRLF conversion 2) clone the repo 3) on brach development, change .gitattributes to LF 4) clone again 5) clone again, directly onto the branch development (git clone -b) ** Expected result, (I) ** clone 2) and original repo 1) are bytewise identical ** Actual result (I) ** clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF as I have been warned before, I am (more or less) fine/OK with this ** Expected result, (II) ** - clone without -b (4) and clone with -b (5) are bytewise identical - I would have expected, that whatever I do, as soon as I have a clone and I am on branch development, my file should be LF - I would have expected, that HOW you clone is irrelevant ** Actual result (II) ** without -b (4) I have a CRLF file on my disk. with -b (5) I have a LF file on my disk. The clones are not bytewise indentical. It appears as if the .gitattributes in branch development does not have any reliable effect. A potential solution might be be that - checkout - commit (a modified .gitattribues) - further git commands do change the files in the local repo. As of now my understanding is that this is not how .gitattributes (or .gitignore) are designed. .gitattributes only has influence on pushing/fetching. I don't know if and which side effects would occur if this design would be changed. Hence I am glad to hear any feedback on the issue described above. And yes, I agree that this is a minor issue and that all .gitattribute things are kind of edge cases. Thanks and with best regards, Max 1) mkdir git-bug-or-feature cd git-bug-or-feature git init echo foo.bar eol=crlf .gitattributes echo hello world foo.bar git add . git commit -m now crlf # [master (root-commit) 7f3f6b0] now crlf # warning: LF will be replaced by CRLF in foo.bar. # The file will have its original line endings in your working directory. file foo.bar # foo.bar: ASCII text cd .. 2) git clone git-bug-or-feature git-bug-or-feature_clone cd git-bug-or-feature_clone file foo.bar # foo.bar: ASCII text, with CRLF line terminators cd .. rm -rf git-bug-or-feature_clone 3) cd git-bug-or-feature git branch development git checkout development echo foo.bar eol=lf .gitattributes git add . git commit -m now lf on branch development file foo.bar # foo.bar: ASCII text git checkout master file foo.bar # foo.bar: ASCII text cd .. 4) git clone git-bug-or-feature git-bug-or-feature_clone cd git-bug-or-feature_clone file foo.bar -- 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
zsh completion for `git push origin --delete`
The man for `--delete` says only refs on the remote repo are affected. Then, the auto-completion in zsh shall not return local refs. ``` $ git branch -a master * tmp remotes/origin/master remotes/origin/tmp $ git push origin --delete tab FETCH_HEAD HEAD master ORIG_HEAD origin/master origin/tmp tmp ``` I feel hitting tab shall only return `master` and `tmp`, which are the valid input `--delete` option. git version 2.2.2 -- Best Regards Yours faithfully Albert Netymk -- 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] branch: add support for --dry-run option
From: Alexander Kuleshov kuleshovm...@gmail.com This patch adds support -d/--dry-run option for branch(es) deletion. If -d/--dry-run option passed to git branch -d branch..., branch(es) surely s|-d/--dry-run|-n/--dry-run| -n is the short version of --dryrun. -d is already in use. will not be removed, instead just print list of branches that are to be removed. [...] -- 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: .gitattributes on branch behaves unexpected. Should it be more stateless?
Hi, I am asking myself if git and .gitattributes should be more stateless? i.e. whatever you have done before is irrelevant, when you reach status XYZ with your git repo, it is EXACTLY and BINARY the same all the time and everywhere. It took some time for me to figure out, that depending on HOW you clone, the resulting local repo may differ. I did not expect this. I assumed that when I clone, it is a clone (meaning: 100% identical). And that the things I have done in my local repo before, don't have any relevance at all. You don't say which parts you believe should be identical, nor why. Internally Git can represent its object store in many ways based on some objects being 'loose' and some objects being 'packed'. However both styles of representation are of the same base objects and their contents. Then we have external OS representation, in particular the end of line representations between the three main OS types Win/Mac/'nix. Git gives _you_ the ability the use any of these representations for the same base objects. Thus the object file with text Hello World/EOL/Goodbye World will have three different binary representations once you export them to the selected file system type (according to you .gitattributes settings). If you always select LF endings for text files (both on the way in and on the way out of the repo), then you will get identical files on the different clones. Git has many settings for personalisation. Does that help? ** How to reproduce ** 1) create a repo, add a file with LF ending, add a .gitattributes telling git to do a CRLF conversion 2) clone the repo 3) on brach development, change .gitattributes to LF 4) clone again 5) clone again, directly onto the branch development (git clone -b) ** Expected result, (I) ** clone 2) and original repo 1) are bytewise identical ** Actual result (I) ** clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF as I have been warned before, I am (more or less) fine/OK with this ** Expected result, (II) ** - clone without -b (4) and clone with -b (5) are bytewise identical - I would have expected, that whatever I do, as soon as I have a clone and I am on branch development, my file should be LF - I would have expected, that HOW you clone is irrelevant ** Actual result (II) ** without -b (4) I have a CRLF file on my disk. with -b (5) I have a LF file on my disk. The clones are not bytewise indentical. It appears as if the .gitattributes in branch development does not have any reliable effect. A potential solution might be be that - checkout - commit (a modified .gitattribues) - further git commands do change the files in the local repo. As of now my understanding is that this is not how .gitattributes (or .gitignore) are designed. .gitattributes only has influence on pushing/fetching. I don't know if and which side effects would occur if this design would be changed. Hence I am glad to hear any feedback on the issue described above. And yes, I agree that this is a minor issue and that all .gitattribute things are kind of edge cases. Thanks and with best regards, Max 1) mkdir git-bug-or-feature cd git-bug-or-feature git init echo foo.bar eol=crlf .gitattributes echo hello world foo.bar git add . git commit -m now crlf # [master (root-commit) 7f3f6b0] now crlf # warning: LF will be replaced by CRLF in foo.bar. # The file will have its original line endings in your working directory. file foo.bar # foo.bar: ASCII text cd .. 2) git clone git-bug-or-feature git-bug-or-feature_clone cd git-bug-or-feature_clone file foo.bar # foo.bar: ASCII text, with CRLF line terminators cd .. rm -rf git-bug-or-feature_clone 3) cd git-bug-or-feature git branch development git checkout development echo foo.bar eol=lf .gitattributes git add . git commit -m now lf on branch development file foo.bar # foo.bar: ASCII text git checkout master file foo.bar # foo.bar: ASCII text cd .. 4) git clone git-bug-or-feature git-bug-or-feature_clone cd git-bug-or-feature_clone file foo.bar -- 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
[PATCH v2] Documentation/git-branch.txt: add long options to git branch synopsis
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-branch.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 311b336..722f865 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -8,7 +8,7 @@ git-branch - List, create, or delete branches SYNOPSIS [verse] -'git branch' [--color[=when] | --no-color] [-r | -a] +'git branch' [--color[=when] | --no-color] [(-r|--remotes) | (-a|--all)] [--list] [-v [--abbrev=length | --no-abbrev]] [--column[=options] | --no-column] [(--merged | --no-merged | --contains) [commit]] [pattern...] -- 2.3.0.rc0.286.ga3dc223.dirty -- 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] branch: add support for --dry-run option
This patch adds support -n/--dry-run option for branch(es) deletion.
If -n/--dry-run option passed to git branch -d branch..., branch(es)
will not be removed, instead just print list of branches that are
to be removed.
For example:
$ git branch
a
b
c
* master
$ git branch -d -n a b c
delete branch 'a' (261c0d1)
delete branch 'b' (261c0d1)
delete branch 'c' (261c0d1)
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
Documentation/git-branch.txt | 11 +--
builtin/branch.c | 13 +
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 311b336..32ea581 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -16,7 +16,7 @@ SYNOPSIS
'git branch' (--set-upstream-to=upstream | -u upstream) [branchname]
'git branch' --unset-upstream [branchname]
'git branch' (-m | -M) [oldbranch] newbranch
-'git branch' (-d | -D) [-r] branchname...
+'git branch' (-d | -D) [--dry-run | -n] [-r] branchname...
'git branch' --edit-description [branchname]
DESCRIPTION
@@ -63,7 +63,9 @@ to happen.
With a `-d` or `-D` option, `branchname` will be deleted. You may
specify more than one branch for deletion. If the branch currently
-has a reflog then the reflog will also be deleted.
+has a reflog then the reflog will also be deleted. If passed `-n` or
+`--dry-run` option, branch(es) will be not removed, but show a list of
+branches that are to be removed.
Use `-r` together with `-d` to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
@@ -83,6 +85,11 @@ OPTIONS
-D::
Delete a branch irrespective of its merged status.
+-n::
+--dry-run::
+ Don't remove the branch(es), but show a list of branches that are
+ to be removed.
+
-l::
--create-reflog::
Create the branch's reflog. This activates recording of
diff --git a/builtin/branch.c b/builtin/branch.c
index d8949cb..4a35a2f 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -61,6 +61,7 @@ static unsigned char merge_filter_ref[20];
static struct string_list output = STRING_LIST_INIT_DUP;
static unsigned int colopts;
+static int branch_delete_show_only;
static int parse_branch_color_slot(const char *slot)
{
@@ -255,6 +256,17 @@ static int delete_branches(int argc, const char **argv,
int force, int kinds,
continue;
}
+ if (branch_delete_show_only) {
+ printf(remote_branch
+ ? _(delete remote branch '%s' (%s)\n)
+ : _(delete branch '%s' (%s)\n),
+ bname.buf,
+ (flags REF_ISBROKEN) ? broken
+ : (flags REF_ISSYMREF) ? target
+ : find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ continue;
+ }
+
if (delete_ref(name, sha1, REF_NODEREF)) {
error(remote_branch
? _(Error deleting remote branch '%s')
@@ -840,6 +852,7 @@ int cmd_branch(int argc, const char **argv, const char
*prefix)
REF_REMOTE_BRANCH | REF_LOCAL_BRANCH),
OPT_BIT('d', delete, delete, N_(delete fully merged
branch), 1),
OPT_BIT('D', NULL, delete, N_(delete branch (even if not
merged)), 2),
+ OPT__DRY_RUN(branch_delete_show_only, N_(dry run)),
OPT_BIT('m', move, rename, N_(move/rename a branch and its
reflog), 1),
OPT_BIT('M', NULL, rename, N_(move/rename a branch, even if
target exists), 2),
OPT_BOOL(0, list, list, N_(list branch names)),
--
2.3.0.rc0.286.ga3dc223.dirty
--
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] l10n: de.po: translate 13 new messages
Am 16. Januar 2015 um 23:31 schrieb phillip phillip.sze...@gmail.com: looks good! Thanks for review! -- 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
