Re: git-blame segfault
On Tue, Dec 3, 2013 at 9:45 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: Should be fixed in gcc soon. For the curious, here is the assembler diff (bad vs. good): Cool, Thanks. Good to know this has nothing to do with Git :-) -- 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 1/1] tests: fix gzip with exported GZIP variable in environment
In t/t5000-tar-tree.sh the variable GZIP is used for the command name.
From man gzip:
The environment variable GZIP can hold a set of default options for
gzip. These options are interpreted first and can be overwritten by
explicit command line parameters.
So using any other variable name fixes this.
---
t/t5000-tar-tree.sh | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index c2023b1..01b0ed9 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -25,7 +25,7 @@ commit id embedding:
'
. ./test-lib.sh
-GZIP=${GZIP:-gzip}
+GZIPCMD=${GZIPCMD:-gzip}
GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
@@ -275,27 +275,27 @@ test_expect_success 'only enabled filters are available
remotely' '
test_cmp remote.bar config.bar
'
-if $GZIP --version /dev/null 21; then
- test_set_prereq GZIP
+if $GZIPCMD --version /dev/null 21; then
+ test_set_prereq GZIPCMD
else
say Skipping some tar.gz tests because gzip not found
fi
-test_expect_success GZIP 'git archive --format=tgz' '
+test_expect_success GZIPCMD 'git archive --format=tgz' '
git archive --format=tgz HEAD j.tgz
'
-test_expect_success GZIP 'git archive --format=tar.gz' '
+test_expect_success GZIPCMD 'git archive --format=tar.gz' '
git archive --format=tar.gz HEAD j1.tar.gz
test_cmp j.tgz j1.tar.gz
'
-test_expect_success GZIP 'infer tgz from .tgz filename' '
+test_expect_success GZIPCMD 'infer tgz from .tgz filename' '
git archive --output=j2.tgz HEAD
test_cmp j.tgz j2.tgz
'
-test_expect_success GZIP 'infer tgz from .tar.gz filename' '
+test_expect_success GZIPCMD 'infer tgz from .tar.gz filename' '
git archive --output=j3.tar.gz HEAD
test_cmp j.tgz j3.tar.gz
'
@@ -306,17 +306,17 @@ else
say Skipping some tar.gz tests because gunzip was not found
fi
-test_expect_success GZIP,GUNZIP 'extract tgz file' '
+test_expect_success GZIPCMD,GUNZIP 'extract tgz file' '
$GUNZIP -c j.tgz j.tar
test_cmp b.tar j.tar
'
-test_expect_success GZIP 'remote tar.gz is allowed by default' '
+test_expect_success GZIPCMD 'remote tar.gz is allowed by default' '
git archive --remote=. --format=tar.gz HEAD remote.tar.gz
test_cmp j.tgz remote.tar.gz
'
-test_expect_success GZIP 'remote tar.gz can be disabled' '
+test_expect_success GZIPCMD 'remote tar.gz can be disabled' '
git config tar.tar.gz.remote false
test_must_fail git archive --remote=. --format=tar.gz HEAD \
remote.tar.gz
--
1.8.5
--
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] Improvements to git-archive tests and add_submodule_odb()
On Mon, Dec 2, 2013 at 7:16 PM, Nick Townsend nick.towns...@mac.com wrote:
From: Nick Townsend nick.towns...@mac.com
Date: Sat, 30 Nov 2013 16:54:20 -0800
Subject: [PATCH 2/2] Additional git-archive tests
Interplay between paths specified in three ways now tested:
* After a : in the tree-ish,
* As a pathspec in the command,
* By virtue of the current working directory
Note that these tests are based on the behaviours
as found in 1.8.5. They may not be intentional.
They were developed to regression test enhancements
made to parse_treeish_arg() in archive.c
Signed-off-by: Nick Townsend nick.towns...@mac.com
---
t/t5004-archive-corner-cases.sh | 67
+
1 file changed, 67 insertions(+)
diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index 67f3b54..8b70e4a 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -113,4 +113,71 @@ test_expect_success 'archive empty subtree by direct
pathspec' '
check_dir extract sub
'
+test_expect_success 'setup - repository with subdirs' '
+ mkdir -p a/b/{c,d}
Unportable use of {foo,bar} notation. POSIX shells [1] will just
create a directory named {c,d}. Better to spell it out:
mkdir -p a/b/c a/b/d
[1]:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13
+ echo af a/af
+ echo bf a/b/bf
+ echo cf a/b/c/cf
+ git add a
+ git commit -m commit 1
+ git tag -a -m rev-1 rev-1
+'
+
+test_expect_success 'archive subtree from root by treeish' '
+ git archive --format=tar HEAD:a atreeroot.tar
+ make_dir extract
+ $TAR xf atreeroot.tar -C extract
+ check_dir extract af b b/bf b/c b/c/cf
+'
+
+test_expect_success 'archive subtree from root with pathspec' '
+ git archive --format=tar HEAD a atreepath.tar
+ make_dir extract
+ $TAR xf atreepath.tar -C extract
+ check_dir extract a a/af a/b a/b/bf a/b/c a/b/c/cf
+'
+
+test_expect_success 'archive subtree from root by 2-level treeish' '
+ git archive --format=tar HEAD:a/b abtreeroot.tar
+ make_dir extract
+ $TAR xf abtreeroot.tar -C extract
+ check_dir extract bf c c/cf
+'
+
+test_expect_success 'archive subtree from subdir' '
+ cd a
+ git archive --format=tar HEAD ../asubtree.tar
+ cd ..
+ make_dir extract
+ $TAR xf asubtree.tar -C extract
+ check_dir extract af b b/bf b/c b/c/cf
+'
If git-archive fails, the subsequent 'cd ..' will not be invoked,
hence all tests following this one will fail since the current
directory has not been restored. If you place the 'cd a' in a
subshell, then the current directory remains unchanged for commands
outside the subshell (and you can drop the 'cd ..'):
(
cd a
git archive ...
)
make_dir ...
...
Ditto for the remaining tests which share this problem.
+
+test_expect_success 'archive subtree from subdir with treeish' '
+ cd a
+ git archive --format=tar HEAD:./b ../absubtree.tar
+ cd ..
+ make_dir extract
+ $TAR xf absubtree.tar -C extract
+ check_dir extract bf c c/cf
+'
+
+test_expect_success 'archive subtree from subdir with treeish and pathspec' '
+ cd a
+ git archive --format=tar HEAD:./b c ../absubtree.tar
+ cd ..
+ make_dir extract
+ $TAR xf absubtree.tar -C extract
+ check_dir extract c c/cf
+'
+
+test_expect_success 'archive subtree from subdir with alt treeish' '
+ cd a
+ git archive --format=tar HEAD:b ../abxsubtree.tar
+ cd ..
+ make_dir extract
+ $TAR xf abxsubtree.tar -C extract
+ check_dir extract bf c c/cf
+'
+
test_done
--
1.8.5.4.g9d8cd78.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 1/1] tests: fix gzip with exported GZIP variable in environment
[cc'ing Peff, the author of these tests]
On Tue, Dec 3, 2013 at 3:57 AM, Christian Hesse m...@eworm.de wrote:
In t/t5000-tar-tree.sh the variable GZIP is used for the command name.
From man gzip:
The environment variable GZIP can hold a set of default options for
gzip. These options are interpreted first and can be overwritten by
explicit command line parameters.
So using any other variable name fixes this.
Missing Signed-off-by: you
---
t/t5000-tar-tree.sh | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index c2023b1..01b0ed9 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -25,7 +25,7 @@ commit id embedding:
'
. ./test-lib.sh
-GZIP=${GZIP:-gzip}
+GZIPCMD=${GZIPCMD:-gzip}
GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
@@ -275,27 +275,27 @@ test_expect_success 'only enabled filters are available
remotely' '
test_cmp remote.bar config.bar
'
-if $GZIP --version /dev/null 21; then
- test_set_prereq GZIP
+if $GZIPCMD --version /dev/null 21; then
+ test_set_prereq GZIPCMD
test_set_prereq is not actually operating on an environment variable.
Its argument is just a generic tag, which is uppercase by convention,
but not otherwise related to a variable which may share the same name,
and which does not pollute the environment. Consequently, it should
not be necessary to rename the argument to test_set_prereq, thus all
changes following this one become superfluous (since they are checking
for presence of tag GZIP, not referencing environment variable GZIP or
GZIPCMD). Thus, the patch becomes much smaller.
In fact, the GZIP command does not appear to be used at all by the
tests, so a simpler solution might be to remove the variable
altogether, and perhaps the prerequisite. Peff?
else
say Skipping some tar.gz tests because gzip not found
fi
-test_expect_success GZIP 'git archive --format=tgz' '
+test_expect_success GZIPCMD 'git archive --format=tgz' '
git archive --format=tgz HEAD j.tgz
'
-test_expect_success GZIP 'git archive --format=tar.gz' '
+test_expect_success GZIPCMD 'git archive --format=tar.gz' '
git archive --format=tar.gz HEAD j1.tar.gz
test_cmp j.tgz j1.tar.gz
'
-test_expect_success GZIP 'infer tgz from .tgz filename' '
+test_expect_success GZIPCMD 'infer tgz from .tgz filename' '
git archive --output=j2.tgz HEAD
test_cmp j.tgz j2.tgz
'
-test_expect_success GZIP 'infer tgz from .tar.gz filename' '
+test_expect_success GZIPCMD 'infer tgz from .tar.gz filename' '
git archive --output=j3.tar.gz HEAD
test_cmp j.tgz j3.tar.gz
'
@@ -306,17 +306,17 @@ else
say Skipping some tar.gz tests because gunzip was not found
fi
-test_expect_success GZIP,GUNZIP 'extract tgz file' '
+test_expect_success GZIPCMD,GUNZIP 'extract tgz file' '
$GUNZIP -c j.tgz j.tar
test_cmp b.tar j.tar
'
-test_expect_success GZIP 'remote tar.gz is allowed by default' '
+test_expect_success GZIPCMD 'remote tar.gz is allowed by default' '
git archive --remote=. --format=tar.gz HEAD remote.tar.gz
test_cmp j.tgz remote.tar.gz
'
-test_expect_success GZIP 'remote tar.gz can be disabled' '
+test_expect_success GZIPCMD 'remote tar.gz can be disabled' '
git config tar.tar.gz.remote false
test_must_fail git archive --remote=. --format=tar.gz HEAD \
remote.tar.gz
--
1.8.5
--
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
--
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] mv: let 'git mv file no-such-dir/' error out
On Tue, Dec 3, 2013 at 3:32 PM, Matthieu Moy matthieu@imag.fr wrote:
Git used to trim the trailing slash, and make the command equivalent to
'git mv file no-such-dir', which created the file no-such-dir (while the
trailing slash explicitly stated that it could only be a directory).
This patch skips the trailing slash removal for the destination path. The
path with its trailing slash is passed to rename(2), which errors out
with the appropriate message:
$ git mv file no-such-dir/
fatal: renaming 'file' failed: Not a directory
There's something we probably should check. In d78b0f3 ([PATCH]
git-mv: add more path normalization - 2006-08-16), it mentions about
git mv something/ somewhere/
there's no test in that commit so I don't know the actual input and
expected outcome. If somewhere is a directory, it errors out with
this patch and works without it. If somewhere does not exist, it
seems to work like Linux mv with or without the patch.
Original-patch-by: Duy Nguyen pclo...@gmail.com
Tests, tweaks and commit message by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
builtin/mv.c | 23 ---
t/t7001-mv.sh | 10 ++
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 2e0e61b..08fbc03 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -16,9 +16,12 @@ static const char * const builtin_mv_usage[] = {
NULL
};
+#define DUP_BASENAME 1
+#define KEEP_TRAILING_SLASH 2
+
static const char **internal_copy_pathspec(const char *prefix,
const char **pathspec,
- int count, int base_name)
+ int count, unsigned flags)
{
int i;
const char **result = xmalloc((count + 1) * sizeof(const char *));
@@ -27,11 +30,12 @@ static const char **internal_copy_pathspec(const char
*prefix,
for (i = 0; i count; i++) {
int length = strlen(result[i]);
int to_copy = length;
- while (to_copy 0 is_dir_sep(result[i][to_copy - 1]))
+ while (!(flags KEEP_TRAILING_SLASH)
+ to_copy 0 is_dir_sep(result[i][to_copy - 1]))
to_copy--;
- if (to_copy != length || base_name) {
+ if (to_copy != length || flags DUP_BASENAME) {
char *it = xmemdupz(result[i], to_copy);
- if (base_name) {
+ if (flags DUP_BASENAME) {
result[i] = xstrdup(basename(it));
free(it);
} else
@@ -87,16 +91,21 @@ int cmd_mv(int argc, const char **argv, const char
*prefix)
source = internal_copy_pathspec(prefix, argv, argc, 0);
modes = xcalloc(argc, sizeof(enum update_mode));
- dest_path = internal_copy_pathspec(prefix, argv + argc, 1, 0);
+ /*
+* Keep trailing slash, needed to let
+* git mv file no-such-dir/ error out.
+*/
+ dest_path = internal_copy_pathspec(prefix, argv + argc, 1,
+ KEEP_TRAILING_SLASH);
submodule_gitfile = xcalloc(argc, sizeof(char *));
if (dest_path[0][0] == '\0')
/* special case: . was normalized to */
- destination = internal_copy_pathspec(dest_path[0], argv,
argc, 1);
+ destination = internal_copy_pathspec(dest_path[0], argv,
argc, DUP_BASENAME);
else if (!lstat(dest_path[0], st)
S_ISDIR(st.st_mode)) {
dest_path[0] = add_slash(dest_path[0]);
- destination = internal_copy_pathspec(dest_path[0], argv,
argc, 1);
+ destination = internal_copy_pathspec(dest_path[0], argv,
argc, DUP_BASENAME);
} else {
if (argc != 1)
die(destination '%s' is not a directory,
dest_path[0]);
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b90e985..e5c8084 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -72,6 +72,16 @@ rm -f idontexist untracked1 untracked2 \
.git/index.lock
test_expect_success \
+'moving to target with trailing slash' \
+'test_must_fail git mv path0/COPYING no-such-dir/
+ test_must_fail git mv path0/COPYING no-such-dir//
+ git mv path0/ no-such-dir/'
+
+test_expect_success \
+'clean up' \
+'git reset --hard'
+
+test_expect_success \
'adding another file' \
'cp $TEST_DIRECTORY/../README path0/README
git add path0/README
--
1.8.5.rc3.4.g8bd3721
--
Duy
--
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 log --no-walk --tags produces strange result for certain user
Hey, I use the following commands to receive the list of tags together with hashes the point to: git log --tags --no-walk --format=%H%d%x01 --decorate=full Generally it works fine, however a user reported that for his repository this command returns the list containing several hashes without tag references. Something like this: 05c9a3a6247698ff740ca3a79828456347afdcef (HEAD, tag: refs/tags/2.33, refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master) a7fda708d76d7f83d5a160b6b137b98b7677f771 (tag: refs/tags/2.44) f119c2e7c69bb5ed1da5bae29c8754550ab96bde 07385a6ebe5a2e01e6ba9c8d0cb7b15c9a13f65d (tag: refs/tags/1.69) Here third hash doesn't have a reference. There are 3 such hashes in his repository. How can this happen? Is it a bug or some special scenario? * I've already asked the user to execute `git tag --points-at` on these suspiciously tagged hashes: nothing was returned. * `git show --decorate=full` executed on these hashes return commit details, and no references on them. * From the log user sees that these hashes indicate some normal commits, nothing special at first glance. Git version that he uses is 1.8.4.0. Thanks! -- 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: Ideas to speed up repacking
On Tue, Dec 3, 2013 at 2:17 PM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: If nothing else has happened in the repository, perhaps, but I suspect that the real problem is how you would prove it. For example, I am guessing that your Scenario 4 could be something like: : setup #1 $ git repack -a -d -f $ git prune : scenario #4 $ git commit --allow-empty -m 'new commit' which would add a single loose object to the repository, advancing the current branch ref by one commit, fast-forwarding relative to the state you were in after setup #1. But how would you efficiently prove that it was the only thing that happened? Shawn mentioned elsewhere that we could generate bundle header in and keep it in pack-XXX.bh file at pack creation time. With that information we could verify if a ref has been reset, just fast forwarded or even deleted. With what information? If you keep the back-then-current information and nothing else, how would you differentiate between the simple scenario #4 above vs 'lost and new' two commit versions of the scenario? The endpoints should both show that one ref (and only one ref) advanced by one commit, but one has cruft in the object database while the other does not. Yeah I was wrong. Reading Martin's mail again I wonder how we just grab all objects and skip history traversal. Who will decide object order in the new pack if we don't traverse history and collect path information. -- Duy -- 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/RESEND] transport.c: mark push status strings for translation
Mark strings like [up to date] passed to print_ref_status() for
translation with N_() instead of _() so they can remain untranslated
in porcelain mode.
While at there, mark some error strings in git push for translation
too.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/push.c | 8 +++---
transport.c| 81 ++
2 files changed, 52 insertions(+), 37 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 7b1b66c..22e2d4c 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -319,7 +319,7 @@ static int push_with_options(struct transport *transport,
int flags)
if (!is_empty_cas(cas)) {
if (!transport-smart_options)
- die(underlying transport does not support --%s option,
+ die(_(underlying transport does not support --%s
option),
CAS_OPT_NAME);
transport-smart_options-cas = cas;
}
@@ -426,7 +426,7 @@ static int option_parse_recurse_submodules(const struct
option *opt,
if (*flags (TRANSPORT_RECURSE_SUBMODULES_CHECK |
TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND))
- die(%s can only be used once., opt-long_name);
+ die(_(%s can only be used once.), opt-long_name);
if (arg) {
if (!strcmp(arg, check))
@@ -434,9 +434,9 @@ static int option_parse_recurse_submodules(const struct
option *opt,
else if (!strcmp(arg, on-demand))
*flags |= TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND;
else
- die(bad %s argument: %s, opt-long_name, arg);
+ die(_(bad %s argument: %s), opt-long_name, arg);
} else
- die(option %s needs an argument (check|on-demand),
+ die(_(option %s needs an argument (check|on-demand)),
opt-long_name);
return 0;
diff --git a/transport.c b/transport.c
index 7202b77..1fb92a1 100644
--- a/transport.c
+++ b/transport.c
@@ -14,6 +14,7 @@
#include url.h
#include submodule.h
#include string-list.h
+#include utf8.h
/* rsync support */
@@ -627,16 +628,23 @@ static void print_ref_status(char flag, const char
*summary, struct ref *to, str
else
fprintf(stdout, %s\n, summary);
} else {
- fprintf(stderr, %c %-*s , flag, TRANSPORT_SUMMARY_WIDTH,
summary);
+ int width = TRANSPORT_SUMMARY_WIDTH;
+ const char *localized_summary = _(summary);
+ /*
+* Compensate for the invisible bytes in utf-8
+* strings. The expression below is guaranteed always
+* positive (or zero in case of ascii strings) because
+* none of the doublewidth characters are ASCII
+* characters.
+*/
+ width += strlen(localized_summary) -
utf8_strwidth(localized_summary);
+ fprintf(stderr, %c %-*s , flag, width, localized_summary);
if (from)
fprintf(stderr, %s - %s,
prettify_refname(from-name), prettify_refname(to-name));
else
fputs(prettify_refname(to-name), stderr);
- if (msg) {
- fputs( (, stderr);
- fputs(msg, stderr);
- fputc(')', stderr);
- }
+ if (msg)
+ fprintf(stderr, (%s), _(msg));
fputc('\n', stderr);
}
}
@@ -649,11 +657,11 @@ static const char *status_abbrev(unsigned char sha1[20])
static void print_ok_ref_status(struct ref *ref, int porcelain)
{
if (ref-deletion)
- print_ref_status('-', [deleted], ref, NULL, NULL, porcelain);
+ print_ref_status('-', N_([deleted]), ref, NULL, NULL,
porcelain);
else if (is_null_sha1(ref-old_sha1))
print_ref_status('*',
- (!prefixcmp(ref-name, refs/tags/) ? [new tag] :
- [new branch]),
+ (!prefixcmp(ref-name, refs/tags/) ? N_([new tag]) :
+N_([new branch])),
ref, ref-peer_ref, NULL, porcelain);
else {
char quickref[84];
@@ -664,7 +672,7 @@ static void print_ok_ref_status(struct ref *ref, int
porcelain)
if (ref-forced_update) {
strcat(quickref, ...);
type = '+';
- msg = forced update;
+ msg = N_(forced update);
} else {
strcat(quickref, ..);
type = ' ';
@@ -678,50 +686,57 @@ static void print_ok_ref_status(struct ref *ref, int
porcelain)
static int
[PATCH] contrib/git-credential-gnome-keyring.c: small stylistic cleanups
Signed-off-by: John Szakmeister j...@szakmeister.net
---
The gnome-keyring credential backend had a number of coding style
violations. I believe this fixes all of them.
.../gnome-keyring/git-credential-gnome-keyring.c | 55 ++
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 635c96b..1613404 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -95,9 +95,9 @@ static const char*
gnome_keyring_result_to_message(GnomeKeyringResult result)
static void gnome_keyring_done_cb(GnomeKeyringResult result, gpointer
user_data)
{
- gpointer *data = (gpointer*) user_data;
- int *done = (int*) data[0];
- GnomeKeyringResult *r = (GnomeKeyringResult*) data[1];
+ gpointer *data = (gpointer *) user_data;
+ int *done = (int *) data[0];
+ GnomeKeyringResult *r = (GnomeKeyringResult *) data[1];
*r = result;
*done = 1;
@@ -132,27 +132,25 @@ static GnomeKeyringResult
gnome_keyring_item_delete_sync(const char *keyring, gu
*/
struct credential
{
- char *protocol;
- char *host;
+ char *protocol;
+ char *host;
unsigned short port;
- char *path;
- char *username;
- char *password;
+ char *path;
+ char *username;
+ char *password;
};
-#define CREDENTIAL_INIT \
- { NULL,NULL,0,NULL,NULL,NULL }
+#define CREDENTIAL_INIT { NULL, NULL, 0, NULL, NULL, NULL }
-typedef int (*credential_op_cb)(struct credential*);
+typedef int (*credential_op_cb)(struct credential *);
struct credential_operation
{
- char *name;
+ char *name;
credential_op_cb op;
};
-#define CREDENTIAL_OP_END \
- { NULL,NULL }
+#define CREDENTIAL_OP_END { NULL, NULL }
/* - GNOME Keyring functions - */
@@ -221,7 +219,7 @@ static int keyring_get(struct credential *c)
static int keyring_store(struct credential *c)
{
guint32 item_id;
- char *object = NULL;
+ char *object = NULL;
GnomeKeyringResult result;
/*
@@ -262,7 +260,7 @@ static int keyring_store(struct credential *c)
static int keyring_erase(struct credential *c)
{
- char *object = NULL;
+ char *object = NULL;
GList *entries;
GnomeKeyringNetworkPasswordData *password_data;
GnomeKeyringResult result;
@@ -298,8 +296,7 @@ static int keyring_erase(struct credential *c)
if (result == GNOME_KEYRING_RESULT_CANCELLED)
return EXIT_SUCCESS;
- if (result != GNOME_KEYRING_RESULT_OK)
- {
+ if (result != GNOME_KEYRING_RESULT_OK) {
g_critical(%s, gnome_keyring_result_to_message(result));
return EXIT_FAILURE;
}
@@ -312,8 +309,7 @@ static int keyring_erase(struct credential *c)
gnome_keyring_network_password_list_free(entries);
- if (result != GNOME_KEYRING_RESULT_OK)
- {
+ if (result != GNOME_KEYRING_RESULT_OK) {
g_critical(%s, gnome_keyring_result_to_message(result));
return EXIT_FAILURE;
}
@@ -325,9 +321,8 @@ static int keyring_erase(struct credential *c)
* Table with helper operation callbacks, used by generic
* credential helper main function.
*/
-static struct credential_operation const credential_helper_ops[] =
-{
- { get, keyring_get },
+static struct credential_operation const credential_helper_ops[] = {
+ { get, keyring_get },
{ store, keyring_store },
{ erase, keyring_erase },
CREDENTIAL_OP_END
@@ -370,7 +365,7 @@ static int credential_read(struct credential *c)
if (!line_len)
break;
- value = strchr(buf,'=');
+ value = strchr(buf, '=');
if (!value) {
g_warning(invalid credential line: %s, key);
gnome_keyring_memory_free(buf);
@@ -384,7 +379,7 @@ static int credential_read(struct credential *c)
} else if (!strcmp(key, host)) {
g_free(c-host);
c-host = g_strdup(value);
- value = strrchr(c-host,':');
+ value = strrchr(c-host, ':');
if (value) {
*value++ = '\0';
c-port = atoi(value);
@@ -429,16 +424,16 @@ static void credential_write(const struct credential *c)
static void usage(const char *name)
{
struct credential_operation const *try_op = credential_helper_ops;
- const char *basename = strrchr(name,'/');
+ const char *basename = strrchr(name, '/');
basename = (basename) ?
Re: [PATCH v3] gitweb: Add an option for adding more branch refs
On Mon, 2013-12-02 at 18:34 +0100, Jakub Narębski wrote:
W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
krzesi...@endocode.com wrote:
Allow @additional_branch_refs configuration variable to tell gitweb to
show refs from additional hierarchies in addition to branches in the
list-of-branches view.
Signed-off-by: Krzesimir Nowakkrzesi...@endocode.com
Why not use %feature hash instead of adding new configuration variable?
I think that this option is similar enough to 'remote_heads' feature
(which BTW should be 'remote-heads'), and could conceivably enabled
on a per-repository basis, i.e. with repository configuration override,
isn't it?
I'd like to see some consensus on it before I start changing the patch
again.
%feature hash is mainly (but not only) about options that can be
configured on per-repository basis. Configuration variables are
about options that are per-instance (per gitweb).
Well, I am mostly interested in per-instance configuration in this case,
but if that is also possible with %feature hash, then ok, I'll try to
make it work.
From what I've seen (correct me please if I got it wrong) feature
settings is taken from per-repository config file from [gitweb] section.
If there's nothing then some default value is taken. That default value
can be overriden with per-instance perl config file.
So it is easy to override it from per-instance perl config by typing:
$feature{'additional-branch-refs'}{'default'} = ['wip', 'no|tfun,ny'];
$feature{'additional-branch-refs'}{'override'} = 1;
(Note the edge case of refs/no|tfun,ny, which passes the git
check-ref-format scrutiny.)
But for now, most of features are quite simple - either booleans,
integers or list of simple strings (in snapshot feature). What I need
here is a list of strings, like CSV in following example:
[gitweb]
additional_branch_refs = wip,no|tfun,ny
Is dependency on external module like Text::CSV or Text::CSV_XS ok? If
not, I can hack some CSV reading code.
Usually %feature hash is preferred over adding new configuration variable
but this is not some hard rule. Note however that patches adding new config
are met with more scrutiny, as it is harder to fix mistakes because of
requirement of backwards compatibility of configuration files.
I don't know what kind of backwards compatibility you mention. Whether
you want gitweb to survive reading old config file or to honor
deprecated/old config variables.
I meant here honoring deprecated/old variables, i.e. honoring existing
configuration files. See for example backward compatibility for old
$stylesheet variable vs new @stylesheets in print_header_links().
Though in this case it shouldn't be much of a problem; it would be
easy to honor @additional_branch_refs by setting 'default' for
'extra-branch-refs' feature to it.
extra-branch-refs is nicer than additional-branch-refs, I'll use it.
BTW. there really should be gitweb/CodingGuidelines...
Yes, would be useful. As in every other project. :)
Well, Git itself *has* Documentation/CodingGuidelines, but perhaps
gitweb subsystem should have it's own...
[...]
@@ -3662,7 +3701,8 @@ sub git_get_heads_list {
my ($committer, $epoch, $tz) =
($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
$ref_item{'fullname'} = $name;
- $name =~ s!^refs/(?:head|remote)s/!!;
+ my $strip_refs = join '|', map { quotemeta }
get_branch_refs();
+ $name =~ s!^refs/(?:$strip_refs|remotes)/!!;
$ref_item{'name'} = $name;
$ref_item{'id'}= $hash;
@@ -7179,7 +7219,8 @@ sub snapshot_name {
$ver = $1;
} else {
# branches and other need shortened SHA-1 hash
- if ($hash =~ m!^refs/(?:heads|remotes)/(.*)$!) {
+ my $strip_refs = join '|', map { quotemeta }
get_branch_refs();
+ if ($hash =~ m!^refs/(?:$strip_refs|remotes)/(.*)$!) {
$ver = $1;
}
$ver .= '-' . git_get_short_hash($project, $hash);
One one hand, it is about threating extra branch refs the same way as
'head'.
On the other hand we loose distinction between 'refs/heads/foo' and e.g.
'refs/wip/foo'. But maybe that's all right...
In git_get_heads_list sub I could append a ($ref_dir) to refs which
are in neither 'heads' nor 'remotes', so heads view would look like:
master
old-stable
some-work-in-progress (wip)
some-other-branch (other)
where both master and old-stable are in refs/heads/,
some-work-in-progress in refs/wip/ and some-other-branch in refs/other/.
In case of branch snapshot names (snapshot_name sub) I could change it,
so names for branches mentioned above
Great Donation
My wife and I won the Euro Millions Lottery will be donating 1.5 Million Pounds to you in our ongoing lucky draws donations. Please get back to us with your Name, Age, Tel, Country and i will send you more details how your funds will be sent to you. Please read the article - http://news.sky.com/story/972395/148-6m-euromillions-jackpot-winners-named Adrian Gillian Bayford. -- 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: Fwd: [PATCH 4/5] Replace {pre,suf}fixcmp() with {starts,ends}_with()
On Tue, Dec 03, 2013 at 08:03:39AM +0100, Christian Couder wrote:
I am trying to forward this patch from my gmail address, as it doesn't
seem to go through when I send it from my home machine.
This made it through to me, but not the list. There are at least two
things going on:
1. The message is 172K, which is over the 100K limit imposed by vger;
the list is silently dropping it.
2. In my case, the direct mail was being flagged by spam because it
contains the blacklisted domain old.name. Which of course is not
a domain at all but rather this code:
old.name = old.path + strlen(refs/heads/);
I've tweaked my server.
I can't say why it wasn't getting to Junio via direct mail. Maybe the
same spam thing, or maybe something else.
From: Christian Couder chrisc...@tuxfamily.org
Date: Sun, Dec 1, 2013 at 8:49 AM
Subject: [PATCH 4/5] Replace {pre,suf}fixcmp() with {starts,ends}_with()
To: christian.cou...@gmail.com
This patch was generated automatically using the following
commands:
git grep --name-only prefixcmp | grep -v '\.h' | grep -v 'strbuf.c' |
xargs perl -pi -e 's/!prefixcmp\(/starts_with\(/g'
git grep --name-only prefixcmp | grep -v '\.h' | grep -v 'strbuf.c' |
xargs perl -pi -e 's/prefixcmp\(/!starts_with\(/g'
git grep --name-only suffixcmp | grep -v '\.h' | grep -v 'strbuf.c' |
xargs perl -pi -e 's/!suffixcmp\(/ends_with\(/g'
git grep --name-only suffixcmp | grep -v '\.h' | grep -v 'strbuf.c' |
xargs perl -pi -e 's/suffixcmp\(/!ends_with\(/g'
It was generated on version 1.8.5 of the git codebase.
I skimmed the patch and didn't notice any problems. It's
whitespace-damaged by gmail, of course. The simplest thing is probably
to just point us at a public repo with the commit, if you have one.
-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 v3] gitweb: Add an option for adding more branch refs
On Tue, Dec 3, 2013 at 11:53 AM, Krzesimir Nowak krzesi...@endocode.com wrote:
On Mon, 2013-12-02 at 18:34 +0100, Jakub Narębski wrote:
W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
krzesi...@endocode.com wrote:
Allow @additional_branch_refs configuration variable to tell gitweb to
show refs from additional hierarchies in addition to branches in the
list-of-branches view.
Signed-off-by: Krzesimir Nowakkrzesi...@endocode.com
Why not use %feature hash instead of adding new configuration variable?
I think that this option is similar enough to 'remote_heads' feature
(which BTW should be 'remote-heads'), and could conceivably enabled
on a per-repository basis, i.e. with repository configuration override,
isn't it?
I'd like to see some consensus on it before I start changing the patch
again.
%feature hash is mainly (but not only) about options that can be
configured on per-repository basis. Configuration variables are
about options that are per-instance (per gitweb).
Well, I am mostly interested in per-instance configuration in this case,
but if that is also possible with %feature hash, then ok, I'll try to
make it work.
Yes, it is possible to have per-instance configuration (you can even
forbid per-repository configuration).
From what I've seen (correct me please if I got it wrong) feature
settings is taken from per-repository config file from [gitweb] section.
If there's nothing then some default value is taken. That default value
can be overriden with per-instance perl config file.
%feature settings are taken from gitweb configuration (the 'default'
key), and if given feature is overrideable and per-repository configuration
in the form of appropriate key in [gitweb] section of repository config
file exists, it is used instead.
So it is easy to override it from per-instance perl config by typing:
$feature{'additional-branch-refs'}{'default'} = ['wip', 'no|tfun,ny'];
$feature{'additional-branch-refs'}{'override'} = 1;
Yes. The 'override' is about checking (which imposes a bit of
performance penalty) and respecting per-repository configuration.
(Note the edge case of refs/no|tfun,ny, which passes the git
check-ref-format scrutiny.)
But for now, most of features are quite simple - either booleans,
integers or list of simple strings (in snapshot feature). What I need
here is a list of strings, like CSV in following example:
[gitweb]
additional_branch_refs = wip,no|tfun,ny
Is dependency on external module like Text::CSV or Text::CSV_XS ok? If
not, I can hack some CSV reading code.
Why not use space, which is forbidden in refnames, to separate
entries? Similar to feature_snapshot(), which is about comma separated
list, without escaping.
--
Jakub Narebski
--
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/1] tests: fix gzip with exported GZIP variable in environment
On Tue, Dec 03, 2013 at 04:49:06AM -0500, Eric Sunshine wrote: -if $GZIP --version /dev/null 21; then - test_set_prereq GZIP +if $GZIPCMD --version /dev/null 21; then + test_set_prereq GZIPCMD test_set_prereq is not actually operating on an environment variable. Its argument is just a generic tag, which is uppercase by convention, but not otherwise related to a variable which may share the same name, and which does not pollute the environment. Consequently, it should not be necessary to rename the argument to test_set_prereq, thus all changes following this one become superfluous (since they are checking for presence of tag GZIP, not referencing environment variable GZIP or GZIPCMD). Thus, the patch becomes much smaller. Right. We can get away with just changing the environment variable, and leaving the prereq. By the way, we had the exact same problem with $UNZIP, fixed in ac00128 (t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead, 2013-01-06). I'd probably call the new variable GIT_GZIP for consistency, but... In fact, the GZIP command does not appear to be used at all by the tests, so a simpler solution might be to remove the variable altogether, and perhaps the prerequisite. Peff? Yes, though it's a bit more subtle than that. The gzip tests are relying on git's internally-configured tar.tgz.command filter, which is hard-coded to gzip -cn. So we do depend on having a working gzip, but we do _not_ depend on the one found in the $GZIP variable. It must be called gzip. There are a few options I see: 1. Drop $GZIP variable, and hard-code the prerequisite check to gzip, which is what is being tested. 2. Keep $GZIP (but rename it to $GIT_GZIP), and explicitly set up tar.tgz.command as $GIT_GZIP -cn. 3. Teach the Makefile a knob to set the value for gzip at compile time, and use that for the baked-in config (and propagate it to the test to check the prerequisite). I think I'd be in favor of (1). It's the simplest, and we have not seen any reports of people who do not actually have gzip called gzip. Users can still override it via config if they really want to. -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
[PATCH] t5000: simplify gzip prerequisite checks
In t5000, we test the built-in .tar.gz config for
git-archive. To make our tests portable, we check that we
have a way to both gzip and gunzip, and we respected
environment variables to point to alternate commands for
doing these operations.
However, the $GZIP variable did not actually do anything, as
changing it would not affect the baked-in value in
archive-tar.c. Moreover, setting the variable $GZIP
influences gzip itself. From the gzip man page:
The environment variable GZIP can hold a set of default
options for gzip. These options are interpreted first and
can be overwritten by explicit command line parameters.
We could rename this variable, and use it to set up custom
config (or even have a Makefile knob to affect the built
binary), but it is not worth the trouble; nobody has ever
reported a problem with the baked-in default, and they can
always change it via config if they need to. Let's just drop
the variable and use gzip in the test (keeping the
prerequisite, of course).
While we're at it, we can drop the GUNZIP variable and
prerequisite; it uses gzip -d, so if we have GZIP, we
will have both.
We can also use test_lazy_prereq for the gzip prerequisite,
which is simpler and behaves more consistently with the rest
of git (e.g., by making output available when the test is
run with -v).
Noticed-by: Christian Hesse m...@eworm.de
Signed-off-by: Jeff King p...@peff.net
---
t/t5000-tar-tree.sh | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index c2023b1..519cc34 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -25,8 +25,6 @@ commit id embedding:
'
. ./test-lib.sh
-GZIP=${GZIP:-gzip}
-GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
@@ -39,6 +37,8 @@ test_lazy_prereq TAR_NEEDS_PAX_FALLBACK '
)
'
+test_lazy_prereq GZIP 'gzip --version'
+
get_pax_header() {
file=$1
header=$2=
@@ -275,12 +275,6 @@ test_expect_success 'only enabled filters are available
remotely' '
test_cmp remote.bar config.bar
'
-if $GZIP --version /dev/null 21; then
- test_set_prereq GZIP
-else
- say Skipping some tar.gz tests because gzip not found
-fi
-
test_expect_success GZIP 'git archive --format=tgz' '
git archive --format=tgz HEAD j.tgz
'
@@ -300,14 +294,8 @@ test_expect_success GZIP 'infer tgz from .tar.gz filename'
'
test_cmp j.tgz j3.tar.gz
'
-if $GUNZIP --version /dev/null 21; then
- test_set_prereq GUNZIP
-else
- say Skipping some tar.gz tests because gunzip was not found
-fi
-
-test_expect_success GZIP,GUNZIP 'extract tgz file' '
- $GUNZIP -c j.tgz j.tar
+test_expect_success GZIP 'extract tgz file' '
+ gzip -d -c j.tgz j.tar
test_cmp b.tar j.tar
'
--
1.8.5.rc3.493.g965953d
--
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 10/21] pack-bitmap: add support for bitmap indexes
Am 28.11.2013 11:38, schrieb Jeff King:
On Wed, Nov 27, 2013 at 10:08:56AM +0100, Karsten Blees wrote:
Khash is OK for sha1 keys, but I don't think it should be advertised
as a second general purpose hash table implementation. Its far too
easy to shoot yourself in the foot by using 'straightforward' hash-
and comparison functions. Khash doesn't store the hash codes of the
keys, so you have to take care of that yourself or live with the
performance penalties (see [1]).
[1] http://article.gmane.org/gmane.comp.version-control.git/237876
Yes. I wonder if we should improve it in that respect. I haven't looked
carefully at the hash code you posted elsewhere, but I feel like many
uses will want a macro implementation to let them store arbitrary types
smaller or larger than a pointer.
-Peff
IMO, trying to improve khash isn't worth the trouble.
With smaller-than-pointer types, khash _may_ actually save a few bytes compared
to hash.[ch] or hashmap.[ch]. E.g. a set of 'int's would be a perfect use case
for khash. However, you're using bitmaps for that, and khash's predefined
macros for int sets and maps have been removed from the git version.
Using khash with pointers and larger-than-pointer types is just a waste of
memory and performance, though. Hash tables are sparsely filled by design, and
using large types means lots of large empty buckets. E.g. kh_resize requires
almost four times the size or your data, and copies everything at least three
times.
Additionally, there are the obvious problems with khash's macro design (hard to
read, impossible to debug, and each named instance increases executable size by
~4k).
Below is a patch that converts pack-bitmap.c to hashmap. Its not even longer
than the khash version, and the hashmap API forces you to think about
no-brainer improvements such as specifying an expected size or skipping
duplicates checks where they aren't needed. I could do the same for
pack-bitmap-write.c if you like.
Karsten
---8--
Subject: [PATCH] pack-bitmap.c: convert to new hashmap implementation
Preallocates bitmap_index.bitmaps with the expected size to prevent
rehashing.
Combines the five arrays of ext_index ('objects', 'hashes' and khash's
'keys', 'flags' and 'vals') into a single structure for better locality.
Removes two unnecessary duplicates checks:
- we don't expect a pack index file to contain duplicate sha1's
- ext_index_add_object is only called after bitmap_position returned -1,
so it is impossible that the entry is already there
Signed-off-by: Karsten Blees bl...@dcon.de
---
pack-bitmap.c | 166 --
1 file changed, 81 insertions(+), 85 deletions(-)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 078f7c6..115caed 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -15,6 +15,7 @@
* commit.
*/
struct stored_bitmap {
+ struct hashmap_entry ent;
unsigned char sha1[20];
struct ewah_bitmap *root;
struct stored_bitmap *xor;
@@ -22,6 +23,16 @@ struct stored_bitmap {
};
/*
+ * An entry in the extended index.
+ */
+struct ext_entry {
+ struct hashmap_entry ent;
+ uint32_t name_hash;
+ struct object *object;
+ unsigned int nr;
+};
+
+/*
* The currently active bitmap index. By design, repositories only have
* a single bitmap index available (the index for the biggest packfile in
* the repository), since bitmap indexes need full closure.
@@ -61,7 +72,7 @@ static struct bitmap_index {
struct ewah_bitmap *tags;
/* Map from SHA1 - `stored_bitmap` for all the bitmapped comits */
- khash_sha1 *bitmaps;
+ struct hashmap bitmaps;
/* Number of bitmapped commits */
uint32_t entry_count;
@@ -76,12 +87,7 @@ static struct bitmap_index {
* packed in `pack`, these objects are added to this fake index and
* are assumed to appear at the end of the packfile for all operations
*/
- struct eindex {
- struct object **objects;
- uint32_t *hashes;
- uint32_t count, alloc;
- khash_sha1_pos *positions;
- } ext_index;
+ struct hashmap ext_index;
/* Bitmap result of the last performed walk */
struct bitmap *result;
@@ -93,6 +99,21 @@ static struct bitmap_index {
} bitmap_git;
+static int stored_bitmap_cmp(const struct stored_bitmap *entry,
+ const struct stored_bitmap *entry_or_key,
+ const unsigned char *sha1)
+{
+ return hashcmp(entry-sha1, sha1 ? sha1 : entry_or_key-sha1);
+}
+
+static int ext_entry_cmp(const struct ext_entry *entry,
+ const struct ext_entry *entry_or_key,
+ const unsigned char *sha1)
+{
+ return hashcmp(entry-object-sha1,
+ sha1 ? sha1 : entry_or_key-object-sha1);
+}
+
static struct ewah_bitmap *lookup_stored_bitmap(struct stored_bitmap *st)
{
struct
[PATCH 1/3] gitweb: Move check-ref-format code into separate function
This check will be used in more than one place later.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Reviewed-by: Jakub Narębski jna...@gmail.com
Reviewed-by: Eric Sunshine sunsh...@sunshineco.com
---
gitweb/gitweb.perl | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 68c77f6..f7730d7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1452,6 +1452,16 @@ sub validate_pathname {
return $input;
}
+sub check_ref_format {
+ my $input = shift || return undef;
+
+ # restrictions on ref name according to git-check-ref-format
+ if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
+ return undef;
+ }
+ return $input;
+}
+
sub validate_refname {
my $input = shift || return undef;
@@ -1462,10 +1472,9 @@ sub validate_refname {
# it must be correct pathname
$input = validate_pathname($input)
or return undef;
- # restrictions on ref name according to git-check-ref-format
- if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
- return undef;
- }
+ # check git-check-ref-format restrictions
+ $input = check_ref_format($input)
+ or return undef;
return $input;
}
--
1.8.3.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
[PATCH 3/3] gitweb: Denote non-heads, non-remotes branches.
Given two branches residing in refs/heads/master and refs/wip/feature
the list-of-branches view will present them in following way:
master
feature (wip)
When getting a snapshot of a 'feature' branch, the tarball is going to
have name like 'project-wip-feature-short hash.tgz'.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Reviewed-by: Jakub Narębski jna...@gmail.com
Reviewed-by: Eric Sunshine sunsh...@sunshineco.com
---
gitweb/gitweb.perl | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6326075..eb8d962 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3723,8 +3723,14 @@ sub git_get_heads_list {
$ref_item{'fullname'} = $name;
my $strip_refs = join '|', map { quotemeta } get_branch_refs();
$name =~ s!^refs/($strip_refs|remotes)/!!;
+ $ref_item{'name'} = $name;
+ # for refs neither in 'heads' nor 'remotes' we want to
+ # show their different ref dir
+ my $ref_dir = (defined $1) ? $1 : '';
+ if ($ref_dir ne '' and $ref_dir ne 'heads' and $ref_dir ne
'remotes') {
+ $ref_item{'name'} .= ' (' . $ref_dir . ')';
+ }
- $ref_item{'name'} = $name;
$ref_item{'id'}= $hash;
$ref_item{'title'} = $title || '(no commit message)';
$ref_item{'epoch'} = $epoch;
@@ -7241,7 +7247,24 @@ sub snapshot_name {
# branches and other need shortened SHA-1 hash
my $strip_refs = join '|', map { quotemeta } get_branch_refs();
if ($hash =~ m!^refs/($strip_refs|remotes)/(.*)$!) {
- $ver = $1;
+ my $ref_dir = $1;
+ $ver = $2;
+
+ if (defined $ref_dir) {
+ # this is going to be a part of
+ # filename, so lets stick to
+ # alphanumerics, dashes and underlines
+ # only - some filesystems do not like
+ # some punctuation symbols for
+ # example.
+ $ref_dir =~ s/[^[:alnum:]_-]//g;
+ }
+
+ # for refs not in heads nor remotes we want to
+ # add a ref dir to archive name
+ if ($ref_dir ne '' and $ref_dir ne 'heads' and $ref_dir
ne 'remotes') {
+ $ver = $ref_dir . '-' . $ver;
+ }
}
$ver .= '-' . git_get_short_hash($project, $hash);
}
--
1.8.3.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
[PATCH 2/3] gitweb: Add a feature for adding more branch refs
Allow extra-branch-refs feature to tell gitweb to show refs from
additional hierarchies in addition to branches in the list-of-branches
view.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Reviewed-by: Jakub Narębski jna...@gmail.com
Reviewed-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/gitweb.conf.txt | 27 +++
gitweb/gitweb.perl| 76 ---
2 files changed, 91 insertions(+), 12 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index e2113d9..3de8e14 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -849,6 +849,33 @@ time zones in the form of +/-HHMM, such as +0200.
+
Project specific override is not supported.
+extra-branch-refs::
+ List of additional directories under refs which are going to
+ be used as branch refs. For example if you have a gerrit setup
+ where all branches under refs/heads/ are official,
+ push-after-review ones and branches under refs/sandbox/,
+ refs/wip and refs/other are user ones where permissions are
+ much wider, then you might want to set this variable as
+ follows:
++
+
+$feature{'extra-branch-refs'}{'default'} =
+ ['sandbox', 'wip', 'other'];
+
++
+If overriding was enabled then this feature can be configured on a
+per-repository basis via repository's `gitweb.extrabranchrefs`
+configuration variable, which contains a space separated list of
+refs. An example:
++
+
+[gitweb]
+ extrabranchrefs = sandbox wip other
+
++
+It is an error to specify a ref that does not pass git check-ref-format
+scrutiny. Duplicated values are filtered.
+
EXAMPLES
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f7730d7..6326075 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -548,6 +548,20 @@ our %feature = (
'sub' = sub { feature_bool('remote_heads', @_) },
'override' = 0,
'default' = [0]},
+
+ # Enable showing branches under other refs in addition to heads
+
+ # To set system wide extra branch refs have in $GITWEB_CONFIG
+ # $feature{'extra-branch-refs'}{'default'} = ['dirs', 'of', 'choice'];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'extra-branch-refs'}{'override'} = 1;
+ # and in project config gitweb.extrabranchrefs = dirs of choice
+ # Every directory is separated with whitespace.
+
+ 'extra-branch-refs' = {
+ 'sub' = \feature_extra_branch_refs,
+ 'override' = 0,
+ 'default' = []},
);
sub gitweb_get_feature {
@@ -626,6 +640,17 @@ sub feature_avatar {
return @val ? @val : @_;
}
+sub feature_extra_branch_refs {
+ my (@branch_refs) = @_;
+ my $values = git_get_project_config('extra_branch_refs');
+
+ if ($values) {
+ @branch_refs = split /\s+/, $values;
+ }
+
+ return @branch_refs;
+}
+
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
@@ -656,6 +681,18 @@ sub filter_snapshot_fmts {
!$known_snapshot_formats{$_}{'disabled'}} @fmts;
}
+sub filter_and_validate_refs {
+ my @refs = @_;
+ my %unique_refs = ();
+
+ foreach my $ref (@refs) {
+ die_error(500, Invalid ref '$ref' in 'extra-branch-refs'
feature) unless (check_ref_format($ref));
+ # 'heads' are added implicitly in get_branch_refs().
+ $unique_refs{$ref} = 1 if ($ref ne 'heads');
+ }
+ return sort keys %unique_refs;
+}
+
# If it is set to code reference, it is code that it is to be run once per
# request, allowing updating configurations that change with each request,
# while running other code in config file only once.
@@ -1113,7 +1150,7 @@ sub evaluate_git_dir {
our $git_dir = $projectroot/$project if $project;
}
-our (@snapshot_fmts, $git_avatar);
+our (@snapshot_fmts, $git_avatar, @extra_branch_refs);
sub configure_gitweb_features {
# list of supported snapshot formats
our @snapshot_fmts = gitweb_get_feature('snapshot');
@@ -1131,6 +1168,13 @@ sub configure_gitweb_features {
} else {
$git_avatar = '';
}
+
+ our @extra_branch_refs = gitweb_get_feature('extra-branch-refs');
+ @extra_branch_refs = filter_and_validate_refs (@extra_branch_refs);
+}
+
+sub get_branch_refs {
+ return ('heads', @extra_branch_refs);
}
# custom error
[PATCH 0/3] Show extra branch refs in gitweb
First patch just splits some code to a function, second patch adds the extra-branch-refs feature and third one adds some visual differentation of branches from non-standard ref directories. Krzesimir Nowak (3): gitweb: Move check-ref-format code into separate function gitweb: Add a feature for adding more branch refs gitweb: Denote non-heads, non-remotes branches. Documentation/gitweb.conf.txt | 27 ++ gitweb/gitweb.perl| 120 +++--- 2 files changed, 129 insertions(+), 18 deletions(-) -- 1.8.3.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 v3] gitweb: Add an option for adding more branch refs
On Tue, 2013-12-03 at 14:02 +0100, Jakub Narębski wrote:
On Tue, Dec 3, 2013 at 11:53 AM, Krzesimir Nowak krzesi...@endocode.com
wrote:
On Mon, 2013-12-02 at 18:34 +0100, Jakub Narębski wrote:
W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
krzesi...@endocode.com wrote:
Allow @additional_branch_refs configuration variable to tell gitweb to
show refs from additional hierarchies in addition to branches in the
list-of-branches view.
Signed-off-by: Krzesimir Nowakkrzesi...@endocode.com
Why not use %feature hash instead of adding new configuration variable?
I think that this option is similar enough to 'remote_heads' feature
(which BTW should be 'remote-heads'), and could conceivably enabled
on a per-repository basis, i.e. with repository configuration override,
isn't it?
I'd like to see some consensus on it before I start changing the patch
again.
%feature hash is mainly (but not only) about options that can be
configured on per-repository basis. Configuration variables are
about options that are per-instance (per gitweb).
Well, I am mostly interested in per-instance configuration in this case,
but if that is also possible with %feature hash, then ok, I'll try to
make it work.
Yes, it is possible to have per-instance configuration (you can even
forbid per-repository configuration).
From what I've seen (correct me please if I got it wrong) feature
settings is taken from per-repository config file from [gitweb] section.
If there's nothing then some default value is taken. That default value
can be overriden with per-instance perl config file.
%feature settings are taken from gitweb configuration (the 'default'
key), and if given feature is overrideable and per-repository configuration
in the form of appropriate key in [gitweb] section of repository config
file exists, it is used instead.
So it is easy to override it from per-instance perl config by typing:
$feature{'additional-branch-refs'}{'default'} = ['wip', 'no|tfun,ny'];
$feature{'additional-branch-refs'}{'override'} = 1;
Yes. The 'override' is about checking (which imposes a bit of
performance penalty) and respecting per-repository configuration.
(Note the edge case of refs/no|tfun,ny, which passes the git
check-ref-format scrutiny.)
But for now, most of features are quite simple - either booleans,
integers or list of simple strings (in snapshot feature). What I need
here is a list of strings, like CSV in following example:
[gitweb]
additional_branch_refs = wip,no|tfun,ny
Is dependency on external module like Text::CSV or Text::CSV_XS ok? If
not, I can hack some CSV reading code.
Why not use space, which is forbidden in refnames, to separate
entries? Similar to feature_snapshot(), which is about comma separated
list, without escaping.
Thanks for explanations and a hint. Following patches are in Show extra
branch refs in gitweb.
Cheers,
--
Krzesimir Nowak
Software Developer
Endocode AG
krzesi...@endocode.com
--
Endocode AG, Johannisstraße 20, 10117 Berlin
i...@endocode.com | www.endocode.com
Vorstandsvorsitzender: Mirko Boehm
Vorstände: Dr. Karl Beecher, Chris Kühl, Sebastian Sucker
Aufsichtsratsvorsitzende: Jennifer Beecher
Registergericht: Amtsgericht Charlottenburg - HRB 150748 B
--
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] path_treatment: also ignore $GIT_DIR if it's not .git
Am 01.12.2013 20:04, schrieb Dennis Kaarsemaker: We always ignore anything named .git, but we should also ignore the git directory if the user overrides it by setting $GIT_DIR Reported-By: Ingy döt Net i...@ingy.net Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net --- dir.c | 2 +- t/t7508-status.sh | 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/dir.c b/dir.c index 23b6de4..884b37d 100644 --- a/dir.c +++ b/dir.c @@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct *dir, The special case for .git is hardcoded in many places in git, including the line immediately above this diff hunk. So I figure that GIT_DIR is not meant to _rename_ the .git dir, but to point somewhere _outside_ the worktree (or somewhere within the .git dir). If we want to support the rename case fully, I think there are a few more questions to answer (and a few more places to change), e.g.: - What if GIT_DIR=.foo and someone upstream adds a .foo directory? - Should it be possible to track .git as a normal file or directory if its not the GIT_DIR? - What about other commands than status, e.g. does 'git clean -df' leave the GIT_DIR alone? If we don't want to support this, though, I think it would be more approrpiate to issue a warning if GIT_DIR points to a worktree location. -- 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: trouble on windows network share
Did anyone ever get to the bottom of this? I'm seeing this exact issue on both NetApp storage systems with SMB 2.x enabled and also on Windows 7 and Server 2008 R2 shares (which also use SMB 2.x). If we use SMB 1.x (such as XP), things work fine. -- 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: trouble on windows network share
That is a new detail (SMB 1 vs. 2) that can be used to debug this further. -Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Phil Wiffen Sent: Tuesday, December 03, 2013 11:48 AM To: git@vger.kernel.org Subject: Re: trouble on windows network share Did anyone ever get to the bottom of this? I'm seeing this exact issue on both NetApp storage systems with SMB 2.x enabled and also on Windows 7 and Server 2008 R2 shares (which also use SMB 2.x). If we use SMB 1.x (such as XP), things work fine. -- 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 smime.p7s Description: S/MIME cryptographic signature
Re: Ideas to speed up repacking
Duy Nguyen pclo...@gmail.com writes: Reading Martin's mail again I wonder how we just grab all objects and skip history traversal. Who will decide object order in the new pack if we don't traverse history and collect path information. I vaguely recall raising a related topic for quick repack, assuming everything in existing packfiles are reachable, that only removes loose cruft several weeks ago. Once you decide that your quick repack do not care about ejecting objects from existing packs, like how I suspect Martin's outline will lead us to, we can repack the reachable loose ones on the recent surface of the history and then concatenate the contents of existing packs, excluding duplicates and possibly adjusting the delta base offsets for some entries, without traversing the bulk of the history. -- 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] Improvements to git-archive tests and add_submodule_odb()
Nick Townsend nick.towns...@mac.com writes:
From: Nick Townsend nick.towns...@mac.com
Date: Mon, 25 Nov 2013 15:31:09 -0800
Subject: [PATCH 1/2] submodule: add_submodule_odb() usability
Please do not add these; instead, drop From/Date (because we can see
them in the mail header from your MUA) and replace the mail header
Subject with this one.
The body of the patch looks OK to me (provided that we'd want to
promote use of that function).
Thanks.
Although add_submodule_odb() is documented as being
externally usable, it is declared static and also
has incorrect documentation. This commit fixes those
and makes no changes to existing code using them.
All tests still pass.
Improved wording based on Rene Scharfe feedback
Signed-off-by: Nick Townsend nick.towns...@mac.com
---
Documentation/technical/api-ref-iteration.txt | 4 ++--
submodule.c | 2 +-
submodule.h | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/api-ref-iteration.txt
b/Documentation/technical/api-ref-iteration.txt
index aa1c50f..02adfd4 100644
--- a/Documentation/technical/api-ref-iteration.txt
+++ b/Documentation/technical/api-ref-iteration.txt
@@ -50,10 +50,10 @@ submodules object database. You can do this by a
code-snippet like
this:
const char *path = path/to/submodule
- if (!add_submodule_odb(path))
+ if (add_submodule_odb(path))
die(Error submodule '%s' not populated., path);
-`add_submodule_odb()` will return an non-zero value on success. If you
+`add_submodule_odb()` will return zero on success. If you
do not do this you will get an error for each ref that it does not point
to a valid object.
diff --git a/submodule.c b/submodule.c
index 1905d75..1ea46be 100644
--- a/submodule.c
+++ b/submodule.c
@@ -143,7 +143,7 @@ void stage_updated_gitmodules(void)
die(_(staging updated .gitmodules failed));
}
-static int add_submodule_odb(const char *path)
+int add_submodule_odb(const char *path)
{
struct strbuf objects_directory = STRBUF_INIT;
struct alternate_object_database *alt_odb;
diff --git a/submodule.h b/submodule.h
index 7beec48..3e3cdca 100644
--- a/submodule.h
+++ b/submodule.h
@@ -41,5 +41,6 @@ int find_unpushed_submodules(unsigned char new_sha1[20],
const char *remotes_nam
struct string_list *needs_pushing);
int push_unpushed_submodules(unsigned char new_sha1[20], const char
*remotes_name);
void connect_work_tree_and_git_dir(const char *work_tree, const char
*git_dir);
+int add_submodule_odb(const char *path);
#endif
--
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] Improvements to git-archive tests and add_submodule_odb()
Eric Sunshine sunsh...@sunshineco.com writes: +test_expect_success 'archive subtree from subdir' ' + cd a + git archive --format=tar HEAD ../asubtree.tar + cd .. + make_dir extract + $TAR xf asubtree.tar -C extract + check_dir extract af b b/bf b/c b/c/cf +' If git-archive fails, the subsequent 'cd ..' will not be invoked, hence all tests following this one will fail since the current directory has not been restored. If you place the 'cd a' in a subshell, then the current directory remains unchanged for commands outside the subshell (and you can drop the 'cd ..'): ( cd a git archive ... ) make_dir ... ... Thanks, and please indent the commands run in the subshell for better readability. -- 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
Branching workflow
Hi, I have been using a very basic workflow for branching, features each in a branch. My branches would be: - develop = Main upstream branch - feature/* fix/* = Feature and fix branches - master = Integration of the whole feature and fix branches So I have now came up with a very difficult task. I just discovered that one of those branches, lest call it feature/bad, is evil and is making the integration branch (master) fail horribly. In my workflow, I tend to merge develop (official updates) into my feature branches, and them into master. So now I have the big problem on how to undo all changes from feature/fix. I have been told that one alternative workflow would be to revert the last merge and remerge it into master, so that I have always just one commit to revert if necessary (instead of the monstrous quantity I have now to). The workflow proposal should be in order of importance: - Let me stay up-to-date with develop branch - Easy to revert in master - Have a clean history - Easy to follow I think I should be capable of doing some sort of merge/rebase branching workflow to avoid having to do that. I have thought about rebasing always the feature branches, and rebasing master into all of them, but it seems pretty strange to me. If anyone can give any advice, I would fully appreciate! Javier Domingo Cansino -- 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 10/21] pack-bitmap: add support for bitmap indexes
On Tue, Dec 03, 2013 at 03:40:41PM +0100, Karsten Blees wrote: IMO, trying to improve khash isn't worth the trouble. With smaller-than-pointer types, khash _may_ actually save a few bytes compared to hash.[ch] or hashmap.[ch]. E.g. a set of 'int's would be a perfect use case for khash. However, you're using bitmaps for that, and khash's predefined macros for int sets and maps have been removed from the git version. True, we are not using it for smaller-than-pointer sizes here. So it may not be worth thinking about (I was considering more for the general case). In most instances, though, we can shove the int bits into a pointer with the right casting. So it probably isn't worth worrying about (you may waste a few bytes, but probably not more than one word per entry). Using khash with pointers and larger-than-pointer types is just a waste of memory and performance, though. Hash tables are sparsely filled by design, and using large types means lots of large empty buckets. E.g. kh_resize requires almost four times the size or your data, and copies everything at least three times. I think the analysis is more complicated than that, and depends on what you are storing. If you are storing something that is 1.5 times the size of a pointer, it is more space efficient to just stick it in the hash table than it is to have a separate pointer in the hash table (you pay the load factor penalty only on the single pointer, but you've almost doubled your total storage). But again, that's a more general argument. We're not storing anything of that size here, and in fact I think we are just storing pointers everywhere. Additionally, there are the obvious problems with khash's macro design (hard to read, impossible to debug, and each named instance increases executable size by ~4k). Yes, those are all downsides to macros. Type safety is one of the upsides, though. Besides macros, I think the major difference between the two implementations is open-addressing versus chaining. Especially for sets, we've had good experiences with open-addressing by keeping the load factor low (e.g., the one in object.c). As you note, the resizing operation pays some penalty, but in most of our workloads it's largely irrelevant compared to lookup times. Chaining typically adds an extra layer of pointer-following to the lookup, and I'd be worried about that loss of locality. It's true that when you are storing a pointer you are already hurting locality to follow the pointer to the key, but I don't know whether that means an _extra_ layer doesn't still hurt more (and I really mean I don't know -- I'd be interested to see measurements). In your implementation, it looks like you break even there because you store the hash directly in the entry, and do a single-word compare (so you avoid having to follow a pointer to the key in the common case during lookup). But that also means you're paying extra to store the hash. That probably makes sense for things like strings, where it takes some effort to calculate the hash. But not necessarily for sha1s, where looking at the hash is the same thing as looking at the key bytes (so you are storing extra bytes, and when you do have a hit on the stored hash, which is just the first bytes of the sha1, you end up comparing them again as part of the hashcmp. The tradeoff is that in the non-matching cases, you avoid an extra level of indirection). All of these are things I could see helping or hurting, depending on the case. I'd really love to see more numbers. I tried timing your patch below, but there was no interesting change. Mostly because the code path you changed is not heavily exercised (the ext_index is for objects that are not in the pack, and frequent packing keeps that number low). I'd be really interested to see if you could make the hash in object.c faster. That one is a prominent lookup bottle-neck (e.g., for git rev-list --objects --all); if you can make that faster, I would be very convinced that your implementation is fast (note that I am not implying the converse; if you cannot make it faster, that does not necessarily mean your implementation sucks, but perhaps only that the existing one has lots of type-specific optimizations which add up). Khash also has a lot of bloat (e.g., flags) that the one in object.c does not have. If you do not care about deletion and are storing something with a sentinel value (e.g., NULL for pointers), you can trim quite a bit of fat. Below is a patch that converts pack-bitmap.c to hashmap. Its not even longer than the khash version, and the hashmap API forces you to think about no-brainer improvements such as specifying an expected size or skipping duplicates checks where they aren't needed. I could do the same for pack-bitmap-write.c if you like. If it's not too much trouble, I'd be curious to measure the performance impact on pack-bitmap-write. Removes two unnecessary duplicates checks: - we don't expect a pack index file to
Re: [PATCH 1/1] tests: fix gzip with exported GZIP variable in environment
Jeff King p...@peff.net writes: There are a few options I see: 1. Drop $GZIP variable, and hard-code the prerequisite check to gzip, which is what is being tested. 2. Keep $GZIP (but rename it to $GIT_GZIP), and explicitly set up tar.tgz.command as $GIT_GZIP -cn. 3. Teach the Makefile a knob to set the value for gzip at compile time, and use that for the baked-in config (and propagate it to the test to check the prerequisite). I think I'd be in favor of (1). It's the simplest, and we have not seen any reports of people who do not actually have gzip called gzip. Users can still override it via config if they really want to. I am OK with (1). A related tangent is that we may have to worry about is how/if a random setting coming from GZIP in the environment (e.g. GZIP=-1v) would interfere with the test. It may be the simplest to unset $GZIP at the beginning of these tests, regardless of which of the above three is taken. -- 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: Re: [PATCH] Improvements to git-archive tests and add_submodule_odb()
On Mon, Dec 02, 2013 at 04:14:37PM -0800, Nick Townsend wrote: diff --git a/submodule.c b/submodule.c index 1905d75..1ea46be 100644 --- a/submodule.c +++ b/submodule.c @@ -143,7 +143,7 @@ void stage_updated_gitmodules(void) die(_(staging updated .gitmodules failed)); } -static int add_submodule_odb(const char *path) +int add_submodule_odb(const char *path) I am not against making add_submodule_odb() usable from outside submodule.c but I would prefer if this change goes along with some code actually using it. The reason being that when refactoring or extending you immediately know that a function is file local only with the static keyword. Without anyone using this function from outside submodule.c this fact is still true and so the code should say, IMO. Its not a big deal to postpone removing this keyword in a later commit so I would like to drop this change from the patch. The documentation fix is fine with me. Cheers Heiko -- 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] path_treatment: also ignore $GIT_DIR if it's not .git
Karsten Blees karsten.bl...@gmail.com writes: So I figure that GIT_DIR is not meant to _rename_ the .git dir, but to point somewhere _outside_ the worktree (or somewhere within the .git dir). Correct. If we don't want to support this, though, I think it would be more approrpiate to issue a warning if GIT_DIR points to a worktree location. But how do tell what is and isn't a worktree location? Having the path in the index would be one, but you may find it out only after issuing git checkout $antient_commit. -- 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: Re: [PATCH] submodule recursion in git-archive
Hi, On Mon, Dec 02, 2013 at 03:55:36PM -0800, Nick Townsend wrote: On 29 Nov 2013, at 14:38, Heiko Voigt hvo...@hvoigt.net wrote: FYI, I already started to implement this lookup of submodule paths early this year[1] but have not found the time to proceed on that yet. I am planning to continue on that topic soonish. We need it to implement a correct recursive fetch with clone on-demand as a basis for the future recursive checkout. During the work on this I hit too many open questions. Thats why I am currently working on a complete plan[2] so we can discuss and define how this needs to be implemented. It is an asciidoc document which I will send out once I am finished with it. Cheers Heiko [1] http://article.gmane.org/gmane.comp.version-control.git/217020 [2] https://github.com/hvoigt/git/wiki/submodule-fetch-config It seems to me that the question that you are trying to solve is more complex than the problem I faced in git-archive, where we have a single commit of the top-level repository that we are chasing. Perhaps we should split the work into two pieces: a. Identifying the complete submodule configuration for a single commit, and b. the complexity of behaviour when fetching and cloning recursively (which of course requires a.) You are right the latter (b) is a separate topic. So how about I extract the submodule config parsing part from the mentioned patch and you can then use that patch as a basis for your work? As far as I understand you only need to parse the .gitmodules file for one commit and then lookup the submodule names from paths right? That would simplify matters and we can postpone the caching of multiple commits for the time when I continue on b. I’m very happy to work on the first, but the second seems to me to require more understanding than I currently possess. In order to do this it would help to have a place to discuss this. I see you have used the wiki of your fork of git on GitHub. Is that the right place to solicit input? I only used that to collect all information into one place. I am not sure if thats actually necessary for the .gitmodules parsing you need. I think we should discuss everything related to the design and patches here on the list. If you have questions regarding my code I am also happy to answer that via private mail. Cheers Heiko -- 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] Improvements to git-archive tests and add_submodule_odb()
Heiko Voigt hvo...@hvoigt.net writes: On Mon, Dec 02, 2013 at 04:14:37PM -0800, Nick Townsend wrote: diff --git a/submodule.c b/submodule.c index 1905d75..1ea46be 100644 --- a/submodule.c +++ b/submodule.c @@ -143,7 +143,7 @@ void stage_updated_gitmodules(void) die(_(staging updated .gitmodules failed)); } -static int add_submodule_odb(const char *path) +int add_submodule_odb(const char *path) I am not against making add_submodule_odb() usable from outside submodule.c but I would prefer if this change goes along with some code actually using it. The reason being that when refactoring or extending you immediately know that a function is file local only with the static keyword. Without anyone using this function from outside submodule.c this fact is still true and so the code should say, IMO. Its not a big deal to postpone removing this keyword in a later commit so I would like to drop this change from the patch. The documentation fix is fine with me. OK, thanks, then let's do this. -- 8 -- From: Nick Townsend nick.towns...@mac.com Date: Mon, 25 Nov 2013 15:31:09 -0800 Subject: [PATCH] ref-iteration doc: add_submodule_odb() returns 0 for success The usage sample of add_submodule_odb() function in the Submodules section expects non-zero return value for success, but the function actually reports success with zero. Helped-by: René Scharfe l@web.de Reviewed-by: Heiko Voigt hvo...@hvoigt.net Signed-off-by: Nick Townsend nick.towns...@mac.com --- Documentation/technical/api-ref-iteration.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/api-ref-iteration.txt b/Documentation/technical/api-ref-iteration.txt index aa1c50f..02adfd4 100644 --- a/Documentation/technical/api-ref-iteration.txt +++ b/Documentation/technical/api-ref-iteration.txt @@ -50,10 +50,10 @@ submodules object database. You can do this by a code-snippet like this: const char *path = path/to/submodule - if (!add_submodule_odb(path)) + if (add_submodule_odb(path)) die(Error submodule '%s' not populated., path); -`add_submodule_odb()` will return an non-zero value on success. If you +`add_submodule_odb()` will return zero on success. If you do not do this you will get an error for each ref that it does not point to a valid object. -- 1.8.5-262-g1a2486c -- 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: Branching workflow
On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote: I have been using a very basic workflow for branching, features each in a branch. My branches would be: - develop = Main upstream branch - feature/* fix/* = Feature and fix branches - master = Integration of the whole feature and fix branches So I have now came up with a very difficult task. I just discovered that one of those branches, lest call it feature/bad, is evil and is making the integration branch (master) fail horribly. In my workflow, I tend to merge develop (official updates) into my feature branches, and them into master. So now I have the big problem on how to undo all changes from feature/fix. I have been told that one alternative workflow would be to revert the last merge and remerge it into master, so that I have always just one commit to revert if necessary (instead of the monstrous quantity I have now to). The workflow proposal should be in order of importance: - Let me stay up-to-date with develop branch - Easy to revert in master - Have a clean history - Easy to follow I think I should be capable of doing some sort of merge/rebase branching workflow to avoid having to do that. I have thought about rebasing always the feature branches, and rebasing master into all of them, but it seems pretty strange to me. If anyone can give any advice, I would fully appreciate! It sounds like you want a throwaway integration branch. This is similar to the workflow Junio uses with git.git's pu branch, which involves rebuilding a branch by: * resetting it to some base (develop in your case) * merging in the required feature branches This may not quite be what you want because it does mean that you cannot build on the integration branch - it is intended to be rewritten often, but it does provide a good platform for testing features and then merging them to a stable branch once they have proved to be good. The advantage is that you know that the integration merges are temporary and you can test on top of that without having set the result in stone. shameless plugIf you are interested in such a workflow then you may want to try my git-integration program [1] to manage integration branches. There is also a reimplementation in Ruby with a slightly different feature set [2] [1] http://johnkeeping.github.io/git-integration [2] http://github.com/felipec/git-reintegrate -- 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 2/3] gitweb: Add a feature for adding more branch refs
Krzesimir Nowak krzesi...@endocode.com writes: Allow extra-branch-refs feature to tell gitweb to show refs from additional hierarchies in addition to branches in the list-of-branches view. Signed-off-by: Krzesimir Nowak krzesi...@endocode.com Reviewed-by: Junio C Hamano gits...@pobox.com Please do not add Reviewed-by: like this; I've never reviewed this version of the patch. These are to be added only when you re-send, for final application, the version as exactly reviewed, or adjusted a previous version you got reviewed in a way that match suggestions given by reviewers. Reviewed-by: Jakub Narębski jna...@gmail.com Reviewed-by: Eric Sunshine sunsh...@sunshineco.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
Segfault when fetching from current git.git on GitHub
Hi, I've fetched from the current git.git on GitHub minutes ago and got a segfault. I could reproduce it with the Git version of the current next branch (1.8.5.392.gf545f4d) with the steps below. The segfault does not appear with version 1.8.5. Steps to reproduce: git init tmp cd tmp git remote add origin https://github.com/git/git.git git fetch -v Full stacktrace: http://pastebin.com/zK8epKWj ProcMaps and ProcStatus from Ubuntu's Apport: http://pastebin.com/ZpPk1WSA Ralf -- 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] path_treatment: also ignore $GIT_DIR if it's not .git
Am 03.12.2013 19:32, schrieb Junio C Hamano: Karsten Blees karsten.bl...@gmail.com writes: So I figure that GIT_DIR is not meant to _rename_ the .git dir, but to point somewhere _outside_ the worktree (or somewhere within the .git dir). Correct. If we don't want to support this, though, I think it would be more approrpiate to issue a warning if GIT_DIR points to a worktree location. But how do tell what is and isn't a worktree location? Having the path in the index would be one, but you may find it out only after issuing git checkout $antient_commit. In setup_work_tree(), the result of remove_leading_path(git_dir, work_tree) must be absolute or start with .. or .git, otherwise warn? -- 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/3] gitweb: Move check-ref-format code into separate function
Krzesimir Nowak krzesi...@endocode.com writes:
This check will be used in more than one place later.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Reviewed-by: Jakub Narębski jna...@gmail.com
Reviewed-by: Eric Sunshine sunsh...@sunshineco.com
---
gitweb/gitweb.perl | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 68c77f6..f7730d7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1452,6 +1452,16 @@ sub validate_pathname {
return $input;
}
+sub check_ref_format {
+ my $input = shift || return undef;
+
+ # restrictions on ref name according to git-check-ref-format
+ if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
+ return undef;
+ }
+ return $input;
+}
+
sub validate_refname {
my $input = shift || return undef;
@@ -1462,10 +1472,9 @@ sub validate_refname {
# it must be correct pathname
$input = validate_pathname($input)
or return undef;
- # restrictions on ref name according to git-check-ref-format
- if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
- return undef;
- }
So far, so good.
+ # check git-check-ref-format restrictions
+ $input = check_ref_format($input)
+ or return undef;
return $input;
Hmmm. Why do you need LFINDENTor return under here? It would
not hurt too much per-se (strictly speaking, if the $input were a
string 0, this will return undef instead of 0, which should be
an OK name as far as the regexp is concerned), but it seems to be
making the logic unnecessarily complex for no real gain.
}
--
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] path_treatment: also ignore $GIT_DIR if it's not .git
Junio C Hamano wrote: Karsten Blees karsten.bl...@gmail.com writes: If we don't want to support this, though, I think it would be more approrpiate to issue a warning if GIT_DIR points to a worktree location. But how do tell what is and isn't a worktree location? Having the path in the index would be one, but you may find it out only after issuing git checkout $antient_commit. I think the idea was that *any* path under $(git rev-parse --show-toplevel) would not be a valid GIT_DIR, unless its last path component is .git. Alas, I don't think that would work smoothly. - Some people may already be using GIT_DIR=$HOME/dotfiles.git to track some files with a toplevel of $HOME. That is error-prone and it would be cleaner to either use plain .git or keep the $GIT_DIR outside the worktree (for example by tucking dotfiles into a separate $HOME/dotfiles dir), true, but producing a noisy warning with no way out would not serve these people well. - There is no outside-the-worktree location when GIT_WORK_TREE=/. So your suggestion of at least noticing when git checkout wants to write files that overlap with the GIT_DIR seems simpler. -- 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: Branching workflow
Hi John!, Thanks a lot for your tip, but I have the problem that I would need to have a linear history in master (forgot to mention it explicitly) ;( I build on master branch, and getting to a previous version is hereby needed. I had thought about the revert workflow, but using --no-commit. I would then have a way to mark stuff as re-mergeable. I am pretty lost with this. Is like a non-ending hell, because I have to provide linear history to master and develop, and allowing master to be revertable. Isn't there something like git revert branch-name so that all commits that have been merged from that branch, and don't belong to any other, can be reverted? With this history: A-B-C := develop B-D-Z-Y := feature/bad B-D-G-H := feature/good A-B-C-z-g-y-h := master (caps original commits, regular merged commits) so that: git checkout master git revert feature/bad would revert z and h in master history, in one single commit, and making available merging feature/bad when it's ready, with all conflicting if needed. Ideas welcome =) Javier Domingo Cansino 2013/12/3 John Keeping j...@keeping.me.uk: On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote: I have been using a very basic workflow for branching, features each in a branch. My branches would be: - develop = Main upstream branch - feature/* fix/* = Feature and fix branches - master = Integration of the whole feature and fix branches So I have now came up with a very difficult task. I just discovered that one of those branches, lest call it feature/bad, is evil and is making the integration branch (master) fail horribly. In my workflow, I tend to merge develop (official updates) into my feature branches, and them into master. So now I have the big problem on how to undo all changes from feature/fix. I have been told that one alternative workflow would be to revert the last merge and remerge it into master, so that I have always just one commit to revert if necessary (instead of the monstrous quantity I have now to). The workflow proposal should be in order of importance: - Let me stay up-to-date with develop branch - Easy to revert in master - Have a clean history - Easy to follow I think I should be capable of doing some sort of merge/rebase branching workflow to avoid having to do that. I have thought about rebasing always the feature branches, and rebasing master into all of them, but it seems pretty strange to me. If anyone can give any advice, I would fully appreciate! It sounds like you want a throwaway integration branch. This is similar to the workflow Junio uses with git.git's pu branch, which involves rebuilding a branch by: * resetting it to some base (develop in your case) * merging in the required feature branches This may not quite be what you want because it does mean that you cannot build on the integration branch - it is intended to be rewritten often, but it does provide a good platform for testing features and then merging them to a stable branch once they have proved to be good. The advantage is that you know that the integration merges are temporary and you can test on top of that without having set the result in stone. shameless plugIf you are interested in such a workflow then you may want to try my git-integration program [1] to manage integration branches. There is also a reimplementation in Ruby with a slightly different feature set [2] [1] http://johnkeeping.github.io/git-integration [2] http://github.com/felipec/git-reintegrate -- 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: Branching workflow
Javier Domingo javier...@gmail.com writes: Hi, I have been using a very basic workflow for branching, features each in a branch. My branches would be: - develop = Main upstream branch - feature/* fix/* = Feature and fix branches - master = Integration of the whole feature and fix branches So I have now came up with a very difficult task. I just discovered that one of those branches, lest call it feature/bad, is evil and is making the integration branch (master) fail horribly. In my workflow, I tend to merge develop (official updates) into my feature branches, and them into master. I think the standard advice is not to contaminate feature branches with unrelated changes, whether from an upstream updates or from other unrelated feature breanches. You would still want to make sure that your feature branches in work-in-progress state would work with updated upstream from time to time, but that is much better done by having a test integration branch you maintain with: : always start from the tip of upstream $ git fetch upstream $ git checkout -B develop remotes/upstream/master : merge everything you want $ git merge feature/A $ git merge feature/B ... $ git merge fix/Z And you will never merge 'develop' into 'master'. Only after you are satisfied with a single feature (or fix), you merge that to 'master', while your other features may still be suspect. -- 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: Segfault when fetching from current git.git on GitHub
Hi, Ralf Thielow wrote: I've fetched from the current git.git on GitHub minutes ago and got a segfault. I could reproduce it with the Git version of the current next branch (1.8.5.392.gf545f4d) with the steps below. The segfault does not appear with version 1.8.5. Yep, I can reproduce this. (gdb) bt #0 next_quote_pos (s=0x0, maxlen=-1) at quote.c:168 #1 0x004ca2bb in quote_c_style_counted (name=0x0, maxlen=-1, sb=0x7fffe290, fp=0x0, no_dq=0) at quote.c:215 #2 0x004fd4c0 in set_helper_option (transport=optimized out, name=0x525f89 depth, value=0x0) at transport-helper.c:307 #3 0x004fb57f in transport_set_option (transport=0x7d5740, name=optimized out, value=0x0) at transport.c:1004 #4 0x0042de10 in backfill_tags (ref_map=0x806a50, transport=0x7d5740) at builtin/fetch.c:791 It's fallout from 0f284b11 (transport: catch non positive --depth option value, 2013-11-26). -- 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: Branching workflow
I will start to rebase all feature branches because I have no real dependency on those, but master needs to have a linear history, as I build from it regularly, and I need to assure that people can get a previous version of master. The problem with that is that I wouldn't be able to have a linear history on master. I had also thought about doing a snapshot branch of the integration branch, so that I could maintain history of integration, and just update it with integration snapshots, but I am trying to get another more git-ish way to achieve all these requirements of all branches (they are really driving me crazy). Thanks a lot for the idea. I will mantain clean feature branches from now on, Javier Domingo Cansino -- 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: Ideas to speed up repacking
Martin Fick mf...@codeaurora.org writes: * Setup 1: Do a full repack. All loose and packed objects are added ... * Scenario 1: Start with Setup 1. Nothing has changed on the repo contents (no new object/packs, refs all the same), but repacking config options have changed (for example compression level has changed). On Tuesday, December 03, 2013 10:50:07 am Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: Reading Martin's mail again I wonder how we just grab all objects and skip history traversal. Who will decide object order in the new pack if we don't traverse history and collect path information. I vaguely recall raising a related topic for quick repack, assuming everything in existing packfiles are reachable, that only removes loose cruft several weeks ago. Once you decide that your quick repack do not care about ejecting objects from existing packs, like how I suspect Martin's outline will lead us to, we can repack the reachable loose ones on the recent surface of the history and then concatenate the contents of existing packs, excluding duplicates and possibly adjusting the delta base offsets for some entries, without traversing the bulk of the history. From this, it sounds like scenario 1 (a single pack being repacked) might then be doable (just trying to establish a really simple baseline)? Except that it would potentially not result in the same ordering without traversing history? Or, would the current pack ordering be preserved and thus be correct? -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: slow git-cherry-pick.
On Monday 25 of November 2013 09:26:40 Junio C Hamano wrote: Paweł Sikora pawel.sik...@agmk.net writes: On Sunday 24 of November 2013 19:47:10 Duy Nguyen wrote: On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora pawel.sik...@agmk.net wrote: i've recently reinstalled a fresh system (fc20-beta) on my workstation and observing a big slowdown on git cherry-pick operation (git-1.8.4.2-1). the previous centos installation with an old git version works faster (few seconds per cherry pick). now the same operation takes 1 min. What is the git version before the reinstallation? git-1.7.11.3-1.el5.rf. i've checked this version on another machine with centos-5.$latest and it does similar amout of stat/read operation quickly (~6s). this fast centos-5 machine has /home on raid-0 (2x500GB) while my slow (1min) workstation has /home on linear lvm (250G+1T). so, i suppose that my slow working copy crosses disks boundary or spread over 1TB drive and the random git i/o impacts performance. the question still remains - does the git need to scan whole checkout during picking well defined set of files? We do update-index to see what local changes you have upfront in order to avoid stomping on them (and we do not know upfront what paths the cherry-picked commit would change, given that there may be renames involved), so the answer is unfortunately yes, we would need to do lstat(2) the whole thing. this is quite weird for me (user). git pull also fetches objects from server and aborts user's action if working copy contains uncommitted modifications on files that will be modified by incoming objects. from the other side, the cherry-pick needs to stat() the whole working copy to achieve similar precondition. looks like suboptimal implementation. Doing that lstat(2) more lazily and do away with the update-index might be possible, but I suspect that may be quite a lot of work. maybe you can use the existing implementation used by 'pull' ? -- gpg key fingerprint = 60B4 9886 AD53 EB3E 88BB 1EB5 C52E D01B 683B 9411 -- 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/3] gitweb: Move check-ref-format code into separate function
On Tue, Dec 3, 2013 at 8:02 PM, Junio C Hamano gits...@pobox.com wrote:
Krzesimir Nowak krzesi...@endocode.com writes:
+sub check_ref_format {
+ my $input = shift || return undef;
+
+ # restrictions on ref name according to git-check-ref-format
+ if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
+ return undef;
+ }
+ return $input;
+}
[...]
@@ -1462,10 +1472,9 @@ sub validate_refname {
# it must be correct pathname
$input = validate_pathname($input)
or return undef;
- # restrictions on ref name according to git-check-ref-format
- if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
- return undef;
- }
So far, so good.
+ # check git-check-ref-format restrictions
+ $input = check_ref_format($input)
+ or return undef;
return $input;
Hmmm. Why do you need LFINDENTor return under here? It would
not hurt too much per-se (strictly speaking, if the $input were a
string 0, this will return undef instead of 0, which should be
an OK name as far as the regexp is concerned), but it seems to be
making the logic unnecessarily complex for no real gain.
I think this simply follows $input = validate_sth($input) or return undef;
pattern used in this area of gitweb code (perhaps mis-used).
Stricly speaking pure refactoring (no functional change, e.g. no assign
to $input) would be check_ref_format($input) or return undef;, or even
return check_ref_format($input); if we keep check_ref_format() passthru
on valid refname.
--
Jakub Narebski
--
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/3] gitweb: Move check-ref-format code into separate function
Jakub Narębski jna...@gmail.com writes: Stricly speaking pure refactoring (no functional change, e.g. no assign to $input) would be check_ref_format($input) or return undef;, or even return check_ref_format($input); if we keep check_ref_format() passthru on valid refname. Exactly. -- 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: [BUG] Core dump w/ bus error on bad mmap'd packfile
Amit Bakshi ambak...@gmail.com writes: I was getting core dumps (bus error 7) with git 1.7.1 when doing a git checkout. I tried git fsck, and same thing. I got the same with precompiled rpms of 1.7.12, and with a locally compiled version of git 1.8.5. [...] $ git fsck Checking pack-0ccb5ee4f60003a7ea47d6904633cce5973efa60.pack in: 0x7f9070507000 remain: 17345210 offset: 17345230 Bus error (core dumped) git verify-pack correctly shows the error, without a bus error. $ git verify-pack -v pack-0ccb5ee4f60003a7ea47d6904633cce5973efa60.pack fatal: read error on input: Input/output error pack-0ccb5ee4f60003a7ea47d6904633cce5973efa60.pack: bad mmap()ing a file and attempting to read from parts that the kernel can then not page in (in your case because it couldn't read the file) are expected to give a SIGBUS, so there is no bug here. The different behavior comes from some commands using mmap() and some using read() to access the packs. Perhaps we could try to map the faulting address back to the file it came from, though. The siginfo_t for a SIGBUS contains information about the faulting address, so for the case of packs we could walk the 'struct packed_git' list and see which open window the address belongs to. I need to think about the implications of doing that in a signal handler, though. -- Thomas Rast t...@thomasrast.ch -- 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] gitk: chmod +x po2msg
Junio C Hamano gits...@pobox.com writes: * Paul, I forgot to forward this to you. Could you apply it to your tree? I see you have updates up to ce2c58cd (gitk: Recognize -L option, 2013-11-16), which I'll be pulling into my tree shortly. When you pull, can you pick up the other half of the series that led up to ce2c58cd? http://thread.gmane.org/gmane.comp.version-control.git/227151/focus=237937 -- Thomas Rast t...@thomasrast.ch -- 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/RESEND] transport.c: mark push status strings for translation
Nguyễn Thái Ngọc Duy wrote:
Mark strings like [up to date] passed to print_ref_status() for
translation with N_() instead of _() so they can remain untranslated
in porcelain mode.
Makes sense.
[...]
--- a/builtin/push.c
+++ b/builtin/push.c
Perhaps it would make sense to send these as a separate patch, since
they are simpler than the rest.
[...]
--- a/transport.c
+++ b/transport.c
@@ -14,6 +14,7 @@
#include url.h
#include submodule.h
#include string-list.h
+#include utf8.h
/* rsync support */
@@ -627,16 +628,23 @@ static void print_ref_status(char flag, const char
*summary, struct ref *to, str
else
fprintf(stdout, %s\n, summary);
} else {
- fprintf(stderr, %c %-*s , flag, TRANSPORT_SUMMARY_WIDTH,
summary);
+ int width = TRANSPORT_SUMMARY_WIDTH;
+ const char *localized_summary = _(summary);
The summary arg comes from one of a few places:
(a) [deleted] etc from print_ok_ref_status, which you marked
with N_ (good)
(b) deadbe... from status_abbrev via print_ok_ref_status. Can we
avoid passing it to gettext()?
(c) [no match] etc from print_one_push_status, marked with
N_ (good)
I am tempted to suggest something like
const char *localized_summary;
if (*summary != '[')
/* Leave abbreviated sha1 from status_abbrev() alone */
localized_summary = summary;
else
localized_summary = _(summary);
but that's kind of ugly. Is there a simpler way? Should the summary
arg be passed in already localized (with 'porcelain' handling higher
up)?
Thanks,
Jonathan
--
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: slow git-cherry-pick.
Paweł Sikora pawel.sik...@agmk.net writes:
Umm, there's a gem here that the thread missed so far:
my git repo isn't very big[1] but it's checked out on the linear lvm
where random i/o generally hurts and strace shows that current git version
performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before
^
There's no reason why it should do the lstat() *twice* for every file.
But Paweł is right; the code path roughly goes like this:
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
[...]
res = sequencer_pick_revisions(opts);
int sequencer_pick_revisions(struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
[...]
return pick_commits(todo_list, opts);
}
static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
I'm too tired to dig further, but AFAICT it's just a rather obvious case
of duplication of effort.
--
Thomas Rast
t...@thomasrast.ch
--
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 2/3] gitweb: Add a feature for adding more branch refs
Krzesimir Nowak krzesi...@endocode.com writes:
@@ -626,6 +640,17 @@ sub feature_avatar {
return @val ? @val : @_;
}
+sub feature_extra_branch_refs {
+ my (@branch_refs) = @_;
+ my $values = git_get_project_config('extra_branch_refs');
Hmph. Three points.
* Almost all callers of this function use
my ($val) = git_get_project_config(...);
my @val = git_get_project_config(...);
to expect that the function returns a list of things (and grab the
first one among them, not the length of the list). Shoudln't this
part do the same?
* Wouldn't this be a good candidate for a multi-valued configuration
variable, e.g. shouldn't this
[gitweb]
extraBranchRefs = wip
extraBranchRefs = sandbox other
be parsed as a three-item list, qw(wip sandbox other)?
* I think the $key parameter to git_get_project_config() eventually
is used to look up a key in the Git-style configuration file, and
the 'words_with_underscore' goes against our convention (cf. see
how 'show-sizes' feature is spelled as 'showsizes' there).
+ if ($values) {
+ @branch_refs = split /\s+/, $values;
+ }
+
+ return @branch_refs;
+}
--
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 jk/remove-deprecated] stop installing git-tar-tree link
On Mon, Dec 02, 2013 at 03:37:10PM -0800, Jonathan Nieder wrote:
When the built-in git tar-tree command (a thin wrapper around git
archive) was removed in 925ceccf (tar-tree: remove deprecated
command, 2013-11-10), the build continued to install a non-functioning
git-tar-tree command in gitexecdir by mistake:
$ PATH=$(git --exec-path):$PATH
$ git-tar-tree -h
fatal: cannot handle tar-tree internally
The list of links in gitexecdir is populated from BUILTIN_OBJS, which
includes builtin/tar-tree.o to implement git get-tar-commit-id.
Rename the get-tar-commit-id source file to builtin/get-tar-commit-id.c
to reflect its purpose and fix 'make install'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi,
John Keeping wrote:
builtin/tar-tree.c | 62 -
Here's a quick fixup on top. Thoughts?
This is the obvious tidy-up on top of my series. I avoided doing it
because I thought it would just add unnecessary noise, but I had not
realised that the names of the built-in object files was important, so
it's not just noise but a part of doing the job properly.
Makefile| 3 +--
builtin/{tar-tree.c = get-tar-commit-id.c} | 0
2 files changed, 1 insertion(+), 2 deletions(-)
rename builtin/{tar-tree.c = get-tar-commit-id.c} (100%)
diff --git a/Makefile b/Makefile
index 504931f..37beb73 100644
--- a/Makefile
+++ b/Makefile
@@ -586,7 +586,6 @@ BUILT_INS += git-cherry$X
BUILT_INS += git-cherry-pick$X
BUILT_INS += git-format-patch$X
BUILT_INS += git-fsck-objects$X
-BUILT_INS += git-get-tar-commit-id$X
BUILT_INS += git-init$X
BUILT_INS += git-merge-subtree$X
BUILT_INS += git-show$X
@@ -929,6 +928,7 @@ BUILTIN_OBJS += builtin/fmt-merge-msg.o
BUILTIN_OBJS += builtin/for-each-ref.o
BUILTIN_OBJS += builtin/fsck.o
BUILTIN_OBJS += builtin/gc.o
+BUILTIN_OBJS += builtin/get-tar-commit-id.o
BUILTIN_OBJS += builtin/grep.o
BUILTIN_OBJS += builtin/hash-object.o
BUILTIN_OBJS += builtin/help.o
@@ -980,7 +980,6 @@ BUILTIN_OBJS += builtin/show-ref.o
BUILTIN_OBJS += builtin/stripspace.o
BUILTIN_OBJS += builtin/symbolic-ref.o
BUILTIN_OBJS += builtin/tag.o
-BUILTIN_OBJS += builtin/tar-tree.o
BUILTIN_OBJS += builtin/unpack-file.o
BUILTIN_OBJS += builtin/unpack-objects.o
BUILTIN_OBJS += builtin/update-index.o
diff --git a/builtin/tar-tree.c b/builtin/get-tar-commit-id.c
similarity index 100%
rename from builtin/tar-tree.c
rename to builtin/get-tar-commit-id.c
--
1.8.4.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: Fwd: [PATCH 4/5] Replace {pre,suf}fixcmp() with {starts,ends}_with()
On Tue, Dec 3, 2013 at 1:46 PM, Jeff King p...@peff.net wrote: This made it through to me, but not the list. There are at least two things going on: 1. The message is 172K, which is over the 100K limit imposed by vger; the list is silently dropping it. 2. In my case, the direct mail was being flagged by spam because it contains the blacklisted domain old.name. Which of course is not a domain at all but rather this code: old.name = old.path + strlen(refs/heads/); I've tweaked my server. I can't say why it wasn't getting to Junio via direct mail. Maybe the same spam thing, or maybe something else. [...] I skimmed the patch and didn't notice any problems. It's whitespace-damaged by gmail, of course. The simplest thing is probably to just point us at a public repo with the commit, if you have one. Ok, the commit is in the use_starts_ends_with branch on this github repo: https://github.com/chriscool/git.git Thanks, Christian. -- 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 2/3] gitweb: Add a feature for adding more branch refs
On Tue, Dec 3, 2013 at 9:15 PM, Junio C Hamano gits...@pobox.com wrote:
Krzesimir Nowak krzesi...@endocode.com writes:
@@ -626,6 +640,17 @@ sub feature_avatar {
return @val ? @val : @_;
}
+sub feature_extra_branch_refs {
+ my (@branch_refs) = @_;
+ my $values = git_get_project_config('extra_branch_refs');
Hmph. Three points.
* Almost all callers of this function use
my ($val) = git_get_project_config(...);
my @val = git_get_project_config(...);
to expect that the function returns a list of things (and grab the
first one among them, not the length of the list). Shouldn't this
part do the same?
Right. feature_snapshot() has here
my (@fmts) = @_;
my ($val) = git_get_project_config('snapshot');
...though git_get_project_config returns scalar.
* Wouldn't this be a good candidate for a multi-valued configuration
variable, e.g. shouldn't this
[gitweb]
extraBranchRefs = wip
extraBranchRefs = sandbox other
be parsed as a three-item list, qw(wip sandbox other)?
This would require changes in git_get_project_config(), which would
need to be able to deal with multi-valued result (it caches these
results, so we pay only one cost of `git config` call).
* I think the $key parameter to git_get_project_config() eventually
is used to look up a key in the Git-style configuration file, and
the 'words_with_underscore' goes against our convention (cf. see
how 'show-sizes' feature is spelled as 'showsizes' there).
Errr... actually git_get_project_config() strips '_' from $key, though
not for some strange reason '-'.
BTW. though it is 'showsizes' in code, it usually is 'showSizes' in
config file (camelCase convention, lowercased by git-config).
+ if ($values) {
+ @branch_refs = split /\s+/, $values;
+ }
+
+ return @branch_refs;
+}
--
Jakub Narebski
--
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: Re* [PATCH] Improvements to git-archive tests and add_submodule_odb()
Hi, On Tue, Dec 03, 2013 at 10:39:36AM -0800, Junio C Hamano wrote: OK, thanks, then let's do this. Yes, sounds good. Cheers Heiko -- 8 -- From: Nick Townsend nick.towns...@mac.com Date: Mon, 25 Nov 2013 15:31:09 -0800 Subject: [PATCH] ref-iteration doc: add_submodule_odb() returns 0 for success The usage sample of add_submodule_odb() function in the Submodules section expects non-zero return value for success, but the function actually reports success with zero. Helped-by: René Scharfe l@web.de Reviewed-by: Heiko Voigt hvo...@hvoigt.net Signed-off-by: Nick Townsend nick.towns...@mac.com --- Documentation/technical/api-ref-iteration.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/api-ref-iteration.txt b/Documentation/technical/api-ref-iteration.txt index aa1c50f..02adfd4 100644 --- a/Documentation/technical/api-ref-iteration.txt +++ b/Documentation/technical/api-ref-iteration.txt @@ -50,10 +50,10 @@ submodules object database. You can do this by a code-snippet like this: const char *path = path/to/submodule - if (!add_submodule_odb(path)) + if (add_submodule_odb(path)) die(Error submodule '%s' not populated., path); -`add_submodule_odb()` will return an non-zero value on success. If you +`add_submodule_odb()` will return zero on success. If you do not do this you will get an error for each ref that it does not point to a valid object. -- 1.8.5-262-g1a2486c -- 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/5] teach replace objects to sha1_object_info_extended()
From: Junio C Hamano gits...@pobox.com Jeff King p...@peff.net writes: On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote: I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag directly in lookup_replace_object. That means that it is now a meaningful flag for sha1_object_info_extended, even though the name does not say so. It also means that the two may have to coordinate further flags (since a portion of their flag namespace is shared by lookup_replace_object). I don't foresee adding a lot of new flags, though, so it probably isn't a huge deal. I also would have expected sha1_object_info_extended to simply receive the new flag via the struct object_info. Again, probably not a big deal, because there aren't many callsites that needed updating. But if we were not sharing flags with read_sha1_file, I think doing it as a flag in the struct would be nicer. Curious what this would look like, I wrote the patch. If you drop your patches 2 and 3, then your final patch (actually fixing the problem) would look like the one below: We may be getting into bikeshed territory, and I don't feel super-strongly about it, so I won't say anything more. Now we've seen both alternatives, and you or Junio can pick. :) Thanks for doing that. I still prefer a flag used by sha1_object_info_extended(), read_sha1_file_extended() and lookup_replace_object_extended(). I think it is more coherent this way. FWIW, I shared that a little funny feeling ;-) Yeah, it's true that I should have renamed the flag. READ_SHA1_FILE_REPLACE is too much related to the read_sha1_file*() functions. As it is related to lookup_replace_object*() functions, what about LOOKUP_REPLACE_OBJECT? Thanks, Christian. -- 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/5] teach replace objects to sha1_object_info_extended()
From: Jeff King p...@peff.net On Sat, Nov 30, 2013 at 02:51:18PM +0100, Christian Couder wrote: Here is a patch series to improve the way sha1_object_info_extended() behaves when it is passed a replaced object. Overall looks OK to me. Thanks for reviewing it. [...] I checked the resulting behavior against the list I made earlier; looks like all of the _extended callsites are doing the right thing. I do think the checks you added in 277336a (replace: forbid replacing an object with one of a different type, 2013-09-06) need updating. I started on that, but I wonder if all of cmd_replace should simply turn off read_replace_refs. I'd think it would always want to be dealing with the true objects. Yeah, I think you are right. I will have a look and probably turn off read_replace_ref in cmd_replace() as you suggest. Thanks, Christian. -- 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
[ANNOUNCE] Git v1.8.5.1
The latest maintenance release Git v1.8.5.1 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: dcd244c7198e8afe42ab223f7b3c9b1ae01749c3 git-1.8.5.1.tar.gz 16cd5fdf486aa880c4fcb297d769070c67996317 git-htmldocs-1.8.5.1.tar.gz 32befa65b564640981d71f8a38eee19939a2eb63 git-manpages-1.8.5.1.tar.gz The following public repositories all have a copy of the v1.8.5.1 tag and the maint branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Also, http://www.kernel.org/pub/software/scm/git/ has copies of the release tarballs. Git v1.8.5.1 Release Notes == Fixes since v1.8.5 -- * git submodule init copied submodule.$name.update settings from .gitmodules to .git/config without making sure if the suggested value was sensible. Changes since v1.8.5 are as follows: Junio C Hamano (3): submodule: do not copy unknown update mode from .gitmodules Git 1.8.4.5 Git 1.8.5.1 Nick Townsend (1): ref-iteration doc: add_submodule_odb() returns 0 for success -- 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] submodule: do not copy unknown update mode from .gitmodules
When submodule.$name.update is given as hint from the upstream in the .gitmodules file, we used to blindly copy it to .git/config, unless there already is a value defined for the submodule. However, there is no reason to expect that the update mode hinted by the upstream is available in the version of Git the user is using, and a really custom !cmd prepared by an upstream person running on Linux may not even be available to a user on Windows. It is simply irresponsible to copy the setting blindly and to attempt to use it during a later submodule update without validating it first. Just show the suggested value to the diagnostic output, and set the value to 'none' in the configuration, if it is not one of the ones that are known to be supported by this version of Git. Helped-by: Jens Lehmann jens.lehm...@web.de Helped-by: Jeff King p...@peff.net Signed-off-by: Junio C Hamano gits...@pobox.com --- git-submodule.sh| 20 +++- t/t7406-submodule-update.sh | 15 +++ 2 files changed, 30 insertions(+), 5 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index 2979197..83917d8 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -612,11 +612,21 @@ cmd_init() fi # Copy update setting when it is not set yet - upd=$(git config -f .gitmodules submodule.$name.update) - test -z $upd || - test -n $(git config submodule.$name.update) || - git config submodule.$name.update $upd || - die $(eval_gettext Failed to register update mode for submodule path '\$displaypath') + if upd=$(git config -f .gitmodules submodule.$name.update) + test -n $upd + test -z $(git config submodule.$name.update) + then + case $upd in + rebase | merge | none) + ;; # known modes of updating + *) + echo 2 warning: unknown update mode '$upd' suggested for submodule '$name' + upd=none + ;; + esac + git config submodule.$name.update $upd || + die $(eval_gettext Failed to register update mode for submodule path '\$displaypath') + fi done } diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index f0b3305..0825a92 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -323,6 +323,21 @@ test_expect_success 'submodule update - command in .git/config catches failure' ) ' +test_expect_success 'submodule init does not copy command into .git/config' ' + (cd super +H=$(git ls-files -s submodule | cut -d -f2) +mkdir submodule1 +git update-index --add --cacheinfo 16 $H submodule1 +git config -f .gitmodules submodule.submodule1.path submodule1 +git config -f .gitmodules submodule.submodule1.url ../submodule +git config -f .gitmodules submodule.submodule1.update !false +git submodule init submodule1 +echo none expect +git config submodule.submodule1.update actual +test_cmp expect actual + ) +' + test_expect_success 'submodule init picks up rebase' ' (cd super git config -f .gitmodules submodule.rebasing.update rebase -- 1.8.5.1-400-gbc1da41 -- 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
[ANNOUNCE] Git v1.8.4.5
A maintenance release Git v1.8.4.5 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: b43c0cc46749ad62b8ac74237ceca00c8e386edb git-1.8.4.5.tar.gz bd66db8c9528e53d2b93e88ef8e96164e597333f git-htmldocs-1.8.4.5.tar.gz 1ff6380e60c879a563ef89452ca461e9610e41c0 git-manpages-1.8.4.5.tar.gz The following public repositories all have a copy of the v1.8.4.5 tag and the maint-1.8.4 branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Also, http://www.kernel.org/pub/software/scm/git/ has copies of the release tarballs. Git v1.8.4.5 Release Notes == Fixes since v1.8.4.4 * Recent update to remote-hg that attempted to make it work better with non ASCII pathnames fed Unicode strings to the underlying Hg API, which was wrong. * git submodule init copied submodule.$name.update settings from .gitmodules to .git/config without making sure if the suggested value was sensible. Changes since v1.8.4.4 are as follows: Junio C Hamano (2): submodule: do not copy unknown update mode from .gitmodules Git 1.8.4.5 Richard Hansen (1): remote-hg: don't decode UTF-8 paths into Unicode objects -- 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 filter-branch --directory-filter oddity
When using git filter-branch --prune-empty --directory-filter foo/bar to extract the history of the foo/bar directory, I am getting a very strange result. Directory foo/bar is slow moving. Say, 22 commits out of several thousand. I would like to extract just those 22 commits. Instead, I get ~1500 commits, which seem to have not been skipped because they are merge commits. Merges completely immaterial to this directory. As they have not been skipped, they are fully fleshed out. By this, I mean that we have the whole tree in place. So these 22 commits appear with foo/bar pulled out to the root of the project, in the midst of 1500 commits with a full tree. The commit diffs make no sense what-so-ever. Am I doing it wrong? m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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 filter-branch --directory-filter oddity
On Tue, Dec 3, 2013 at 5:44 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
As they have not been skipped, they are fully fleshed out. By this, I
mean that we have the whole tree in place. So these 22 commits appear
with foo/bar pulled out to the root of the project, in the midst of
1500 commits with a full tree.
IOWs, I am experimenting with something like:
git filter-branch -f -d /tmp/moodle-$RANDOM --prune-empty
--index-filter git ls-files -z | grep -zZ -v '${dirpath}' | xargs -0
--no-run-if-empty -n100 git rm --quiet --cached --ignore-unmatch
^v2.1.0 $branches
git filter-branch -f --prune-empty --subdirectory-filter ${dirpath}
^v2.1.0 $branches
git filter-branch -f --commit-filter
~/src/git-filter-branch-tools/remove-pointless-commit.rb \\$@\
^v2.1.0 $branches
perhaps the docs for filter-branch imply, to me at least, that it's a
DWIM tool. I am surprised at having to roll my own on something that
is fairly popular.
cheers,
m
--
martin.langh...@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
--
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 3/3] push: also use upstream mapping when pushing a single ref
When the user is using the 'upstream' mode, these commands:
$ git push
$ git push origin
would find the 'upstream' branch for the current branch, and then
push the current branch to update it. However, pushing a single
branch explicitly, i.e.
$ git push origin $(git symbolic-ref --short HEAD)
would not go through the same ref mapping process, and ends up
updating the branch at 'origin' of the same name, which may not
necessarily be the upstream of the branch being pushed.
In the spirit similar to the previous one, map a colon-less refspec
using the upstream mapping logic.
Note that this is deliberately done after the logic to map refspec
via the remote.$name.push configuration did not find any. This is
because most of those that employ a simple 'upstream' mode do not
have the push refspec, and checking with remote.$name.push refspec
first will allow it to be used as a mechanism to override the usual
'upstream' push mapping (which is primarily useful for centralized
workflow) by those who want to use a triangular workflow.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/push.c| 11 +++
t/t5516-fetch-push.sh | 30 ++
2 files changed, 41 insertions(+)
diff --git a/builtin/push.c b/builtin/push.c
index bdc1fc1..71c081e 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -58,6 +58,17 @@ static const char *map_refspec(const char *ref,
}
}
+ if (push_default == PUSH_DEFAULT_UPSTREAM
+ !prefixcmp(matched-name, refs/heads/)) {
+ struct branch *branch = branch_get(matched-name + 11);
+ if (branch-merge_nr == 1 branch-merge[0]-src) {
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addf(buf, %s:%s,
+ ref, branch-merge[0]-src);
+ return strbuf_detach(buf, NULL);
+ }
+ }
+
return ref;
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6d7f102..926e7f6 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1160,6 +1160,7 @@ test_expect_success 'with no remote.$name.push, it is not
used as refmap' '
git pull ../testrepo master
git branch next
git config remote.dst.url ../dst
+ git config push.default matching
git push dst master
git show-ref refs/heads/master ../dst/expect
)
@@ -1171,6 +1172,35 @@ test_expect_success 'with no remote.$name.push, it is
not used as refmap' '
test_cmp dst/expect dst/actual
'
+test_expect_success 'with no remote.$name.push, upstream mapping is used' '
+ mk_test testrepo heads/master
+ rm -fr src dst
+ git init src
+ git init --bare dst
+ (
+ cd src
+ git pull ../testrepo master
+ git branch next
+ git config remote.dst.url ../dst
+ git config remote.dst.fetch +refs/heads/*:refs/remotes/dst/*
+ git config push.default upstream
+
+ git config branch.master.merge refs/heads/trunk
+ git config branch.master.remote dst
+
+ git push dst master
+ git show-ref refs/heads/master |
+ sed -e s|refs/heads/master|refs/heads/trunk| ../dst/expect
+ )
+ (
+ cd dst
+ test_must_fail git show-ref refs/heads/master
+ test_must_fail git show-ref refs/heads/next
+ git show-ref refs/heads/trunk actual
+ )
+ test_cmp dst/expect dst/actual
+'
+
test_expect_success 'push does not follow tags by default' '
mk_test testrepo heads/master
rm -fr src dst
--
1.8.5.1-400-gbc1da41
--
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 0/3] Teaching git push to map pushed refs
Earlier, Peff taught git fetch origin master to update a remote-tracking branch by internally mapping the colon-less refspec 'master' to '+refs/heads/master:refs/remotes/origin/master'. Both git fetch origin git fetch origin master would update the same refs/remotes/origin/master, which avoids surprises. However, we did not have a similar refspec mapping on the push side. This three-patch series does just that, and would help triangular workflow by making these two: git checkout master git push origin git push origin master update the same ref at the 'origin'. Junio C Hamano (3): builtin/push.c: use strbuf instead of manual allocation push: use remote.$name.push as a refmap push: also use upstream mapping when pushing a single ref Documentation/git-push.txt | 9 -- builtin/push.c | 79 -- remote.c | 8 ++--- remote.h | 2 ++ t/t5516-fetch-push.sh | 75 +++ 5 files changed, 144 insertions(+), 29 deletions(-) -- 1.8.5.1-400-gbc1da41 -- 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] push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of git fetch literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote satellite]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote mothership]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-push.txt | 9 +++--
builtin/push.c | 35 ---
remote.c | 8
remote.h | 2 ++
t/t5516-fetch-push.sh | 45 +
5 files changed, 90 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 9eec740..2b7f4f9 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -56,8 +56,13 @@ it can be any arbitrary SHA-1 expression, such as
`master~4` or
+
The dst tells which ref on the remote side is updated with this
push. Arbitrary expressions cannot be used here, an actual ref must
-be named. If `:`dst is omitted, the same ref as src will be
-updated.
+be named.
+If `git push [repository]` without any `refspec` argument is set to
+update some ref at the destination with `src` with
+`remote.repository.push` configuration variable, `:dst` part can
+be omitted---such a push will update a ref that `src` normally updates
+without any `refspec` on the command line. Otherwise, missing
+`:dst` means to update the same ref as the `src`.
+
The object referenced by src is used to update the dst reference
on the remote side. By default this is only allowed if dst is not
diff --git a/builtin/push.c b/builtin/push.c
index 76e4400..bdc1fc1 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -35,7 +35,34 @@ static void add_refspec(const char *ref)
refspec[refspec_nr-1] = ref;
}
-static void set_refspecs(const char **refs, int nr)
+static const char *map_refspec(const char *ref,
+ struct remote *remote, struct ref *local_refs)
+{
+ struct ref *matched = NULL;
+
+ /* Does ref uniquely name our ref? */
+ if (count_refspec_match(ref, local_refs, matched) != 1)
+ return ref;
+
+ if (remote-push) {
+ struct refspec query;
+ memset(query, 0, sizeof(struct refspec));
+ query.src = matched-name;
+ if (!query_refspecs(remote-push, remote-push_refspec_nr,
query)
+ query.dst) {
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addf(buf, %s%s:%s,
+ query.force ? + : ,
+ query.src, query.dst);
+ return strbuf_detach(buf, NULL);
+ }
+ }
+
+ return ref;
+}
+
+static void set_refspecs(const char **refs, int nr,
+struct remote *remote, struct ref *local_refs)
{
int i;
for (i = 0; i nr; i++) {
@@ -56,7 +83,8 @@ static void set_refspecs(const char **refs, int nr)
die(_(--delete only accepts plain target ref
names));
strbuf_addf(delref, :%s, ref);
ref = strbuf_detach(delref, NULL);
- }
+ } else if (!strchr(ref, ':'))
+ ref = map_refspec(ref, remote, local_refs);
add_refspec(ref);
}
}
@@ -487,7 +515,8 @@ int cmd_push(int argc, const char **argv, const char
*prefix)
if (argc 0) {
repo = argv[0];
- set_refspecs(argv + 1, argc - 1);
+ set_refspecs(argv
[PATCH 1/3] builtin/push.c: use strbuf instead of manual allocation
The command line arguments given to git push are massaged into
a list of refspecs in set_refspecs() function. This was implemented
using xmalloc, strcpy and friends, but it is much easier to read if
done using strbuf.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/push.c | 35 ++-
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 7b1b66c..76e4400 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -41,29 +41,22 @@ static void set_refspecs(const char **refs, int nr)
for (i = 0; i nr; i++) {
const char *ref = refs[i];
if (!strcmp(tag, ref)) {
- char *tag;
- int len;
+ struct strbuf tagref = STRBUF_INIT;
if (nr = ++i)
die(_(tag shorthand without tag));
- len = strlen(refs[i]) + 11;
- if (deleterefs) {
- tag = xmalloc(len+1);
- strcpy(tag, :refs/tags/);
- } else {
- tag = xmalloc(len);
- strcpy(tag, refs/tags/);
- }
- strcat(tag, refs[i]);
- ref = tag;
- } else if (deleterefs !strchr(ref, ':')) {
- char *delref;
- int len = strlen(ref)+1;
- delref = xmalloc(len+1);
- strcpy(delref, :);
- strcat(delref, ref);
- ref = delref;
- } else if (deleterefs)
- die(_(--delete only accepts plain target ref names));
+ ref = refs[i];
+ if (deleterefs)
+ strbuf_addf(tagref, :refs/tags/%s, ref);
+ else
+ strbuf_addf(tagref, refs/tags/%s, ref);
+ ref = strbuf_detach(tagref, NULL);
+ } else if (deleterefs) {
+ struct strbuf delref = STRBUF_INIT;
+ if (strchr(ref, ':'))
+ die(_(--delete only accepts plain target ref
names));
+ strbuf_addf(delref, :%s, ref);
+ ref = strbuf_detach(delref, NULL);
+ }
add_refspec(ref);
}
}
--
1.8.5.1-400-gbc1da41
--
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: slow git-cherry-pick.
On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast t...@thomasrast.ch wrote:
Paweł Sikora pawel.sik...@agmk.net writes:
Umm, there's a gem here that the thread missed so far:
my git repo isn't very big[1] but it's checked out on the linear lvm
where random i/o generally hurts and strace shows that current git version
performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before
^
There's no reason why it should do the lstat() *twice* for every file.
But Paweł is right; the code path roughly goes like this:
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
[...]
res = sequencer_pick_revisions(opts);
int sequencer_pick_revisions(struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
[...]
return pick_commits(todo_list, opts);
}
static int pick_commits(struct commit_list *todo_list, struct replay_opts
*opts)
{
[...]
read_and_refresh_cache(opts);
I'm too tired to dig further, but AFAICT it's just a rather obvious case
of duplication of effort.
That's something to optimize, but it's single commit picking,
sequencer_pick_revisions() should call single_pick() instead of
pick_commits().
The read+close on the whole checkout looks like there's problem with
refresh operation and git decides to read up and verify sha-1 by
content. Pawel, if you run strace git update-index --refresh twice,
does it still show 1 stat + 1 read for every entry on the second try?
--
Duy
--
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] difftool: Change prompt to display the number of files in the diff queue
When --prompt option is set, git-difftool displays a prompt for each modified
file to be viewed in an external diff program. At that point it could be useful
to display a counter and the total number of files in the diff queue.
Below is the current difftool prompt for the first of 5 modified files:
Viewing: 'diff.c'
Launch 'vimdiff' [Y/n]:
Consider the modified prompt:
Viewing (1/5): 'diff.c'
Launch 'vimdiff' [Y/n]:
The current GIT_EXTERNAL_DIFF mechanism does not tell the number of
paths in the diff queue nor the current counter. To make this
counter/total info available for GIT_EXTERNAL_DIFF programs without
breaking existing ones:
(1) Modify run_external_diff() function in diff.c to set one environment
variable for a counter and one for the total number of files in the diff
queue. The size of the diff queue is already available in the
diff_queue_struct. For the counter define a new variable in the
diff_options struct and reset it to zero in diff_setup_done() function.
Pre-increment the counter inside the run_external_diff() function.
(2) Modify git-difftool--helper.sh script to display the counter and the diff
queue count values in the difftool prompt.
(3) Update git.txt documentation
(4) Update t4020-diff-external.sh test script
Signed-off-by: Zoltan Klinger zoltan.klin...@gmail.com
---
Reworked the patch to use environment variables instead of command line
arguments for making the counter and total values available to external
scripts. This way existing scripts will still work and can be updated
later if they want to make use of these two new values.
Documentation/git.txt| 9 +
diff.c | 19 +--
diff.h | 2 ++
git-difftool--helper.sh | 3 ++-
t/t4020-diff-external.sh | 16
5 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 4448ce2..10939ac 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -806,6 +806,15 @@ temporary file --- it is removed when 'GIT_EXTERNAL_DIFF'
exits.
+
For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
parameter, path.
++
+For each path 'GIT_EXTERNAL_DIFF' is called, two environment variables,
+'GIT_DIFF_PATH_COUNTER' and 'GIT_DIFF_PATH_TOTAL' are set.
+
+'GIT_DIFF_PATH_COUNTER'::
+ A 1-based counter incremented by one for every path.
+
+'GIT_DIFF_PATH_TOTAL'::
+ The total number of paths.
other
~
diff --git a/diff.c b/diff.c
index e34bf97..c4078af 100644
--- a/diff.c
+++ b/diff.c
@@ -2899,11 +2899,18 @@ static void run_external_diff(const char *pgm,
struct diff_filespec *one,
struct diff_filespec *two,
const char *xfrm_msg,
- int complete_rewrite)
+ int complete_rewrite,
+ struct diff_options *o)
{
const char *spawn_arg[10];
int retval;
const char **arg = spawn_arg[0];
+ struct diff_queue_struct *q = diff_queued_diff;
+
+ struct strbuf counterstr = STRBUF_INIT;
+ struct strbuf totalstr = STRBUF_INIT;
+ strbuf_addf(counterstr, %d, ++o-diff_path_counter);
+ strbuf_addf(totalstr, %d, q-nr);
if (one two) {
struct diff_tempfile *temp_one, *temp_two;
@@ -2928,8 +2935,14 @@ static void run_external_diff(const char *pgm,
}
*arg = NULL;
fflush(NULL);
+
+ setenv (GIT_DIFF_PATH_COUNTER, counterstr.buf, 1);
+ setenv (GIT_DIFF_PATH_TOTAL, totalstr.buf, 1);
+
retval = run_command_v_opt(spawn_arg, RUN_USING_SHELL);
remove_tempfile();
+ strbuf_release(counterstr);
+ strbuf_release(totalstr);
if (retval) {
fprintf(stderr, external diff died, stopping at %s.\n, name);
exit(1);
@@ -3042,7 +3055,7 @@ static void run_diff_cmd(const char *pgm,
if (pgm) {
run_external_diff(pgm, name, other, one, two, xfrm_msg,
- complete_rewrite);
+ complete_rewrite, o);
return;
}
if (one two)
@@ -3317,6 +3330,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;
}
static int opt_arg(const char *arg, int arg_short, const char *arg_long, int
*val)
diff --git a/diff.h b/diff.h
index e342325..42bd34c 100644
--- a/diff.h
+++ b/diff.h
@@ -164,6 +164,8 @@ struct diff_options {
diff_prefix_fn_t output_prefix;
int output_prefix_length;
void *output_prefix_data;
+
+ int diff_path_counter;
};
enum color_diff {
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index b00ed95..7ef36b9 100755
--- a/git-difftool--helper.sh
+++
Никаких окуляров и линз
Диагноз не имеет значения, изумительный итог гарантирован http://goo.gl/CQX4we
[RFC 02/11] remote.c: add infrastructure for parsing --prune options
For now, only handle --prune/--no-prune. But handle the option via a
callback so that in the future --prune=PATTERN can be implemented.
The new functions are not yet used.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 62 ++
remote.h | 35 +++
2 files changed, 97 insertions(+)
diff --git a/remote.c b/remote.c
index 075ed71..297e52f 100644
--- a/remote.c
+++ b/remote.c
@@ -7,6 +7,7 @@
#include dir.h
#include tag.h
#include string-list.h
+#include argv-array.h
#include mergesort.h
enum map_direction { FROM_SRC, FROM_DST };
@@ -58,6 +59,67 @@ static struct rewrites rewrites_push;
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
+int prune_option_parse(const struct option *opt, const char *arg, int unset)
+{
+ struct prune_option *target = opt-value;
+
+ if (unset) {
+ target-prune = 0;
+ } else {
+ target-prune = 1;
+ }
+ return 0;
+}
+
+static int git_fetch_config(const char *k, const char *v, void *cb)
+{
+ int *fetch_prune_config = cb;
+
+ if (!strcmp(k, fetch.prune)) {
+ *fetch_prune_config = git_config_bool(k, v);
+ return 0;
+ }
+ return 0;
+}
+
+void prune_option_fill(struct remote *remote,
+ struct prune_option *prune_option, int default_prune)
+{
+ if (prune_option-prune 0) {
+ /*
+* The user specified neither --prune nor --no-prune;
+* use the configured value of remote.name.prune or
+* fetch.prune:
+*/
+ if (remote-prune = 0) {
+ prune_option-prune = remote-prune;
+ } else {
+ int fetch_prune_config = -1;
+
+ git_config(git_fetch_config, fetch_prune_config);
+
+ if (fetch_prune_config = 0)
+ prune_option-prune = fetch_prune_config;
+ else
+ prune_option-prune = default_prune;
+ }
+ }
+}
+
+void argv_push_prune_option(struct argv_array *argv,
+ struct prune_option *prune_option)
+{
+ if (prune_option-prune != -1)
+ argv_array_pushf(argv,
+prune_option-prune
+? --prune
+: --no-prune);
+}
+
+void prune_option_clear(struct prune_option *prune_option)
+{
+}
+
static int valid_remote(const struct remote *remote)
{
return (!!remote-url) || (!!remote-foreign_vcs);
diff --git a/remote.h b/remote.h
index afa3792..21ff4cb 100644
--- a/remote.h
+++ b/remote.h
@@ -53,6 +53,40 @@ struct remote {
char *http_proxy;
};
+/* Structure to hold parsed --prune/--no-prune options */
+struct prune_option {
+ /* Should we prune at all? -1 is indeterminate. */
+ int prune;
+};
+
+#define PRUNE_OPTION_INIT { -1 }
+
+/* parse_opts() callback for --prune/--no-prune options */
+int prune_option_parse(const struct option *opt, const char *arg, int unset);
+
+/*
+ * Fill in prune_option for the specified remote, given the
+ * prune_option values parsed from the command-line. default_prune
+ * specifies whether pruning should default to true or false if it has
+ * not been configured explicitly.
+ */
+void prune_option_fill(struct remote *remote,
+ struct prune_option *prune_option, int default_prune);
+
+/*
+ * Add --prune/--prune=pattern/--no-prune options to the argv_array
+ * to represent the options in prune_options.
+ */
+struct argv_array;
+void argv_push_prune_option(struct argv_array *argv,
+ struct prune_option *prune_option);
+
+/*
+ * Free any resources used by *prune_option (but not *prune_option
+ * itself).
+ */
+void prune_option_clear(struct prune_option *prune_option);
+
struct remote *remote_get(const char *name);
struct remote *pushremote_get(const char *name);
int remote_is_configured(const char *name);
@@ -238,6 +272,7 @@ struct ref *guess_remote_head(const struct ref *head,
* Return refs that no longer exist on remote and that match one of
* the patterns.
*/
+struct string_list;
struct ref *get_stale_heads(struct refspec *refs, int ref_count,
struct ref *fetch_map,
struct string_list *patterns);
--
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
[RFC 11/11] remote: allow prune patterns to be configured
Add two new configuration settings, fetch.pruneRef remote.name.pruneRef via which prune patterns (i.e., the equivalent of --prune=pattern) can be configured globally or for particular remotes. The default remains the same, namely *. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/config.txt| 28 ++- Documentation/fetch-options.txt | 7 + Documentation/git-remote.txt| 13 + remote.c| 47 +--- remote.h| 1 + t/t5505-remote.sh | 60 + t/t5510-fetch.sh| 13 + 7 files changed, 143 insertions(+), 26 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index a405806..5a2118e 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1069,6 +1069,14 @@ fetch.prune:: If true, fetch will automatically behave as if the `--prune` option was given on the command line. See also `remote.name.prune`. +fetch.pruneRef:: + Glob pattern matching the names of local references that are + subject to pruning when git fetch --prune or git remote + prune is run for this remote. See the `--prune=pattern` + option to the linkgit:git-fetch[1] command for more + information. This setting may be overridden for particular + remotes via remote.name.pruneRef. + format.attach:: Enable multipart/mixed attachments as the default for 'format-patch'. The value can also be a double quoted string @@ -2047,6 +2055,20 @@ remote.name.fetch:: The default set of refspec for linkgit:git-fetch[1]. See linkgit:git-fetch[1]. +remote.name.prune:: + When set to true, fetching from this remote by default will + also remove any remote-tracking references that no longer + exist on the remote (as if the `--prune` option were given on + the command line). Overrides `fetch.prune` settings, if any. + See also `remote.name.pruneRef`. + +remote.name.pruneRef:: + Glob pattern matching the names of local references that are + subject to pruning when git fetch --prune or git remote + prune is run for this remote. See the `--prune=pattern` + option to the linkgit:git-fetch[1] command for more + information. This option overrides `fetch.pruneRef`. + remote.name.push:: The default set of refspec for linkgit:git-push[1]. See linkgit:git-push[1]. @@ -2085,12 +2107,6 @@ remote.name.vcs:: Setting this to a value vcs will cause Git to interact with the remote with the git-remote-vcs helper. -remote.name.prune:: - When set to true, fetching from this remote by default will also - remove any remote-tracking references that no longer exist on the - remote (as if the `--prune` option was given on the command line). - Overrides `fetch.prune` settings, if any. - remotes.group:: The list of remotes which are fetched by git remote update group. See linkgit:git-remote[1]. diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 61d3f75..fa2cfdb 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -41,6 +41,7 @@ ifndef::git-pull[] -p:: --prune[=pattern]:: +--no-prune:: After fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag @@ -53,6 +54,12 @@ ifndef::git-pull[] If pattern is specified, then it should be a glob pattern, and pruning is further restricted to references whose names match the pattern. This option can be specified multiple times. ++ +The default for `--prune`/`--no-prune` is taken from the configuration +settings remote.name.prune or fetch.prune, or false if neither of +these is set. The default pattern is taken from +remote.name.pruneRef or fetch.pruneRef, or * if neither of these +is set. endif::git-pull[] ifndef::git-pull[] diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index dd48474..4e1f8b2 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -151,17 +151,20 @@ With `--prune`, display stale remote-tracking branches that no longer exist on the remote (this is the default). With `--prune=pattern`, only report stale references whose names match pattern (this option can be used multiple times). With `--no-prune`, do not report stale -remote-tracking references at all. +remote-tracking references at all. See linkgit:git-fetch[1] for more +information about how pruning patterns can be configured. + With `-n` option, the remote heads are not queried first with `git ls-remote name`; cached information is used instead. 'prune':: -Deletes all stale remote-tracking branches under name. -These stale branches
[RFC 06/11] fetch --prune: allow refname patterns to be specified
Allow optional arguments to be passed to git fetch --prune to choose
which references are subject to pruning. The default, if no argument
is specified, is to prune all references as before.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/fetch-options.txt | 6 +-
builtin/fetch.c | 8 ++--
t/t5510-fetch.sh| 12
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index f0ef7d0..61d3f75 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -40,7 +40,7 @@ ifndef::git-pull[]
specified. No refspecs may be specified.
-p::
---prune::
+--prune[=pattern]::
After fetching, remove any remote-tracking references that no
longer exist on the remote. Tags are not subject to pruning
if they are fetched only because of the default tag
@@ -49,6 +49,10 @@ ifndef::git-pull[]
line or in the remote configuration, for example if the remote
was cloned with the --mirror option), then they are also
subject to pruning.
++
+If pattern is specified, then it should be a glob pattern, and pruning
+is further restricted to references whose names match the pattern.
+This option can be specified multiple times.
endif::git-pull[]
ifndef::git-pull[]
diff --git a/builtin/fetch.c b/builtin/fetch.c
index fcc06a4..2cb48a6 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -73,9 +73,12 @@ static struct option builtin_fetch_options[] = {
N_(fetch all tags and associated objects), TAGS_SET),
OPT_SET_INT('n', NULL, tags,
N_(do not fetch all tags (--no-tags)), TAGS_UNSET),
- { OPTION_CALLBACK, 'p', prune, prune_option, N_(pattern),
+ { OPTION_CALLBACK, 'p', NULL, prune_option, NULL,
N_(prune remote-tracking branches no longer on remote),
PARSE_OPT_NOARG, prune_option_parse },
+ { OPTION_CALLBACK, 0, prune, prune_option, N_(pattern),
+ N_(prune remote-tracking branches (matching pattern, if
specified)),
+ PARSE_OPT_OPTARG, prune_option_parse },
{ OPTION_CALLBACK, 0, recurse-submodules, NULL, N_(on-demand),
N_(control recursive fetching of submodules),
PARSE_OPT_OPTARG, option_parse_recurse_submodules },
@@ -702,7 +705,8 @@ static int fetch_refs(struct transport *transport, struct
ref *ref_map)
static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map)
{
int result = 0;
- struct ref *stale_refs = get_stale_heads(refs, ref_count, ref_map,
NULL);
+ struct ref *stale_refs = get_stale_heads(refs, ref_count, ref_map,
+prune_option.prune_patterns);
struct ref *ref;
const char *dangling_msg = dry_run
? _( (%s will become dangling))
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 5d4581d..42eb21f 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -94,6 +94,18 @@ test_expect_success 'fetch --prune on its own works as
expected' '
test_must_fail git rev-parse origin/extrabranch
'
+test_expect_success 'fetch --prune with arguments' '
+ cd $D
+ git clone . prune-args
+ cd prune-args
+ git update-ref refs/remotes/origin/branch1 master
+ git update-ref refs/remotes/origin/branch2 master
+
+ git fetch --prune=refs/remotes/origin/*1 origin
+ test_must_fail git rev-parse origin/branch1
+ git rev-parse origin/branch2
+'
+
test_expect_success 'fetch --prune with a branch name keeps branches' '
cd $D
git clone . prune-branch
--
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
[RFC 10/11] remote show: allow --prune=pattern options
By default, show the remote-tracking references that could be pruned.
But if the user specifies --prune=pattern, then limit the output to
those matching pattern. And if the user specified --no-prune, then do
not look for stale remote-tracking references at all.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-remote.txt | 6 ++
builtin/remote.c | 3 +++
2 files changed, 9 insertions(+)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 9cbc986..dd48474 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -147,6 +147,12 @@ error.
Gives some information about the remote name.
+
+With `--prune`, display stale remote-tracking branches that no longer
+exist on the remote (this is the default). With `--prune=pattern`,
+only report stale references whose names match pattern (this option
+can be used multiple times). With `--no-prune`, do not report stale
+remote-tracking references at all.
++
With `-n` option, the remote heads are not queried first with
`git ls-remote name`; cached information is used instead.
diff --git a/builtin/remote.c b/builtin/remote.c
index e1d43e2..293d82d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1165,6 +1165,9 @@ static int show(int argc, const char **argv)
int no_query = 0, result = 0, query_flag = 0;
struct prune_option prune_option = PRUNE_OPTION_INIT;
struct option options[] = {
+ { OPTION_CALLBACK, 0, prune, prune_option, N_(pattern),
+ N_(show prunable remote-tracking branches (matching
pattern, if specified)),
+ PARSE_OPT_OPTARG, prune_option_parse },
OPT_BOOL('n', NULL, no_query, N_(do not query remotes)),
OPT_END()
};
--
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
[RFC 03/11] fetch: use the new functions for handling --prune options
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 36
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 9a04512..fcc06a4 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -30,8 +30,7 @@ enum {
TAGS_SET = 2
};
-static int fetch_prune_config = -1; /* unspecified */
-static int prune = -1; /* unspecified */
+static struct prune_option prune_option = PRUNE_OPTION_INIT;
#define PRUNE_BY_DEFAULT 0 /* do we prune by default? */
static int all, append, dry_run, force, keep, multiple, update_head_ok,
verbosity;
@@ -59,15 +58,6 @@ static int option_parse_recurse_submodules(const struct
option *opt,
return 0;
}
-static int git_fetch_config(const char *k, const char *v, void *cb)
-{
- if (!strcmp(k, fetch.prune)) {
- fetch_prune_config = git_config_bool(k, v);
- return 0;
- }
- return 0;
-}
-
static struct option builtin_fetch_options[] = {
OPT__VERBOSITY(verbosity),
OPT_BOOL(0, all, all,
@@ -83,8 +73,9 @@ static struct option builtin_fetch_options[] = {
N_(fetch all tags and associated objects), TAGS_SET),
OPT_SET_INT('n', NULL, tags,
N_(do not fetch all tags (--no-tags)), TAGS_UNSET),
- OPT_BOOL('p', prune, prune,
-N_(prune remote-tracking branches no longer on remote)),
+ { OPTION_CALLBACK, 'p', prune, prune_option, N_(pattern),
+ N_(prune remote-tracking branches no longer on remote),
+ PARSE_OPT_NOARG, prune_option_parse },
{ OPTION_CALLBACK, 0, recurse-submodules, NULL, N_(on-demand),
N_(control recursive fetching of submodules),
PARSE_OPT_OPTARG, option_parse_recurse_submodules },
@@ -848,7 +839,7 @@ static int do_fetch(struct transport *transport,
retcode = 1;
goto cleanup;
}
- if (prune) {
+ if (prune_option.prune) {
/*
* We only prune based on refspecs specified
* explicitly (via command line or configuration); we
@@ -935,8 +926,7 @@ static void add_options_to_argv(struct argv_array *argv)
{
if (dry_run)
argv_array_push(argv, --dry-run);
- if (prune != -1)
- argv_array_push(argv, prune ? --prune : --no-prune);
+ argv_push_prune_option(argv, prune_option);
if (update_head_ok)
argv_array_push(argv, --update-head-ok);
if (force)
@@ -1002,17 +992,9 @@ static int fetch_one(struct remote *remote, int argc,
const char **argv)
die(_(No remote repository specified. Please, specify either
a URL or a\n
remote name from which new revisions should be fetched.));
- gtransport = prepare_transport(remote);
+ prune_option_fill(remote, prune_option, PRUNE_BY_DEFAULT);
- if (prune 0) {
- /* no command line request */
- if (0 = gtransport-remote-prune)
- prune = gtransport-remote-prune;
- else if (0 = fetch_prune_config)
- prune = fetch_prune_config;
- else
- prune = PRUNE_BY_DEFAULT;
- }
+ gtransport = prepare_transport(remote);
if (argc 0) {
int j = 0;
@@ -1063,8 +1045,6 @@ int cmd_fetch(int argc, const char **argv, const char
*prefix)
for (i = 1; i argc; i++)
strbuf_addf(default_rla, %s, argv[i]);
- git_config(git_fetch_config, NULL);
-
argc = parse_options(argc, argv, prefix,
builtin_fetch_options, builtin_fetch_usage, 0);
--
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
[RFC 00/11] Make reference pruning more configurable
This patch series applies on top of mh/fetch-tags-in-addition-to-normal-refs and has some minor conflicts with that branch (mostly related to documentation). Let me state in advance that I personally think that the features implemented in this patch series are overkill. But since it was already implemented, I thought I would throw it out there and see if anybody likes it. This patch series makes it possible for the user to specify explicitly which reference namespaces should be subjected to pruning when fetching from a remote. * It allows a pattern to be passed to the --prune option for the following commands: git fetch --prune=pattern [...] git remote update --prune=pattern [...] git remote prune --prune=pattern [...] Only references that match the specified pattern(s) are considered for pruning. git remote show --prune=pattern [...] Only show prunable references that match the specified pattern(s). The --prune=pattern option can be specified multiple times. * It introduces the following multivalued configuration values: fetch.pruneRef remote.name.pruneRef Configuration settings for setting the default --prune=pattern options, globally and per-remote. Background: I started working on this feature as my first approach to solving the problem that git fetch --tags --prune can nuke tags unrelated to the remote being fetched from. Only later did I hit upon the better solution that is implemented in mh/fetch-tags-in-addition-to-normal-refs, namely to change the semantics of the --tags option to *not* subject tags to pruning. But even though --prune=pattern is no longer needed to prevent tag nuking, it might be useful to somebody for other purposes, and therefore I am submitting it to the list as an RFC. Maybe there is a use case associated with non-branch, non-tag references, like perhaps Gerrit pull request-related references? Personally, I am -0 on this series. I think it adds more complication (code, documentation, etc) than its usefulness justifies. I think the functionality in mh/fetch-tags-in-addition-to-normal-refs (which we want in any case!) will satisfy 99% of users and I can't think of use cases where additional configurability of reference pruning is needed. So, if anybody can think of a compelling use case for this feature, please make your case! Michael Michael Haggerty (11): get_stale_heads(): allow limiting to refname patterns remote.c: add infrastructure for parsing --prune options fetch: use the new functions for handling --prune options remote: use the new functions for handling --prune options remote.c: add infrastructure to handle --prune=pattern fetch --prune: allow refname patterns to be specified remote update --prune: allow refname patterns to be specified string_list_append_list(): new function remote prune: allow --prune=pattern options remote show: allow --prune=pattern options remote: allow prune patterns to be configured Documentation/config.txt| 28 -- Documentation/fetch-options.txt | 13 ++- Documentation/git-remote.txt| 29 +-- Documentation/technical/api-string-list.txt | 10 ++- builtin/fetch.c | 43 +++-- builtin/remote.c| 85 -- remote.c| 130 +++- remote.h| 48 +- string-list.c | 9 ++ string-list.h | 8 ++ t/t5505-remote.sh | 88 +++ t/t5510-fetch.sh| 25 ++ 12 files changed, 441 insertions(+), 75 deletions(-) -- 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
[RFC 09/11] remote prune: allow --prune=pattern options
Allow --prune=pattern options to be provided to git remote prune
to specify which reference namespaces should be pruned. --prune
without an argument and --no-prune are disallowed here as they make
no sense.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-remote.txt | 5 +++-
builtin/remote.c | 67 +++-
t/t5505-remote.sh| 15 ++
3 files changed, 66 insertions(+), 21 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 02e50a9..9cbc986 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -19,7 +19,7 @@ SYNOPSIS
'git remote set-url --add' [--push] name newurl
'git remote set-url --delete' [--push] name url
'git remote' [-v | --verbose] 'show' [-n] name...
-'git remote prune' [-n | --dry-run] name...
+'git remote prune' [-n | --dry-run] [--prune=pattern] name...
'git remote' [-v | --verbose] 'update' [-p | --no-prune |
--prune[=pattern]...]
[(group | remote)...]
@@ -157,6 +157,9 @@ These stale branches have already been removed from the
remote repository
referenced by name, but are still locally available in
remotes/name.
+
+With `--prune=pattern`, only prune references whose names match
+pattern. This option can be used multiple times.
++
With `--dry-run` option, report what branches will be pruned, but do not
actually prune them.
diff --git a/builtin/remote.c b/builtin/remote.c
index 6aab923..e1d43e2 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -15,7 +15,7 @@ static const char * const builtin_remote_usage[] = {
N_(git remote remove name),
N_(git remote set-head name (-a | --auto | -d | --delete
|branch)),
N_(git remote [-v | --verbose] show [-n] name),
- N_(git remote prune [-n | --dry-run] name),
+ N_(git remote prune [-n | --dry-run] [--prune=pattern] name),
N_(git remote [-v | --verbose] update [-p | --prune[=pattern] |
--no-prune] [(group | remote)...]),
N_(git remote set-branches [--add] name branch...),
N_(git remote set-url [--push] name newurl [oldurl]),
@@ -326,10 +326,12 @@ struct ref_states {
int queried;
};
-static int get_ref_states(const struct ref *remote_refs, struct ref_states
*states)
+static int get_ref_states(const struct ref *remote_refs,
+ struct ref_states *states,
+ struct prune_option *prune_option)
{
struct ref *fetch_map = NULL, **tail = fetch_map;
- struct ref *ref, *stale_refs;
+ struct ref *ref;
int i;
for (i = 0; i states-remote-fetch_refspec_nr; i++)
@@ -346,15 +348,20 @@ static int get_ref_states(const struct ref *remote_refs,
struct ref_states *stat
else
string_list_append(states-tracked,
abbrev_branch(ref-name));
}
- stale_refs = get_stale_heads(states-remote-fetch,
-states-remote-fetch_refspec_nr,
-fetch_map, NULL);
- for (ref = stale_refs; ref; ref = ref-next) {
- struct string_list_item *item =
- string_list_append(states-stale,
abbrev_branch(ref-name));
- item-util = xstrdup(ref-name);
+ if (prune_option-prune) {
+ struct ref *stale_refs =
+ get_stale_heads(states-remote-fetch,
+ states-remote-fetch_refspec_nr,
+ fetch_map,
+ prune_option-prune_patterns);
+
+ for (ref = stale_refs; ref; ref = ref-next) {
+ struct string_list_item *item =
+ string_list_append(states-stale,
abbrev_branch(ref-name));
+ item-util = xstrdup(ref-name);
+ }
+ free_refs(stale_refs);
}
- free_refs(stale_refs);
free_refs(fetch_map);
sort_string_list(states-new);
@@ -878,8 +885,9 @@ static int append_ref_to_tracked_list(const char *refname,
}
static int get_remote_ref_states(const char *name,
-struct ref_states *states,
-int query)
+struct ref_states *states, int query,
+struct prune_option *prune_option,
+int default_prune)
{
struct transport *transport;
const struct ref *remote_refs;
@@ -897,8 +905,19 @@ static int get_remote_ref_states(const char *name,
transport_disconnect(transport);
states-queried = 1;
- if (query GET_REF_STATES)
- get_ref_states(remote_refs, states);
+ if (query GET_REF_STATES) {
+ struct prune_option
[RFC 01/11] get_stale_heads(): allow limiting to refname patterns
Add a patterns argument to get_stale_heads(). If it is non-NULL,
then only refnames matching one of the glob patterns in the string
list will be included in the output.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch.c | 3 ++-
builtin/remote.c | 3 ++-
remote.c | 26 --
remote.h | 9 +++--
4 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 3d978eb..9a04512 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -711,7 +711,8 @@ static int fetch_refs(struct transport *transport, struct
ref *ref_map)
static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map)
{
int result = 0;
- struct ref *ref, *stale_refs = get_stale_heads(refs, ref_count,
ref_map);
+ struct ref *stale_refs = get_stale_heads(refs, ref_count, ref_map,
NULL);
+ struct ref *ref;
const char *dangling_msg = dry_run
? _( (%s will become dangling))
: _( (%s has become dangling));
diff --git a/builtin/remote.c b/builtin/remote.c
index f532f35..c08dfa8 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -347,7 +347,8 @@ static int get_ref_states(const struct ref *remote_refs,
struct ref_states *stat
string_list_append(states-tracked,
abbrev_branch(ref-name));
}
stale_refs = get_stale_heads(states-remote-fetch,
-states-remote-fetch_refspec_nr,
fetch_map);
+states-remote-fetch_refspec_nr,
+fetch_map, NULL);
for (ref = stale_refs; ref; ref = ref-next) {
struct string_list_item *item =
string_list_append(states-stale,
abbrev_branch(ref-name));
diff --git a/remote.c b/remote.c
index dc56619..075ed71 100644
--- a/remote.c
+++ b/remote.c
@@ -1986,13 +1986,31 @@ struct stale_heads_info {
struct ref **stale_refs_tail;
struct refspec *refs;
int ref_count;
+ struct string_list *patterns;
};
static int get_stale_heads_cb(const char *refname,
- const unsigned char *sha1, int flags, void *cb_data)
+ const unsigned char *sha1, int flags,
+ void *cb_data)
{
struct stale_heads_info *info = cb_data;
struct refspec query;
+ struct string_list *patterns = info-patterns;
+
+ if (patterns) {
+ int refname_matches = 0;
+ struct string_list_item *item;
+
+ for_each_string_list_item(item, patterns) {
+ if (!fnmatch(item-string, refname, 0)) {
+ refname_matches = 1;
+ break;
+ }
+ }
+ if (!refname_matches)
+ return 0;
+ }
+
memset(query, 0, sizeof(struct refspec));
query.dst = (char *)refname;
@@ -2014,15 +2032,19 @@ static int get_stale_heads_cb(const char *refname,
return 0;
}
-struct ref *get_stale_heads(struct refspec *refs, int ref_count, struct ref
*fetch_map)
+struct ref *get_stale_heads(struct refspec *refs, int ref_count,
+ struct ref *fetch_map,
+ struct string_list *patterns)
{
struct ref *ref, *stale_refs = NULL;
struct string_list ref_names = STRING_LIST_INIT_NODUP;
struct stale_heads_info info;
+
info.ref_names = ref_names;
info.stale_refs_tail = stale_refs;
info.refs = refs;
info.ref_count = ref_count;
+ info.patterns = patterns;
for (ref = fetch_map; ref; ref = ref-next)
string_list_append(ref_names, ref-name);
sort_string_list(ref_names);
diff --git a/remote.h b/remote.h
index c07eb99..afa3792 100644
--- a/remote.h
+++ b/remote.h
@@ -234,8 +234,13 @@ struct ref *guess_remote_head(const struct ref *head,
const struct ref *refs,
int all);
-/* Return refs which no longer exist on remote */
-struct ref *get_stale_heads(struct refspec *refs, int ref_count, struct ref
*fetch_map);
+/*
+ * Return refs that no longer exist on remote and that match one of
+ * the patterns.
+ */
+struct ref *get_stale_heads(struct refspec *refs, int ref_count,
+ struct ref *fetch_map,
+ struct string_list *patterns);
/*
* Compare-and-swap
--
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
[RFC 04/11] remote: use the new functions for handling --prune options
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index c08dfa8..09b965a 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1372,10 +1372,12 @@ static int get_remote_default(const char *key, const
char *value, void *priv)
static int update(int argc, const char **argv)
{
- int i, prune = -1;
+ int i;
+ struct prune_option prune_option = PRUNE_OPTION_INIT;
struct option options[] = {
- OPT_BOOL('p', prune, prune,
-N_(prune remotes after fetching)),
+ { OPTION_CALLBACK, 'p', prune, prune_option, N_(pattern),
+ N_(prune remotes after fetching),
+ PARSE_OPT_NOARG, prune_option_parse },
OPT_END()
};
struct argv_array fetch_argv = ARGV_ARRAY_INIT;
@@ -1387,8 +1389,7 @@ static int update(int argc, const char **argv)
argv_array_push(fetch_argv, fetch);
- if (prune != -1)
- argv_array_push(fetch_argv, prune ? --prune : --no-prune);
+ argv_push_prune_option(fetch_argv, prune_option);
if (verbose)
argv_array_push(fetch_argv, -v);
argv_array_push(fetch_argv, --multiple);
--
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
[RFC 07/11] remote update --prune: allow refname patterns to be specified
Allow optional arguments to be passed to git remote update --prune
to choose which references are subject to pruning. The default, if no
argument is specified, is to prune all references as before.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-remote.txt | 7 +--
builtin/remote.c | 9 ++---
t/t5505-remote.sh| 13 +
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 2507c8b..02e50a9 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -20,7 +20,8 @@ SYNOPSIS
'git remote set-url --delete' [--push] name url
'git remote' [-v | --verbose] 'show' [-n] name...
'git remote prune' [-n | --dry-run] name...
-'git remote' [-v | --verbose] 'update' [-p | --prune] [(group | remote)...]
+'git remote' [-v | --verbose] 'update' [-p | --no-prune |
--prune[=pattern]...]
+ [(group | remote)...]
DESCRIPTION
---
@@ -168,7 +169,9 @@ remotes.default is not defined, all remotes which do not
have the
configuration parameter remote.name.skipDefaultUpdate set to true will
be updated. (See linkgit:git-config[1]).
+
-With `--prune` option, prune all the remotes that are updated.
+The options `--prune`, `--no-prune`, and `--prune=pattern` affect
+whether remote-tracking branches associated with the remotes are
+pruned. See linkgit:git-fetch[1] for more information.
DISCUSSION
diff --git a/builtin/remote.c b/builtin/remote.c
index 09b965a..6aab923 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -16,7 +16,7 @@ static const char * const builtin_remote_usage[] = {
N_(git remote set-head name (-a | --auto | -d | --delete
|branch)),
N_(git remote [-v | --verbose] show [-n] name),
N_(git remote prune [-n | --dry-run] name),
- N_(git remote [-v | --verbose] update [-p | --prune] [(group |
remote)...]),
+ N_(git remote [-v | --verbose] update [-p | --prune[=pattern] |
--no-prune] [(group | remote)...]),
N_(git remote set-branches [--add] name branch...),
N_(git remote set-url [--push] name newurl [oldurl]),
N_(git remote set-url --add name newurl),
@@ -1375,9 +1375,12 @@ static int update(int argc, const char **argv)
int i;
struct prune_option prune_option = PRUNE_OPTION_INIT;
struct option options[] = {
- { OPTION_CALLBACK, 'p', prune, prune_option, N_(pattern),
- N_(prune remotes after fetching),
+ { OPTION_CALLBACK, 'p', NULL, prune_option, NULL,
+ N_(prune remote-tracking branches no longer on
remote),
PARSE_OPT_NOARG, prune_option_parse },
+ { OPTION_CALLBACK, 0, prune, prune_option, N_(pattern),
+ N_(prune remote-tracking branches (matching pattern,
if specified)),
+ PARSE_OPT_OPTARG, prune_option_parse },
OPT_END()
};
struct argv_array fetch_argv = ARGV_ARRAY_INIT;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 8f6e392..0dffe47 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -614,6 +614,19 @@ test_expect_success 'update --prune' '
)
'
+test_expect_success 'update --prune with argument' '
+ git clone one update-prune-arg
+ (
+ cd update-prune-arg
+ git update-ref refs/remotes/origin/branch1 master
+ git update-ref refs/remotes/origin/branch2 master
+
+ git remote update --prune=refs/remotes/*1 origin
+ test_must_fail git rev-parse origin/branch1
+ git rev-parse origin/branch2
+ )
+'
+
cat one/expect -\EOF
apis/master
apis/side
--
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
[RFC 08/11] string_list_append_list(): new function
Add a new function that appends the strings from one string_list onto
another string_list.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/technical/api-string-list.txt | 10 --
string-list.c | 9 +
string-list.h | 8
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-string-list.txt
b/Documentation/technical/api-string-list.txt
index 20be348..2072cf7 100644
--- a/Documentation/technical/api-string-list.txt
+++ b/Documentation/technical/api-string-list.txt
@@ -22,8 +22,9 @@ member (you need this if you add things later) and you should
set the
`nr` and `alloc` members in that case, too.
. Adds new items to the list, using `string_list_append`,
- `string_list_append_nodup`, `string_list_insert`,
- `string_list_split`, and/or `string_list_split_in_place`.
+ `string_list_append_nodup`, `string_list_append_list`,
+ `string_list_insert`, `string_list_split`, and/or
+ `string_list_split_in_place`.
. Can check if a string is in the list using `string_list_has_string` or
`unsorted_string_list_has_string` and get it from the list using
@@ -141,6 +142,11 @@ write `string_list_insert(...)-util = ...;`.
ownership of a malloc()ed string to a `string_list` that has
`strdup_string` set.
+`string_list_append_list`::
+
+ Append the strings from one string_list to the end of another
+ one.
+
`sort_string_list`::
Sort the list's entries by string value in `strcmp()` order.
diff --git a/string-list.c b/string-list.c
index aabb25e..803acd1 100644
--- a/string-list.c
+++ b/string-list.c
@@ -212,6 +212,15 @@ struct string_list_item *string_list_append(struct
string_list *list,
list-strdup_strings ? xstrdup(string) : (char
*)string);
}
+void string_list_append_list(struct string_list *dst, struct string_list *src)
+{
+ struct string_list_item *item;
+
+ ALLOC_GROW(dst-items, dst-nr + src-nr, dst-alloc);
+ for_each_string_list_item(item, src)
+ string_list_append(dst, item-string);
+}
+
/* Yuck */
static compare_strings_fn compare_for_qsort;
diff --git a/string-list.h b/string-list.h
index de6769c..7b0ae86 100644
--- a/string-list.h
+++ b/string-list.h
@@ -76,6 +76,14 @@ void string_list_remove_duplicates(struct string_list
*sorted_list, int free_uti
struct string_list_item *string_list_append(struct string_list *list, const
char *string);
/*
+ * Add all strings from src to the end of dst. If dst-strdup_string
+ * is set, then the strings are copied; otherwise the new
+ * string_list_entries refer to the input strings. src is left
+ * unchanged.
+ */
+void string_list_append_list(struct string_list *dst, struct string_list *src);
+
+/*
* Like string_list_append(), except string is never copied. When
* list-strdup_strings is set, this function can be used to hand
* ownership of a malloc()ed string to list without making an extra
--
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
[RFC 05/11] remote.c: add infrastructure to handle --prune=pattern
This will soon be used to allow the user to tell what reference
namespaces should be subjected to pruning. But since the callers of
these functions still use PARSE_OPT_NOARG, the new functionality is
not yet visible.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
remote.c | 35 +--
remote.h | 11 +++
2 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/remote.c b/remote.c
index 297e52f..89c9eaa 100644
--- a/remote.c
+++ b/remote.c
@@ -6,7 +6,6 @@
#include revision.h
#include dir.h
#include tag.h
-#include string-list.h
#include argv-array.h
#include mergesort.h
@@ -64,9 +63,16 @@ int prune_option_parse(const struct option *opt, const char
*arg, int unset)
struct prune_option *target = opt-value;
if (unset) {
+ if (arg) {
+ error(--no-prune must not be used with an argument);
+ return 1;
+ }
target-prune = 0;
+ string_list_clear(target-prune_patterns, 0);
} else {
target-prune = 1;
+ if (arg)
+ string_list_append(target-prune_patterns, arg);
}
return 0;
}
@@ -104,20 +110,37 @@ void prune_option_fill(struct remote *remote,
prune_option-prune = default_prune;
}
}
+
+ if (prune_option-prune !prune_option-prune_patterns.nr) {
+ /*
+* We want to prune, but no pruning patterns were
+* specified on the command line. Default to *.
+*/
+ string_list_append(prune_option-prune_patterns, *);
+ }
}
void argv_push_prune_option(struct argv_array *argv,
struct prune_option *prune_option)
{
- if (prune_option-prune != -1)
- argv_array_pushf(argv,
-prune_option-prune
-? --prune
-: --no-prune);
+ if (prune_option-prune != -1) {
+ if (prune_option-prune prune_option-prune_patterns.nr) {
+ struct string_list_item *item;
+
+ for_each_string_list_item(item,
prune_option-prune_patterns)
+ argv_array_pushf(argv, --prune=%s,
item-string);
+ } else {
+ argv_array_pushf(argv,
+prune_option-prune
+? --prune
+: --no-prune);
+ }
+ }
}
void prune_option_clear(struct prune_option *prune_option)
{
+ string_list_clear(prune_option-prune_patterns, 0);
}
static int valid_remote(const struct remote *remote)
diff --git a/remote.h b/remote.h
index 21ff4cb..a484290 100644
--- a/remote.h
+++ b/remote.h
@@ -2,6 +2,7 @@
#define REMOTE_H
#include parse-options.h
+#include string-list.h
enum {
REMOTE_CONFIG,
@@ -53,15 +54,18 @@ struct remote {
char *http_proxy;
};
-/* Structure to hold parsed --prune/--no-prune options */
+/* Structure to hold parsed --prune/--prune=pattern/--no-prune options */
struct prune_option {
/* Should we prune at all? -1 is indeterminate. */
int prune;
+
+ /* Arguments passed to --prune=pattern */
+ struct string_list prune_patterns;
};
-#define PRUNE_OPTION_INIT { -1 }
+#define PRUNE_OPTION_INIT { -1, STRING_LIST_INIT_DUP }
-/* parse_opts() callback for --prune/--no-prune options */
+/* parse_opts() callback for --prune/--prune=pattern/--no-prune options */
int prune_option_parse(const struct option *opt, const char *arg, int unset);
/*
@@ -272,7 +276,6 @@ struct ref *guess_remote_head(const struct ref *head,
* Return refs that no longer exist on remote and that match one of
* the patterns.
*/
-struct string_list;
struct ref *get_stale_heads(struct refspec *refs, int ref_count,
struct ref *fetch_map,
struct string_list *patterns);
--
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
