[PATCH v3 8/9] t5521: test --dry-run does not make any changes
Test that when --dry-run is provided to git-pull, it does not make any changes, namely: * --dry-run gets passed to git-fetch, so no FETCH_HEAD will be created and no refs will be fetched. * The index and work tree will not be modified. Signed-off-by: Paul Tan pyoka...@gmail.com --- t/t5521-pull-options.sh | 13 + 1 file changed, 13 insertions(+) diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh index 453aba5..37d6db6 100755 --- a/t/t5521-pull-options.sh +++ b/t/t5521-pull-options.sh @@ -117,4 +117,17 @@ test_expect_success 'git pull --all' ' ) ' +test_expect_success 'git pull --dry-run' ' + test_when_finished rm -rf clonedry + git init clonedry + ( + cd clonedry + git pull --dry-run ../parent + test_path_is_missing .git/FETCH_HEAD + test_path_is_missing .git/refs/heads/master + test_path_is_missing .git/index + test_path_is_missing file + ) +' + test_done -- 2.1.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 v3 0/9] Improve git-pull test coverage
This is a re-roll of [1]. This series depends on jc/merge. This patch series improves test coverage of git-pull.sh, and is part of my GSoC project to rewrite git-pull into a builtin. Improving test coverage helps to prevent regressions that could occur due to the rewrite. This re-roll includes the following changes across all patches: * Added clean-up patch to fix file content comparisons in t5520 * All file content comparisons are quoted to prevent word splitting and use verbose() to provide better error messages. * Style: References to commits are standardized with their summary and date. * Failing tests have been removed. This series will be solely used to extend test coverage of already working functionality. Bugs will be fixed in their own patch series'. * Style: Instead of redirecting stderr to a file named out, redirect it to a file named err. Thanks Eric, Torsten, Junio, Stefan, Dscho and Johannes for your reviews last round. [1] http://thread.gmane.org/gmane.comp.version-control.git/268510/ Paul Tan (9): t5520: fixup file contents comparisons t5520: ensure origin refs are updated t5520: test no merge candidates cases t5520: test for failure if index has unresolved entries t5520: test work tree fast-forward when fetch updates head t5520: test --rebase with multiple branches t5520: test --rebase failure on unborn branch with index t5521: test --dry-run does not make any changes t5520: check reflog action in fast-forward merge t/t5520-pull.sh | 214 ++-- t/t5521-pull-options.sh | 13 +++ 2 files changed, 184 insertions(+), 43 deletions(-) -- 2.1.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
Re: cmd_struct
On Wed, May 13, 2015 at 4:10 PM, Thiago Farina tfrans...@gmail.com wrote: Would be too churn/noise (at this point) to rename cmd_struct to builtin_cmd? The name has served us well, I do not see a compelling reason to change it to anything else, and I suspect the name stayed unchanged because nobody else found such a reason, either. So... if you are unwilling to make a compelling case telling us why the current name does not work, I do not think it is likely that anybody finds such a change necessary, welcome, or even tolerable. -- 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: HEAD - branch decoration doesn't work with --decorate=full
Michael Haggerty mhag...@alum.mit.edu writes:
The new-style HEAD - branch style decoration doesn't work when
--decorate=full is used:
$ bin-wrappers/git show --oneline --decorate
c518059 (HEAD - master, gitster/master) Merge branch 'maint'
$ bin-wrappers/git show --oneline --decorate=full
c518059 (HEAD, refs/remotes/gitster/master, refs/heads/master) Merge branch
'maint'
I would have expected the second invocation to show HEAD -
refs/heads/master.
Was that an oversight or a conscious decision?
I actually think this ultimately comes from a poor design of the
name-decorations infrastructure. The program is expected to call
load_ref_decorations() only once and make the choice between the
full/short at that point, which is passed to add_ref_decoration() to
record either 'refs/heads/master' or 'master' in the singleton
name_decoration decoration. But it does not store which one was
chosen by the caller of load_ref_decorations() anywhere in the
subsystem.
When current_pointed_by_HEAD() wants to see if decorations on an
object, e.g. 'master', matches what 'HEAD' resolves to, it cannot
tell if the original set-up was done for the full decoration, and
the current code just assumes (without even realizing that it is
making that assumption) the decoration must have been set up for the
short ones.
Perhaps something like this, but I am not committing it without
tests or a proper log messge.
I moved static loaded outside as it is in the same category as the
global name-decoration and decoration-flags, i.e. to be initialised
once at the beginning to a fixed setting and then be used with that
setting.
log-tree.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 2c1ed0f..92259bc 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -13,6 +13,8 @@
#include line-log.h
static struct decoration name_decoration = { object names };
+static int decoration_loaded;
+static int decoration_flags;
static char decoration_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RESET,
@@ -146,9 +148,9 @@ static int add_graft_decoration(const struct commit_graft
*graft, void *cb_data)
void load_ref_decorations(int flags)
{
- static int loaded;
- if (!loaded) {
- loaded = 1;
+ if (!decoration_loaded) {
+ decoration_loaded = 1;
+ decoration_flags = flags;
for_each_ref(add_ref_decoration, flags);
head_ref(add_ref_decoration, flags);
for_each_commit_graft(add_graft_decoration, NULL);
@@ -196,8 +198,19 @@ static const struct name_decoration
*current_pointed_by_HEAD(const struct name_d
branch_name = resolve_ref_unsafe(HEAD, 0, unused, rru_flags);
if (!(rru_flags REF_ISSYMREF))
return NULL;
- if (!skip_prefix(branch_name, refs/heads/, branch_name))
- return NULL;
+
+ if ((decoration_flags == DECORATE_SHORT_REFS)) {
+ if (!skip_prefix(branch_name, refs/heads/, branch_name))
+ return NULL;
+ } else {
+ /*
+* Each decoration has a refname in full; keep
+* branch_name also in full, but still make sure
+* HEAD is a reasonable ref.
+*/
+ if (!starts_with(branch_name, refs/))
+ return NULL;
+ }
/* OK, do we have that ref in the list? */
for (list = decoration; list; list = list-next)
--
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 2/3] sha1_name: get_sha1_with_context learns to follow symlinks
Wire up get_sha1_with_context to call get_tree_entry_follow_symlinks
when GET_SHA1_FOLLOW_SYMLINKS is passed in flags. G_S_FOLLOW_SYMLINKS
is incompatible with G_S_ONLY_TO_DIE because the diagnosis
that ONLY_TO_DIE triggers does not at present consider symlinks, and
it would be a significant amount of additional code to allow it to
do so.
Signed-off-by: David Turner dtur...@twitter.com
---
cache.h | 20 +---
sha1_name.c | 20 +++-
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/cache.h b/cache.h
index 3d3244b..65505d1 100644
--- a/cache.h
+++ b/cache.h
@@ -922,15 +922,21 @@ struct object_context {
unsigned char tree[20];
char path[PATH_MAX];
unsigned mode;
+ /*
+* symlink_path is only used by get_tree_entry_follow_symlinks,
+* and only for symlinks that point outside the repository.
+*/
+ struct strbuf symlink_path;
};
-#define GET_SHA1_QUIETLY01
-#define GET_SHA1_COMMIT 02
-#define GET_SHA1_COMMITTISH 04
-#define GET_SHA1_TREE 010
-#define GET_SHA1_TREEISH 020
-#define GET_SHA1_BLOB 040
-#define GET_SHA1_ONLY_TO_DIE 04000
+#define GET_SHA1_QUIETLY 01
+#define GET_SHA1_COMMIT02
+#define GET_SHA1_COMMITTISH04
+#define GET_SHA1_TREE 010
+#define GET_SHA1_TREEISH 020
+#define GET_SHA1_BLOB 040
+#define GET_SHA1_FOLLOW_SYMLINKS 0100
+#define GET_SHA1_ONLY_TO_DIE04000
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_commit(const char *str, unsigned char *sha1);
diff --git a/sha1_name.c b/sha1_name.c
index 6d10f05..0c26515 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1434,11 +1434,19 @@ static int get_sha1_with_context_1(const char *name,
new_filename = resolve_relative_path(filename);
if (new_filename)
filename = new_filename;
- ret = get_tree_entry(tree_sha1, filename, sha1,
oc-mode);
- if (ret only_to_die) {
- diagnose_invalid_sha1_path(prefix, filename,
- tree_sha1,
- name, len);
+ if (flags GET_SHA1_FOLLOW_SYMLINKS) {
+ ret = get_tree_entry_follow_symlinks(tree_sha1,
+ filename, sha1, oc-symlink_path,
+ oc-mode);
+ } else {
+ ret = get_tree_entry(tree_sha1, filename,
+sha1, oc-mode);
+ if (ret only_to_die) {
+ diagnose_invalid_sha1_path(prefix,
+ filename,
+ tree_sha1,
+ name, len);
+ }
}
hashcpy(oc-tree, tree_sha1);
strlcpy(oc-path, filename, sizeof(oc-path));
@@ -1469,5 +1477,7 @@ void maybe_die_on_misspelt_object_name(const char *name,
const char *prefix)
int get_sha1_with_context(const char *str, unsigned flags, unsigned char
*sha1, struct object_context *orc)
{
+ if (flags GET_SHA1_FOLLOW_SYMLINKS flags GET_SHA1_ONLY_TO_DIE)
+ die(BUG: incompatible flags for get_sha1_with_context);
return get_sha1_with_context_1(str, flags, NULL, sha1, orc);
}
--
2.0.4.315.gad8727a-twtrsrc
--
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 0/8] asciidoc fixups
On Wed, May 13, 2015 at 09:43:54AM +0200, Johannes Schindelin wrote: I would like to believe that I am included in said group, because we recently switched to use AsciiDoctor in Git for Windows 2.x. In msysGit times, we could not even run AsciiDoc (and neither AsciiDoctor), instead we relied on Junio publishing the artifacts in the git-htmldocs repository. Thanks, I didn't know that. I have a vague feeling that AsciiDoctor is the future of AsciiDoc (certainly the AsciiDoctor folks feel that way), so the more we can keep compatibility, the better. Knowing that you guys are actively using it makes me feel even better about spending time on it. By the way, we have two patches in our fork that are needed here to use Asciidoctor successfully: https://github.com/git-for-windows/git/compare/893292c41%5E...893292c41%5E2 I would like to put them on top of this patch series. Objections? The first one looks like straight fixes. The second looks rather nasty, and makes the AsciiDoc output worse. I don't have a better solution offhand, 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: Git: How to keep multiple bare repos in sync?
not remote sync.
We have three teams to participate in the same project, and is located in
different places. Bandwidth that between the two of our teams is not enough.
Three teams have their own git server. Like this kind of situation, how should
handle?
chenxitwo
From: Junio C Hamano
Date: 2015-05-13 12:37
To: chenxitwo
CC: git
Subject: Re: Git: How to keep multiple bare repos in sync?
chenxitwo chenxi...@126.com writes:
There are three git server(bare repos), but i don't know to solve the
problem that how to keep these git servers in sync.
rsync?
The problem is under-specified. Is there one of them that is
authoritative and that the other ones should match its progress?
If so, perhaps push from the authoritative one to the other two
with push --mirror (or have the other ones fetch --mirror)?
If you are allowing people to push into any of them randomly,
then there is no general solution. If I push an update to 'master'
of instance A while you update the same 'master' branch of instance
B, somebody has to reconcile the divergence between the two by
creating a merge, and that can possibly conflict, needing human
intervention to
resolve.N�Р骒r��yb�X�肚�v�^�)藓{.n�+丕��≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f
[PATCHv2 1/2] git-p4: add failing test for P4EDITOR handling
Add test case that git-p4 handles a setting of P4EDITOR that takes arguments, e.g. gvim -f Signed-off-by: Luke Diamand l...@diamand.org Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t9820-git-p4-editor-handling.sh | 38 ++ 1 file changed, 38 insertions(+) create mode 100755 t/t9820-git-p4-editor-handling.sh diff --git a/t/t9820-git-p4-editor-handling.sh b/t/t9820-git-p4-editor-handling.sh new file mode 100755 index 000..e0a3c52 --- /dev/null +++ b/t/t9820-git-p4-editor-handling.sh @@ -0,0 +1,38 @@ +#!/bin/sh + +test_description='git p4 handling of EDITOR' + +. ./lib-git-p4.sh + +test_expect_success 'start p4d' ' + start_p4d +' + +test_expect_success 'init depot' ' + ( + cd $cli + echo file1 file1 + p4 add file1 + p4 submit -d file1 + ) +' + +test_expect_failure 'EDITOR has options' ' +# Check that the P4EDITOR argument can be given command-line +# options, which git-p4 will then pass through to the shell. + git p4 clone --dest=$git //depot + test_when_finished cleanup_git + ( + cd $git + echo change file1 + git commit -m change file1 + P4EDITOR=touch \$git/touched\ git p4 submit + test_path_is_file $git/touched + ) +' + +test_expect_success 'kill p4d' ' + kill_p4d +' + +test_done -- 2.4.0.rc3.380.g8e2ddc7 -- 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
[PATCHv2 2/2] git-p4: fix handling of multi-word P4EDITOR
This teaches git-p4 to pass the P4EDITOR variable to the
shell for expansion, so that any command-line arguments are
correctly handled. Without this, git-p4 can only launch the
editor if P4EDITOR is solely the path to the binary, without
any arguments.
This also fixes t9805, which relied on the previous
behaviour.
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Luke Diamand l...@diamand.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-p4.py | 2 +-
t/t9805-git-p4-skip-submit-edit.sh | 2 +-
t/t9820-git-p4-editor-handling.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 41a77e6..ca6bb95 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1248,7 +1248,7 @@ class P4Submit(Command, P4UserMap):
editor = os.environ.get(P4EDITOR)
else:
editor = read_pipe(git var GIT_EDITOR).strip()
-system([editor, template_file])
+system([sh, -c, ('%s $@' % editor), editor, template_file])
# If the file was not saved, prompt to see if this patch should
# be skipped. But skip this verification step if configured so.
diff --git a/t/t9805-git-p4-skip-submit-edit.sh
b/t/t9805-git-p4-skip-submit-edit.sh
index 8931188..5fbf904 100755
--- a/t/t9805-git-p4-skip-submit-edit.sh
+++ b/t/t9805-git-p4-skip-submit-edit.sh
@@ -90,7 +90,7 @@ test_expect_success 'no config, edited' '
cd $git
echo line file1
git commit -a -m change 5
- P4EDITOR=$TRASH_DIRECTORY/ed.sh
+ P4EDITOR=\$TRASH_DIRECTORY/ed.sh\
export P4EDITOR
git p4 submit
p4 changes //depot/... wc
diff --git a/t/t9820-git-p4-editor-handling.sh
b/t/t9820-git-p4-editor-handling.sh
index e0a3c52..c178bd7 100755
--- a/t/t9820-git-p4-editor-handling.sh
+++ b/t/t9820-git-p4-editor-handling.sh
@@ -17,9 +17,9 @@ test_expect_success 'init depot' '
)
'
-test_expect_failure 'EDITOR has options' '
# Check that the P4EDITOR argument can be given command-line
# options, which git-p4 will then pass through to the shell.
+test_expect_success 'EDITOR has options' '
git p4 clone --dest=$git //depot
test_when_finished cleanup_git
(
--
2.4.0.rc3.380.g8e2ddc7
--
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
