RE: [PATCH] contrib/git-credential-gnome-keyring.c: small stylistic cleanups
John Szakmeister wrote:
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];
No need for these castings, a gpointer is void *, so there's no need to cast
them.
--
Felipe Contreras
--
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] push: Allow @ shortcut with git-push
Tomo Krajina wrote:
Until now, HEAD could be used with git-push to push the current
branch. Now @ is a shortcut to HEAD, but it didn't work when
pushing branches. It fails with:
fatal: remote part of refspec is not a valid name in @
Reinterpret all branch names from argv in order for @ to be used
when pushing branches.
Signed-off-by: Tomo Krajina tkraj...@gmail.com
---
builtin/push.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/builtin/push.c b/builtin/push.c
index 7b1b66c..51c0200 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -494,7 +494,20 @@ int cmd_push(int argc, const char **argv, const char
*prefix)
if (argc 0) {
repo = argv[0];
- set_refspecs(argv + 1, argc - 1);
+
+ char *refs[argc - 1];
+ int i;
+ for(i = 1; i argc; i++) {
+ refs[i - 1] = argv[i];
+
+ struct strbuf buf = STRBUF_INIT;
+ interpret_branch_name(argv[i], strlen(argv[i]), buf);
+
+ if(buf.buf strlen(buf.buf) 0)
+ refs[i - 1] = buf.buf;
+ }
+
+ set_refspecs(refs, argc - 1);
}
rc = do_push(repo, flags);
--
I don't think this is the right way to go. There are many places where HEAD
cannot be replaced with @, or @{u}, or any of such syntaxes.
We might want to do this kind of replacement in many other places, but we would
need to make sure it makes sense.
Moreover, in order for this patch to be considered you need to add tests.
Cheers.
--
Felipe Contreras
--
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 v6 06/10] fast-export: add new --refspec option
Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: But it does not have to stay that way. In order to move things forward in that direction, this new configuration has to be distinguishable from the traditional refspec, as it embodies a different concept. Is it a different concept? % git config remote.origin.fetch '+refs/heads/*:refs/remotes-test/origin/*' % git fetch origin master What do you call this thing? --^ -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Junio C Hamano wrote: * fc/transport-helper-fixes (2013-11-13) 12 commits - remote-bzr: support the new 'force' option - transport-helper: add support to delete branches - fast-export: add support to delete refs - fast-import: add support to delete refs - transport-helper: add support for old:new refspec - fast-export: add new --refspec option - fast-export: improve argument parsing - test-hg.sh: tests are now expected to pass - transport-helper: check for 'forced update' message - transport-helper: add 'force' to 'export' helpers - transport-helper: don't update refs in dry-run - transport-helper: mismerge fix Updates transport-helper, fast-import and fast-export to allow the ref mapping and ref deletion in a way similar to the natively supported transports. The option name --refspec needs to be rethought. It does not mean what refspec usually means, even though it shares the same syntax with refspec; calling it --refspec only because it shares the same syntax is like calling it --asciistring and does not make sense. Not true. remote.name.fetch is a refspec, and doesn't specify what to fetch, so does the refspec capability in remote helpers, and so does the proposed --refspec option. It is exactly what it already means. -- Felipe Contreras -- 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] contrib/git-credential-gnome-keyring.c: small stylistic cleanups
Signed-off-by: John Szakmeister j...@szakmeister.net
Reviewed-by: Felipe Contreras felipe.contre...@gmail.com
---
v2 removes some unnecessary casting noticed by Felipe. Thanks for the
feedback Felipe!
.../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..302122c 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 = user_data;
+ int *done = data[0];
+ GnomeKeyringResult *r = 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) ? basename + 1
Please Confirm
Greetings to you, I am Jack Kofi, esq. I want to solicit your consideration to receive some funds (US$9.5M) on my behalf. Get back to me if you are interested so that i can provide you with more details. Yours Sincerely, Jack Kofi -- 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] remote: fix status with branch...rebase=preserve
Commit 66713ef (pull: allow pull to preserve merges when rebasing)
didn't include an update so 'git remote status' parses
branch.name.rebase=preserve
correctly, let's do that.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/remote.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 4e14891..5e4ab66 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -309,8 +309,13 @@ static int config_read_branches(const char *key, const
char *value, void *cb)
space = strchr(value, ' ');
}
string_list_append(info-merge, xstrdup(value));
- } else
- info-rebase = git_config_bool(orig_key, value);
+ } else {
+ int v = git_config_maybe_bool(orig_key, value);
+ if (v = 0)
+ info-rebase = v;
+ else if (!strcmp(value, preserve))
+ info-rebase = 1;
+ }
}
return 0;
}
--
1.8.4.2+fc1
--
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/4] remote-helpers: fixes
Felipe Contreras (3): remote-helpers: add extra safety checks remote-hg: fix 'shared path' path remote-hg: add tests for special filenames jcb91 (1): remote-hg: avoid buggy strftime() contrib/remote-helpers/git-remote-bzr | 14 +--- contrib/remote-helpers/git-remote-hg | 19 +++--- contrib/remote-helpers/test-hg.sh | 68 +++ 3 files changed, 92 insertions(+), 9 deletions(-) -- 1.8.4.2+fc1 -- 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/4] remote-hg: avoid buggy strftime()
From: jcb91 joshuacookebar...@gmail.com
error on pull: fatal: Invalid raw date in ident: remote-hg
Neither %s nor %z are officially supported by python, they may work on
some (most?) platforms, but not all.
removed strftime use of %s and %z, which are not officially supported by
python, with standard formats
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index c6026b9..a81d59e 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -538,7 +538,7 @@ def export_ref(repo, name, kind, head):
print commit %s % ref
print mark :%d % (note_mark)
-print committer remote-hg %s % (ptime.strftime('%s %z'))
+print committer remote-hg %d %s % (ptime.time(),
gittz(ptime.timezone))
desc = Notes for %s\n % (name)
print data %d % (len(desc))
print desc
--
1.8.4.2+fc1
--
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/4] remote-hg: fix 'shared path' path
If the repository is moved, the absolute path of the shared repository would fail. Make sure it's always up-to-date. Reported-by: Michael Davis mjmda...@gmail.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-hg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index aa1d230..718ef95 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -416,6 +416,9 @@ def get_repo(url, alias): local_path = os.path.join(dirname, 'clone') if not os.path.exists(local_path): hg.share(myui, shared_path, local_path, update=False) +else: +# make sure the shared path is always up-to-date +util.writefile(os.path.join(local_path, '.hg', 'sharedpath'), hg_path) repo = hg.repository(myui, local_path) try: -- 1.8.4.2+fc1 -- 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/4] remote-helpers: add extra safety checks
Suggested-by: Roman Ovchinnikov coolthec...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 14 ++
contrib/remote-helpers/git-remote-hg | 14 ++
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 054161a..858ba3c 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -884,6 +884,16 @@ def main(args):
global branches, peers
global transports
+marks = None
+is_tmp = False
+gitdir = os.environ.get('GIT_DIR', None)
+
+if len(args) 3:
+die('Not enough arguments.')
+
+if not gitdir:
+die('GIT_DIR not set')
+
alias = args[1]
url = args[2]
@@ -892,7 +902,6 @@ def main(args):
blob_marks = {}
parsed_refs = {}
files_cache = {}
-marks = None
branches = {}
peers = {}
transports = []
@@ -900,11 +909,8 @@ def main(args):
if alias[5:] == url:
is_tmp = True
alias = hashlib.sha1(alias).hexdigest()
-else:
-is_tmp = False
prefix = 'refs/bzr/%s' % alias
-gitdir = os.environ['GIT_DIR']
dirname = os.path.join(gitdir, 'bzr', alias)
if not is_tmp:
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index a81d59e..aa1d230 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -1165,6 +1165,16 @@ def main(args):
global dry_run
global notes, alias
+marks = None
+is_tmp = False
+gitdir = os.environ.get('GIT_DIR', None)
+
+if len(args) 3:
+die('Not enough arguments.')
+
+if not gitdir:
+die('GIT_DIR not set')
+
alias = args[1]
url = args[2]
peer = None
@@ -1185,16 +1195,12 @@ def main(args):
if alias[4:] == url:
is_tmp = True
alias = hashlib.sha1(alias).hexdigest()
-else:
-is_tmp = False
-gitdir = os.environ['GIT_DIR']
dirname = os.path.join(gitdir, 'hg', alias)
branches = {}
bmarks = {}
blob_marks = {}
parsed_refs = {}
-marks = None
parsed_tags = {}
filenodes = {}
fake_bmark = None
--
1.8.4.2+fc1
--
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 4/4] remote-hg: add tests for special filenames
So that we check that UTF-8 and spaces work fine.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg.sh | 68 +++
1 file changed, 68 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 72f745d..56840ff 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -442,6 +442,74 @@ test_expect_success 'remote new bookmark multiple branch
head' '
# cleanup previous stuff
rm -rf hgrepo
+test_expect_success 'fetch special filenames' '
+ test_when_finished rm -rf hgrepo gitrepo LC_ALL=C
+
+ LC_ALL=en_US.UTF-8
+ export LC_ALL
+
+ (
+ hg init hgrepo
+ cd hgrepo
+
+ echo test æ rø
+ hg add æ rø
+ echo test ø~?
+ hg add ø~?
+ hg commit -m add-utf-8
+ echo test æ rø
+ hg commit -m test-utf-8
+ hg rm ø~?
+ hg mv æ rø ø~?
+ hg commit -m hg-mv-utf-8
+ )
+
+ (
+ git clone hg::hgrepo gitrepo
+ cd gitrepo
+ git -c core.quotepath=false ls-files ../actual
+ )
+ echo ø~? expected
+ test_cmp expected actual
+'
+
+test_expect_success 'push special filenames' '
+ test_when_finished rm -rf hgrepo gitrepo LC_ALL=C
+
+ mkdir -p tmp cd tmp
+
+ LC_ALL=en_US.UTF-8
+ export LC_ALL
+
+ (
+ hg init hgrepo
+ cd hgrepo
+
+ echo one content
+ hg add content
+ hg commit -m one
+ )
+
+ (
+ git clone hg::hgrepo gitrepo
+ cd gitrepo
+
+ echo test æ rø
+ git add æ rø
+ git commit -m utf-8
+
+ git push
+ )
+
+ (cd hgrepo
+ hg update
+ hg manifest ../actual
+ )
+
+ printf content\næ rø\n expected
+ test_cmp expected actual
+'
+
setup_big_push () {
(
hg init hgrepo
--
1.8.4.2+fc1
--
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] completion: fix completion of certain aliases
Some commands need the first word to determine the actual action that is
being executed, however, the command is wrong when we use an alias, for
example 'alias.p=push', if we try to complete 'git p origin ', the
result would be wrong because __git_complete_remote_or_refspec() doesn't
know where it come from.
So let's override words[1], so the alias 'p' is override by the actual
command, 'push'.
Reported-by: Aymeric Beaumet aymeric.beau...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 1 +
contrib/completion/git-completion.zsh | 1 +
2 files changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index dba3c15..c14bac4 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2530,6 +2530,7 @@ __git_main ()
local expansion=$(__git_aliased_command $command)
if [ -n $expansion ]; then
+ words[1]=$expansion
completion_func=_git_${expansion//-/_}
declare -f $completion_func /dev/null $completion_func
fi
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index fac5e71..3eeb7f8 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -96,6 +96,7 @@ __git_zsh_bash_func ()
local expansion=$(__git_aliased_command $command)
if [ -n $expansion ]; then
+ words[1]=$expansion
completion_func=_git_${expansion//-/_}
declare -f $completion_func /dev/null $completion_func
fi
--
1.8.4.2+fc1
--
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 11/21] pack-objects: use bitmaps when packing objects
This week's nits...
I found this harder to read than the previous patch, but I think it's
mostly because the existing code is already a bit tangled. I think the
second item below is worth fixing, though.
Jeff King p...@peff.net writes:
+static off_t write_reused_pack(struct sha1file *f)
+{
+ uint8_t buffer[8192];
We usually just call this 'unsigned char'. I can see why this would be
more portable, but git would already fall apart badly on an architecture
where char is not 8 bits.
+ off_t to_write;
+ int fd;
+
+ if (!is_pack_valid(reuse_packfile))
+ return 0;
+
+ fd = git_open_noatime(reuse_packfile-pack_name);
+ if (fd 0)
+ return 0;
+
+ if (lseek(fd, sizeof(struct pack_header), SEEK_SET) == -1) {
+ close(fd);
+ return 0;
+ }
You do an error return if any of the syscalls in this routine fails, but
there is only one caller and it immediately dies:
} + packfile_size = write_reused_pack(f);
} + if (!packfile_size)
} + die_errno(failed to re-use existing pack);
So if you just died here, when the error happens, you could take the
chance to tell the user _which_ syscall failed.
+
+ if (reuse_packfile_offset 0)
+ reuse_packfile_offset = reuse_packfile-pack_size - 20;
+
+ to_write = reuse_packfile_offset - sizeof(struct pack_header);
+
+ while (to_write) {
+ int read_pack = xread(fd, buffer, sizeof(buffer));
+
+ if (read_pack = 0) {
+ close(fd);
+ return 0;
Similar to the above, but this one may also clobber the 'errno' during
close(), which can lead to misleading messages.
+ }
+
+ if (read_pack to_write)
+ read_pack = to_write;
+
+ sha1write(f, buffer, read_pack);
Not your fault, but sha1write() is an odd function -- it purportedly is
int sha1write(struct sha1file *f, const void *buf, unsigned int count);
but it can only return 0. This goes back all the way to c38138c
(git-pack-objects: write the pack files with a SHA1 csum, 2005-06-26).
+ to_write -= read_pack;
+ }
+
+ close(fd);
+ written += reuse_packfile_objects;
+ return reuse_packfile_offset - sizeof(struct pack_header);
+}
[...]
-static int add_object_entry(const unsigned char *sha1, enum object_type type,
- const char *name, int exclude)
+static int add_object_entry_1(const unsigned char *sha1, enum object_type
type,
+ int flags, uint32_t name_hash,
+ struct packed_git *found_pack, off_t found_offset)
{
[...]
- for (p = packed_git; p; p = p-next) {
- off_t offset = find_pack_entry_one(sha1, p);
- if (offset) {
- if (!found_pack) {
- if (!is_pack_valid(p)) {
- warning(packfile %s cannot be
accessed, p-pack_name);
- continue;
+ if (!found_pack) {
+ for (p = packed_git; p; p = p-next) {
+ off_t offset = find_pack_entry_one(sha1, p);
+ if (offset) {
+ if (!found_pack) {
+ if (!is_pack_valid(p)) {
+ warning(packfile %s cannot be
accessed, p-pack_name);
+ continue;
+ }
+ found_offset = offset;
+ found_pack = p;
}
- found_offset = offset;
- found_pack = p;
+ if (exclude)
+ break;
+ if (incremental)
+ return 0;
+ if (local !p-pack_local)
+ return 0;
+ if (ignore_packed_keep p-pack_local
p-pack_keep)
+ return 0;
}
- if (exclude)
- break;
- if (incremental)
- return 0;
- if (local !p-pack_local)
- return 0;
- if (ignore_packed_keep p-pack_local p-pack_keep)
- return 0;
}
}
This function makes my head spin, and you're indenting it yet another
level.
If it's not too much work, can you split it into the three parts that it
really is? IIUC it boils down to
do we have this already?
possibly apply 'exclude', then return
are
Re: [PATCH v3 12/21] rev-list: add bitmap mode to speed up object lists
Jeff King p...@peff.net writes: Documentation/git-rev-list.txt | 1 + Documentation/rev-list-options.txt | 8 builtin/rev-list.c | 39 ++ 3 files changed, 48 insertions(+) Nice and short. Cheating though, as a lot of the support code is from [10/21] ;-) Reviewed-by: Thomas Rast t...@thomasrast.ch -- 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
[PATCH v2 00/10] teach replace objects to sha1_object_info_extended()
Here is version 2 of a patch series to improve the way sha1_object_info_extended() behaves when it is passed a replaced object. The idea is to add a flags argument to it in the same way as what has been done to read_sha1_file(). This patch series was inspired by a sub thread in this discussion: http://thread.gmane.org/gmane.comp.version-control.git/238118 Patches 1/10, 2/10 and 3/10 are cleanups, among them only 1/10 is new. Patches 4/10, 5/10 and 6/10 were also in the previous version. Patches 7/10, 8/10, 9/10 and 10/10 are new. They add a new --format option to list replace refs. 'short' (which is the default), 'medium' and 'full' formats are supported. This could be considered another patch series, but it is also related, because it uses sha1_object_info() and it fixes its use in builtin/replace.c by unsetting the global variable read_replace_refs in cmd_replace(). Christian Couder (10): Rename READ_SHA1_FILE_REPLACE flag to LOOKUP_REPLACE_OBJECT replace_object: don't check read_replace_refs twice Introduce lookup_replace_object_extended() to pass flags Add an unsigned flags parameter to sha1_object_info_extended() t6050: show that git cat-file --batch fails with replace objects sha1_file: perform object replacement in sha1_object_info_extended() builtin/replace: teach listing using short, medium or full formats t6050: add tests for listing with --format builtin/replace: unset read_replace_refs Documentation/git-replace: describe --format option Documentation/git-replace.txt | 19 - builtin/cat-file.c| 2 +- builtin/replace.c | 63 ++- cache.h | 12 ++--- replace_object.c | 3 --- sha1_file.c | 20 +++--- streaming.c | 2 +- t/t6050-replace.sh| 32 ++ 8 files changed, 127 insertions(+), 26 deletions(-) -- 1.8.5.1.102.g090758b -- 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 10/10] Documentation/git-replace: describe --format option
Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Documentation/git-replace.txt | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index f373ab4..7a07828 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git replace' [-f] object replacement 'git replace' -d object... -'git replace' -l [pattern] +'git replace' [--format=format] [-l [pattern]] DESCRIPTION --- @@ -70,6 +70,23 @@ OPTIONS Typing git replace without arguments, also lists all replace refs. +--format=format:: + When listing, use the specified format, which can be one of + 'short', 'medium' and 'full'. When omitted, the format + defaults to 'short'. + +FORMATS +--- + +The following format are available: + +* 'short': + replaced sha1 +* 'medium': + replaced sha1 - replacement sha1 +* 'full' + replaced sha1 (replaced type) - replacement sha1 (replacement type) + CREATING REPLACEMENT OBJECTS -- 1.8.5.1.102.g090758b -- 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 07/10] builtin/replace: teach listing using short, medium or full formats
By default when listing replace refs, only the sha1 of the
replaced objects are shown.
In many cases, it is much nicer to be able to list all the
sha1 of the replaced objects along with the sha1 of the
replacment objects.
And in other cases it might be interesting to also show the
types of the replaced and replacement objects.
This patch introduce a new --format=fmt option where
fmt can be any of the following:
'short': this is the same as when no --format
option is used, that is only the sha1 of
the replaced objects are shown
'medium': this also lists the sha1 of the
replacement objects
'full': this shows the sha1 and the type of both
the replaced and the replacement objects
Some documentation and some tests will follow.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 61 ---
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index b1bd3ef..9f3619a 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -16,27 +16,65 @@
static const char * const git_replace_usage[] = {
N_(git replace [-f] object replacement),
N_(git replace -d object...),
- N_(git replace -l [pattern]),
+ N_(git replace [--format=format] [-l [pattern]]),
NULL
};
+enum repl_fmt { SHORT, MEDIUM, FULL };
+
+struct show_data {
+ const char *pattern;
+ enum repl_fmt fmt;
+};
+
static int show_reference(const char *refname, const unsigned char *sha1,
int flag, void *cb_data)
{
- const char *pattern = cb_data;
+ struct show_data *data = cb_data;
+
+ if (!fnmatch(data-pattern, refname, 0)) {
+ if (data-fmt == SHORT)
+ printf(%s\n, refname);
+ else if (data-fmt == MEDIUM)
+ printf(%s - %s\n, refname, sha1_to_hex(sha1));
+ else { /* data-fmt == FULL */
+ unsigned char object[20];
+ enum object_type obj_type, repl_type;
- if (!fnmatch(pattern, refname, 0))
- printf(%s\n, refname);
+ if (get_sha1(refname, object))
+ return error(Failed to resolve '%s' as a valid
ref., refname);
+
+ obj_type = sha1_object_info(object, NULL);
+ repl_type = sha1_object_info(sha1, NULL);
+
+ printf(%s (%s) - %s (%s)\n, refname,
typename(obj_type),
+ sha1_to_hex(sha1), typename(repl_type));
+ }
+ }
return 0;
}
-static int list_replace_refs(const char *pattern)
+static int list_replace_refs(const char *pattern, const char *format)
{
+ struct show_data data;
+
if (pattern == NULL)
pattern = *;
+ data.pattern = pattern;
+
+ if (format == NULL || *format == '\0' || !strcmp(format, short))
+ data.fmt = SHORT;
+ else if (!strcmp(format, medium))
+ data.fmt = MEDIUM;
+ else if (!strcmp(format, full))
+ data.fmt = FULL;
+ else
+ die(invalid replace format '%s'\n
+ valid formats are 'short', 'medium' and 'full'\n,
+ format);
- for_each_replace_ref(show_reference, (void *) pattern);
+ for_each_replace_ref(show_reference, (void *) data);
return 0;
}
@@ -127,10 +165,12 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
int cmd_replace(int argc, const char **argv, const char *prefix)
{
int list = 0, delete = 0, force = 0;
+ const char *format = NULL;
struct option options[] = {
OPT_BOOL('l', list, list, N_(list replace refs)),
OPT_BOOL('d', delete, delete, N_(delete replace refs)),
OPT_BOOL('f', force, force, N_(replace the ref if it
exists)),
+ OPT_STRING(0, format, format, N_(format), N_(use this
format)),
OPT_END()
};
@@ -140,6 +180,10 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
usage_msg_opt(-l and -d cannot be used together,
git_replace_usage, options);
+ if (format delete)
+ usage_msg_opt(--format and -d cannot be used together,
+ git_replace_usage, options);
+
if (force (list || delete))
usage_msg_opt(-f cannot be used with -d or -l,
git_replace_usage, options);
@@ -157,6 +201,9 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
if (argc != 2)
usage_msg_opt(bad number of arguments,
git_replace_usage, options);
+ if (format)
+
[PATCH v2 09/10] builtin/replace: unset read_replace_refs
When checking to see if some objects are of the same type
and when displaying the type of objects, git replace uses
the sha1_object_info() function.
Unfortunately this function by default respects replace
refs, so instead of the type of a replaced object, it
gives the type of the replacement object which might
be different.
To fix this bug, and because git replace should work at a
level before replacement takes place, let's unset the
read_replace_refs global variable at the beginning of
cmd_replace().
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 2 ++
t/t6050-replace.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 9f3619a..1672870 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -174,6 +174,8 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
OPT_END()
};
+ read_replace_refs = 0;
+
argc = parse_options(argc, argv, prefix, options, git_replace_usage, 0);
if (list delete)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 3627b4c..f15b805 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -296,7 +296,7 @@ test_expect_success 'test --format medium' '
test_cmp expected actual
'
-test_expect_failure 'test --format full' '
+test_expect_success 'test --format full' '
{
echo $H1 (commit) - $BLOB (blob)
echo $BLOB (blob) - $REPLACED (blob)
--
1.8.5.1.102.g090758b
--
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 04/10] Add an unsigned flags parameter to sha1_object_info_extended()
This parameter is not used yet, but it will be used to tell
sha1_object_info_extended() if it should perform object
replacement or not.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
sha1_file.c| 6 +++---
streaming.c| 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index b2ca775..b15c064 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -238,7 +238,7 @@ static int batch_one_object(const char *obj_name, struct
batch_options *opt,
return 0;
}
- if (sha1_object_info_extended(data-sha1, data-info) 0) {
+ if (sha1_object_info_extended(data-sha1, data-info,
LOOKUP_REPLACE_OBJECT) 0) {
printf(%s missing\n, obj_name);
fflush(stdout);
return 0;
diff --git a/cache.h b/cache.h
index 563f85f..701e42c 100644
--- a/cache.h
+++ b/cache.h
@@ -1104,7 +1104,7 @@ struct object_info {
} packed;
} u;
};
-extern int sha1_object_info_extended(const unsigned char *, struct object_info
*);
+extern int sha1_object_info_extended(const unsigned char *, struct object_info
*, unsigned flags);
/* Dumb servers support */
extern int update_server_info(int);
diff --git a/sha1_file.c b/sha1_file.c
index 4fb2f17..482037e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2443,7 +2443,7 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
return 0;
}
-int sha1_object_info_extended(const unsigned char *sha1, struct object_info
*oi)
+int sha1_object_info_extended(const unsigned char *sha1, struct object_info
*oi, unsigned flags)
{
struct cached_object *co;
struct pack_entry e;
@@ -2477,7 +2477,7 @@ int sha1_object_info_extended(const unsigned char *sha1,
struct object_info *oi)
rtype = packed_object_info(e.p, e.offset, oi);
if (rtype 0) {
mark_bad_packed_object(e.p, sha1);
- return sha1_object_info_extended(sha1, oi);
+ return sha1_object_info_extended(sha1, oi, 0);
} else if (in_delta_base_cache(e.p, e.offset)) {
oi-whence = OI_DBCACHED;
} else {
@@ -2499,7 +2499,7 @@ int sha1_object_info(const unsigned char *sha1, unsigned
long *sizep)
oi.typep = type;
oi.sizep = sizep;
- if (sha1_object_info_extended(sha1, oi) 0)
+ if (sha1_object_info_extended(sha1, oi, LOOKUP_REPLACE_OBJECT) 0)
return -1;
return type;
}
diff --git a/streaming.c b/streaming.c
index debe904..9659f18 100644
--- a/streaming.c
+++ b/streaming.c
@@ -113,7 +113,7 @@ static enum input_source istream_source(const unsigned char
*sha1,
oi-typep = type;
oi-sizep = size;
- status = sha1_object_info_extended(sha1, oi);
+ status = sha1_object_info_extended(sha1, oi, 0);
if (status 0)
return stream_error;
--
1.8.5.1.102.g090758b
--
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 06/10] sha1_file: perform object replacement in sha1_object_info_extended()
sha1_object_info_extended() should perform object replacement
if it is needed.
The simplest way to do that is to make it call
lookup_replace_object_extended().
And now its unsigned flags parameter is used as it is passed
to lookup_replace_object_extended().
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
sha1_file.c| 13 +++--
t/t6050-replace.sh | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 482037e..ee224e4 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2448,8 +2448,9 @@ int sha1_object_info_extended(const unsigned char *sha1,
struct object_info *oi,
struct cached_object *co;
struct pack_entry e;
int rtype;
+ const unsigned char *real = lookup_replace_object_extended(sha1, flags);
- co = find_cached_object(sha1);
+ co = find_cached_object(real);
if (co) {
if (oi-typep)
*(oi-typep) = co-type;
@@ -2461,23 +2462,23 @@ int sha1_object_info_extended(const unsigned char
*sha1, struct object_info *oi,
return 0;
}
- if (!find_pack_entry(sha1, e)) {
+ if (!find_pack_entry(real, e)) {
/* Most likely it's a loose object. */
- if (!sha1_loose_object_info(sha1, oi)) {
+ if (!sha1_loose_object_info(real, oi)) {
oi-whence = OI_LOOSE;
return 0;
}
/* Not a loose object; someone else may have just packed it. */
reprepare_packed_git();
- if (!find_pack_entry(sha1, e))
+ if (!find_pack_entry(real, e))
return -1;
}
rtype = packed_object_info(e.p, e.offset, oi);
if (rtype 0) {
- mark_bad_packed_object(e.p, sha1);
- return sha1_object_info_extended(sha1, oi, 0);
+ mark_bad_packed_object(e.p, real);
+ return sha1_object_info_extended(real, oi, 0);
} else if (in_delta_base_cache(e.p, e.offset)) {
oi-whence = OI_DBCACHED;
} else {
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index b90dbdc..bb785ec 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,7 +276,7 @@ test_expect_success '-f option bypasses the type check' '
git replace -f HEAD^ $BLOB
'
-test_expect_failure 'git cat-file --batch works on replace objects' '
+test_expect_success 'git cat-file --batch works on replace objects' '
git replace | grep $PARA3
echo $PARA3 | git cat-file --batch
'
--
1.8.5.1.102.g090758b
--
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 03/10] Introduce lookup_replace_object_extended() to pass flags
Currently, there is only one caller to lookup_replace_object()
that can benefit from passing it some flags, but we expect
that there could be more.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
cache.h | 6 ++
sha1_file.c | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 873a6b5..563f85f 100644
--- a/cache.h
+++ b/cache.h
@@ -773,6 +773,12 @@ static inline const unsigned char
*lookup_replace_object(const unsigned char *sh
return sha1;
return do_lookup_replace_object(sha1);
}
+static inline const unsigned char *lookup_replace_object_extended(const
unsigned char *sha1, unsigned flag)
+{
+ if (! (flag LOOKUP_REPLACE_OBJECT))
+ return sha1;
+ return lookup_replace_object(sha1);
+}
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/sha1_file.c b/sha1_file.c
index 76e9f32..4fb2f17 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2591,8 +2591,7 @@ void *read_sha1_file_extended(const unsigned char *sha1,
void *data;
char *path;
const struct packed_git *p;
- const unsigned char *repl = (flag LOOKUP_REPLACE_OBJECT)
- ? lookup_replace_object(sha1) : sha1;
+ const unsigned char *repl = lookup_replace_object_extended(sha1, flag);
errno = 0;
data = read_object(repl, type, size);
--
1.8.5.1.102.g090758b
--
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 02/10] replace_object: don't check read_replace_refs twice
Since ecef (inline lookup_replace_object() calls, May 15 2011) the read_replace_refs global variable is checked twice, once in lookup_replace_object() and once again in do_lookup_replace_object(). As do_lookup_replace_object() is called only from lookup_replace_object(), we can remove the check in do_lookup_replace_object(). Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- replace_object.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/replace_object.c b/replace_object.c index d0b1548..cdcaf8c 100644 --- a/replace_object.c +++ b/replace_object.c @@ -97,9 +97,6 @@ const unsigned char *do_lookup_replace_object(const unsigned char *sha1) int pos, depth = MAXREPLACEDEPTH; const unsigned char *cur = sha1; - if (!read_replace_refs) - return sha1; - prepare_replace_object(); /* Try to recursively replace the object */ -- 1.8.5.1.102.g090758b -- 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 16/21] repack: handle optional files created by pack-objects
Jeff King p...@peff.net writes: We ask pack-objects to pack to a set of temporary files, and then rename them into place. Some files that pack-objects creates may be optional (like a .bitmap file), in which case we would not want to call rename(). We already call stat() and make the chmod optional if the file cannot be accessed. We could simply skip the rename step in this case, but that would be a minor regression in noticing problems with non-optional files (like the .pack and .idx files). Instead, we can now annotate extensions as optional, and skip them if they don't exist (and otherwise rely on rename() to barf). Signed-off-by: Jeff King p...@peff.net Reviewed-by: Thomas Rast t...@thomasrast.ch -- 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 v3 17/21] repack: consider bitmaps when performing repacks
Jeff King p...@peff.net writes: From: Vicent Marti tan...@gmail.com Since `pack-objects` will write a `.bitmap` file next to the `.pack` and `.idx` files, this commit teaches `git-repack` to consider the new bitmap indexes (if they exist) when performing repack operations. This implies moving old bitmap indexes out of the way if we are repacking a repository that already has them, and moving the newly generated bitmap indexes into the `objects/pack` directory, next to their corresponding packfiles. Since `git repack` is now capable of handling these `.bitmap` files, a normal `git gc` run on a repository that has `pack.writebitmaps` set to true in its config file will generate bitmap indexes as part of the garbage collection process. Alternatively, `git repack` can be called with the `-b` switch to explicitly generate bitmap indexes if you are experimenting and don't want them on all the time. Signed-off-by: Vicent Marti tan...@gmail.com Signed-off-by: Jeff King p...@peff.net Reviewed-by: Thomas Rast t...@thomasrast.ch -- 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 v3 18/21] count-objects: recognize .bitmap in garbage-checking
Jeff King p...@peff.net writes: From: Nguyễn Thái Ngọc Duy pclo...@gmail.com Count-objects will report any garbage files in the packs directory, including files whose extensions it does not know (case 1), and files whose matching .pack file is missing (case 2). Without having learned about .bitmap files, the current code reports all such files as garbage (case 1), even if their pack exists. Instead, they should be treated as case 2. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Signed-off-by: Jeff King p...@peff.net Reviewed-by: Thomas Rast t...@thomasrast.ch -- 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 v3 19/21] t: add basic bitmap functionality tests
Jeff King p...@peff.net writes: Now that we can read and write bitmaps, we can exercise them with some basic functionality tests. These tests aren't particularly useful for seeing the benefit, as the test repo is too small for it to make a difference. However, we can at least check that using bitmaps does not break anything. Signed-off-by: Jeff King p...@peff.net Reviewed-by: Thomas Rast t...@thomasrast.ch One nit: +test_expect_success JGIT 'jgit can read our bitmaps' ' + git clone . compat-us.git + ( + cd compat-us.git The name suggests a bare repo, but it is a full clone. Not that it matters. -- 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 v3 20/21] t/perf: add tests for pack bitmaps
Jeff King p...@peff.net writes: +test_perf 'simulated fetch' ' + have=$(git rev-list HEAD --until=1.week.ago -1) This will give you HEAD if your GIT_PERF_LARGE_REPO hasn't seen any activity lately. I'd prefer something that always takes a fixed commit, e.g. HEAD~1000, keeping the perf test reproducible over time (not over changing GIT_PERF_LARGE_REPO, of course). -- 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 v3 21/21] pack-bitmap: implement optional name_hash cache
Jeff King p...@peff.net writes: Test origin/master HEAD^ HEAD - 5310.2: repack to disk36.81(37.82+1.43) 47.70(48.74+1.41) +29.6% 47.75(48.70+1.51) +29.7% 5310.3: simulated clone 30.78(29.70+2.14) 1.08(0.97+0.10) -96.5% 1.07(0.94+0.12) -96.5% 5310.4: simulated fetch 3.16(6.10+0.08) 3.54(10.65+0.06) +12.0% 1.70(3.07+0.06) -46.2% 5310.6: partial bitmap36.76(43.19+1.81) 6.71(11.25+0.76) -81.7% 4.08(6.26+0.46) -88.9% You can see that the time spent on an incremental fetch goes down, as our delta heuristics are able to do their work. And we save time on the partial bitmap clone for the same reason. The time now goes down across the board compared to master. Good job! Signed-off-by: Vicent Marti tan...@gmail.com Signed-off-by: Jeff King p...@peff.net Reviewed-by: Thomas Rast t...@thomasrast.ch -- 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
[PATCH 2/4] subtree: allow --squash and --message with push
Signed-off-by: Matthew Ogilvie mmogilvi_...@miniinfo.net --- contrib/subtree/git-subtree.sh | 8 +++- contrib/subtree/git-subtree.txt | 9 - 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 998a9c5..56d915f 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -743,11 +743,17 @@ cmd_push() if [ $# -ne 2 ]; then die You must provide repository refspec fi + + opts= + if [ -n $squash ]; then + opts=-squash + fi + if [ -e $dir ]; then repository=$1 refspec=$2 echo git push using: $repository $refspec - localrev=$(git subtree split --prefix=$prefix) || die + localrev=$(git subtree split --prefix=$prefix $opts --message=$message) || die git push $repository $localrev:refs/heads/$refspec else die '$dir' must already exist. Try 'git subtree add'. diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index 92e7a4d..03092bc 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -140,20 +140,11 @@ OPTIONS want to manipulate. This option is mandatory for all commands. - -OPTIONS FOR add, merge, pull, rejoin --- -m message:: --message=message:: - This option is only valid for add, merge, pull, and - split '--rejoin'. - Specify message as the commit message for the merge commit. --squash:: - This option is only valid for add, merge, pull, and - split '--rejoin'. - Instead of merging the entire history from the subtree project, produce only a single commit that contains all the differences you want to merge, and then merge that -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] subtree: add --edit option
Signed-off-by: Matthew Ogilvie mmogilvi_...@miniinfo.net
---
contrib/subtree/git-subtree.sh | 37 +
contrib/subtree/git-subtree.txt | 4
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 56d915f..ac82b4d 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,6 +21,7 @@ d show debug messages
P,prefix= the name of the subdir to split out
m,message=use the given message as the commit message for the merge commit
squashmerge subtree changes as a single commit
+edit allow user to edit squash commit message interactively
options for 'split'
annotate= add a prefix to commit message of new commits
b,branch= create a new branch from the split subtree
@@ -45,6 +46,7 @@ ignore_joins=
annotate=
squash=
message=
+edit=
debug()
{
@@ -91,6 +93,7 @@ while [ $# -gt 0 ]; do
--ignore-joins) ignore_joins=1 ;;
--no-ignore-joins) ignore_joins= ;;
--squash) squash=1 ;;
+ --edit) edit=1 ;;
--no-squash) squash= ;;
--) break ;;
*) die Unexpected option: $opt ;;
@@ -434,13 +437,12 @@ new_squash_commit()
old=$1
oldsub=$2
newsub=$3
+ msg_file=$4
tree=$(toptree_for_commit $newsub) || exit $?
if [ -n $old ]; then
- squash_msg $dir $oldsub $newsub |
- git commit-tree $tree -p $old || exit $?
+ git commit-tree $tree -p $old -F $msg_file || exit $?
else
- squash_msg $dir $newsub |
- git commit-tree $tree || exit $?
+ git commit-tree $tree -F $msg_file || exit $?
fi
}
@@ -556,7 +558,13 @@ cmd_add_commit()
fi
if [ -n $squash ]; then
- rev=$(new_squash_commit $rev) || exit $?
+ msg_file=$GIT_DIR/COMMIT_EDITMSG
+ squash_msg $dir $rev $msg_file
+ if [ -n $edit ]; then
+ git_editor $msg_file
+ fi
+ rev=$(new_squash_commit $rev $msg_file) || exit $?
+ rm -f $msg_file
commit=$(add_squashed_msg $rev $dir |
git commit-tree $tree $headp -p $rev) || exit $?
else
@@ -672,8 +680,14 @@ cmd_split()
say Subtree is already at commit $latest_new.
exit 0
fi
- new=$(new_squash_commit $old $sub $latest_new) \
- || exit $?
+ msg_file=$GIT_DIR/COMMIT_EDITMSG
+ squash_msg $dir $sub $latest_new $msg_file
+ if [ -n $edit ]; then
+ git_editor $msg_file
+ fi
+ new=$(new_squash_commit $old $sub $latest_new \
+ $msg_file) || exit $?
+ rm -f $msg_file
debug New squash commit: $new
fi
@@ -708,7 +722,13 @@ cmd_merge()
say Subtree is already at commit $rev.
exit 0
fi
- new=$(new_squash_commit $old $sub $rev) || exit $?
+ msg_file=$GIT_DIR/COMMIT_EDITMSG
+ squash_msg $dir $sub $rev $msg_file
+ if [ -n $edit ]; then
+ git_editor $msg_file
+ fi
+ new=$(new_squash_commit $old $sub $rev $msg_file) ||
exit $?
+ rm -f $msg_file
debug New squash commit: $new
rev=$new
fi
@@ -748,6 +768,7 @@ cmd_push()
if [ -n $squash ]; then
opts=-squash
fi
+ # Can't easily pass on --edit because of stdout capture redirection
if [ -e $dir ]; then
repository=$1
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 03092bc..16525d4 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -177,6 +177,10 @@ OPTIONS
the merge back to the mainline, not the synthetic subtree
history.
+--edit::
+ When used with '--squash', bring up an editor on the squash
+ commit message, to allow customizing it.
+
OPTIONS FOR split
-
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] subtree: support split --rejoin --squash
Allow using --squash with git subtree split --rejoin. It
will still split off (and save to --branch) the complete
subtree history, but the merge done for the --rejoin will
be merging a squashed representation of the new subtree
commits, instead of the commits themselves (similar to
how git subtree merge --squash works).
Signed-off-by: Matthew Ogilvie mmogilvi_...@miniinfo.net
---
I can think of a couple of possible objections to this patch.
Are these (or any others) worth fixing?
1. Perhaps someone want the saved subtree (--branch) to have
a squashed representation as well, as an option? Maybe we
need two different --squash options? Something
like --rejoin-squash?
2. It could definitely use some automated tests. In fact,
pre-existing --squash functionality is hardly tested at
all, either.
See patch 4 comments for a script I use to help with
mostly-manual testing.
contrib/subtree/git-subtree.sh | 60 +++--
contrib/subtree/git-subtree.txt | 27 ---
2 files changed, 63 insertions(+), 24 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 7d7af03..998a9c5 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -20,14 +20,13 @@ q quiet
d show debug messages
P,prefix= the name of the subdir to split out
m,message=use the given message as the commit message for the merge commit
+squashmerge subtree changes as a single commit
options for 'split'
annotate= add a prefix to commit message of new commits
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
rejoinmerge the new branch back into HEAD
- options for 'add', 'merge', 'pull' and 'push'
-squashmerge subtree changes as a single commit
eval $(echo $OPTS_SPEC | git rev-parse --parseopt -- $@ || echo exit $?)
@@ -229,13 +228,19 @@ find_latest_squash()
sq=
main=
sub=
+ par1=
+ par2=
git log --grep=^git-subtree-dir: $dir/*\$ \
- --pretty=format:'START %H%n%s%n%n%b%nEND%n' HEAD |
- while read a b junk; do
- debug $a $b $junk
+ --pretty=format:'START %H %P%n%s%n%n%b%nEND%n' HEAD |
+ while read a b c d junk; do
+ debug $a $b $c $d $junk
debug {{$sq/$main/$sub}}
case $a in
- START) sq=$b ;;
+ START)
+ sq=$b
+ par1=$c
+ par2=$d
+ ;;
git-subtree-mainline:) main=$b ;;
git-subtree-split:) sub=$b ;;
END)
@@ -243,7 +248,8 @@ find_latest_squash()
if [ -n $main ]; then
# a rejoin commit?
# Pretend its sub was a squash.
- sq=$sub
+ assert [ $main = $par1 ]
+ sq=$par2
fi
debug Squash found: $sq $sub
echo $sq $sub
@@ -252,6 +258,8 @@ find_latest_squash()
sq=
main=
sub=
+ par1=
+ par2=
;;
esac
done
@@ -565,6 +573,13 @@ cmd_split()
debug Splitting $dir...
cache_setup || exit $?
+ if [ -n $rejoin ]; then
+ ensure_clean
+ if [ -n $squash ]; then
+ first_split=$(find_latest_squash $dir)
+ fi
+ fi
+
if [ -n $onto ]; then
debug Reading history for --onto=$onto...
git rev-list $onto |
@@ -630,13 +645,6 @@ cmd_split()
die No new revisions were found
fi
- if [ -n $rejoin ]; then
- debug Merging split branch into HEAD...
- latest_old=$(cache_get latest_old)
- git merge -s ours \
- -m $(rejoin_msg $dir $latest_old $latest_new) \
- $latest_new 2 || exit $?
- fi
if [ -n $branch ]; then
if rev_exists refs/heads/$branch; then
if ! rev_is_descendant_of_branch $latest_new $branch;
then
@@ -649,6 +657,30 @@ cmd_split()
git update-ref -m 'subtree split' refs/heads/$branch
$latest_new || exit $?
say $action branch '$branch'
fi
+ if [ -n
[PATCH/BAD 4/4] subtree: poor bugfix for split new commits with parents before previous split
Bug description: Unless you use --ignore-joins, git subtree split's
optimization to avoid re-scanning all of history can trim too much.
Any new merged branches that have parents before the previous split
will not be re-attached properly in the split-off subtree.
In the extreme case (if all the changes occurred on such
branches), I've seen the old subtree head might not be an
ancestor of the new head at all.
This fix is only for illustration. It probably should not be
included as-is; it probably scales worse than using --ignore-joins
for anything much beyond trivial cases.
I'm not sure it is possible to speed it up much (while remaining
correct) without switching to a better language than shell script.
I'm not sure how to explain the constraint clearly (or even
precisely define the minimal constraint). One attempt:
Exclude from unrevs any rejoin commit X for which ANY new commit
(not just revs itself) has some other common ancestor (merge base)
besides X. (New commit is one that is not an ancestor of
some previous rejoin commit.)
It would probably be fairly straightforward to adapt
graph traversal algorithms to do this efficiently, but as near
as I can tell, none of the existing options in git-rev-list or
git-merge-base really does anything useful for optimizing this
in shell script...
The simplest traversal technique to fix this might
be if there was a way to make history traversal only stop
at SPECIFIC unrevs, instead of any ancestor of any unrevs.
Other workarounds besides this patch:
* Use --ignore-joins and wait for the really slow processing...
* Plan ahead and delay: After using git subtree split --rejoin,
leave the rejoin merge commit off on a side branch until such time
that all other pre-split branches have been merged. Then
merge the merge at that later time. Only do rejoins fairly
rarely, based on the schedule of merging other branches.
* Ignore the problem: Allow the occasional falsely-disconnected
branch roots to be generated by split. Of course, this
means --ignore-joins would no longer generate a consistent
subtree history, it is hard to examine what actually changed
in the false roots, etc.
* Perhaps manually use temporary grafts or similar to hide rejoins
that would throw it off when doing later splits.
[Intentionally not signed off: Poor performance.]
---
Testing: Below I include a script I've been using to help with
mostly-manual testing. I regularly modify it based on
what I'm testing at the moment. It basically
creates and manipulates a subtree out of git's own contrib
directory.
It may be convenient to use this on a copy of git's
repository instead of the copy in which you are messing with
git-subtree (avoiding changing code out from under the script).
It may also be convenient to symlink git-subtree to the top-level
directory, rather than copy it, so you don't need to keep
re-copying it.
--CUT--
#!/bin/sh
die()
{ echo $@ 12
exit 1
}
GIT=../git-sandbox/bin-wrappers/git
#GIT=git
DBG=
#DBG=-d
EDIT=
#EDIT=--edit
git branch -D br-contrib
git checkout 73bbc0796b4ce65bfb1a12b47a0edc27845ecf50 || die checkout
$GIT subtree split -P contrib \
--branch br-contrib --squash --rejoin $EDIT || die subtree 1
git tag -f step1
git merge -m 'MY MERGE1' 68a65f5fe54c2b21bfe16ef3a0b48956ecf5658a ||
die merge 1
$GIT subtree split -P contrib \
--branch br-contrib --squash --rejoin || die subtree 2
git tag -f step2
git merge -m 'MY MERGE2' 15f7221686eac053902b906c278680b485c865ce || \
die merge 2
$GIT subtree split -P contrib \
--branch br-contrib --squash --rejoin $EDIT || die subtree 3
#
if [ -n $EDIT ]; then
exit 0
fi
git tag -f step3
git merge -m 'MY MERGE3' 26145c9c73ed51bbd8261949d31899d6507519d5 || \
die merge 3
$GIT subtree split -P contrib \
$DBG --branch br-contrib --squash --rejoin || die subtree 4
git tag -f step4
git merge -m 'MY MERGE4' 583736c0bcf09adaa5621b142d8e43c22354041b || \
die merge 4
$GIT subtree split -P contrib \
--branch br-contrib --squash --rejoin || die subtree 5
git tag -f step5
--CUT--
contrib/subtree/git-subtree.sh | 61 +-
1 file changed, 55 insertions(+), 6 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index ac82b4d..6ff4362 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -36,6 +36,8 @@ PATH=$PATH:$(git --exec-path)
require_work_tree
+nl='
+'
quiet=
branch=
debug=
@@ -224,6 +226,13 @@ try_remove_previous()
fi
}
+try_remove()
+{
+ if rev_exists $1; then
+ echo $1
+ fi
+}
+
find_latest_squash()
{
debug Looking for latest squash ($dir)...
@@ -293,8 +302,8 @@ find_existing_splits()
debug Prior: $main - $sub
cache_set $main
Re: [PATCH v2 09/10] builtin/replace: unset read_replace_refs
Christian Couder chriscool at tuxfamily.org writes: When checking to see if some objects are of the same type and when displaying the type of objects, git replace uses the sha1_object_info() function. Unfortunately this function by default respects replace refs, so instead of the type of a replaced object, it gives the type of the replacement object which might be different. Wasn't replace mechanism tightened, so that replacing object must be the same type as replaced object? Is there a situation where you might want replace object with different type of object? -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/10] builtin/replace: unset read_replace_refs
On Sat, Dec 7, 2013 at 8:02 PM, Jakub Narebski jna...@gmail.com wrote: Wasn't replace mechanism tightened, so that replacing object must be the same type as replaced object? Yes, but if --force is used or if the replace ref is created with git update-ref, then it is not enforced. Is there a situation where you might want replace object with different type of object? This was discussed: http://thread.gmane.org/gmane.comp.version-control.git/233157/ 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: Git reports
I looked at man git-http-backend, and I didn't understand a thing. I'll look at it tomorrow again with a clear head. On 7 December 2013 00:22, Jeff King p...@peff.net wrote: On Fri, Dec 06, 2013 at 11:26:51AM -0800, Jonathan Nieder wrote: I am cloning over http I am guessing you are using the dumb (plain static file transfer) HTTP protocol. With that protocol the server doesn't do anything other than shuttle out files, so it doesn't need to do its own progress reporting. Yeah, that would also explain why GIT_TRACE_PACKET produced no output. Perhaps the client should do some progress reporting based on file sizes and amount downloaded so far, but it's hard to get excited about given the existence of smart (transfer only what is needed) HTTP protocol. See git-http-backend(1) for details. You get some very verbose and nasty progress with -vv. It would be nice to have a regular throughput meter for dumb-http, though. I haven't bothered adding one so far because I don't expect many people are using http. However, if we start supporting fetching via bundles over http, then it will be very nice to have some kind of progress display there (since the main use is to get gigantic full clones). -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: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Am 07.12.2013 00:52, schrieb Junio C Hamano:
* kb/doc-exclude-directory-semantics (2013-11-07) 1 commit
- gitignore.txt: clarify recursive nature of excluded directories
Originally merged to 'next' on 2013-11-13
Kicked back to 'pu' to replace with a newer reroll ($gmane/237814
looked OK but there seems to have some loose ends in the
discussion).
I'm unaware of any loose ends, could you clarify?
Btw. $gmane/237814 seems to be a different topic, the version in next (and now
in pu) was $gmane/237429.
* kb/fast-hashmap (2013-11-18) 14 commits
(merged to 'next' on 2013-12-06 at f90be3d)
Damn, a day too late :-) I found these two glitches today...is a fixup patch OK
or should I do a reroll (or separate patch on top)?
Thanks,
Karsten
--- 8 ---
Subject: [PATCH] fixup! add a hashtable implementation that supports O(1)
removal
Use 'unsigned int' for hash-codes everywhere.
Extending 'struct hashmap_entry' with an int-sized member shouldn't waste
memory on 64-bit systems. This is already documented in api-hashmap.txt,
but needs '__attribute__((__packed__))' to work. Reduces e.g.
struct name_entry {
struct hashmap_entry ent;
int namelen;
char *name;
};
from 32 to 24 bytes.
Signed-off-by: Karsten Blees bl...@dcon.de
---
hashmap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hashmap.h b/hashmap.h
index f5b3b61..b64567b 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -15,7 +15,7 @@ extern unsigned int memihash(const void *buf, size_t len);
/* data structures */
-struct hashmap_entry {
+struct __attribute__((__packed__)) hashmap_entry {
struct hashmap_entry *next;
unsigned int hash;
};
@@ -43,7 +43,7 @@ extern void hashmap_free(struct hashmap *map, int
free_entries);
/* hashmap_entry functions */
-static inline void hashmap_entry_init(void *entry, int hash)
+static inline void hashmap_entry_init(void *entry, unsigned int hash)
{
struct hashmap_entry *e = entry;
e-hash = hash;
--
1.8.5.1.178.g0a9afc1.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: What's cooking in git.git (Dec 2013, #02; Fri, 6)
On Sat, Dec 7, 2013 at 4:03 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Junio C Hamano wrote: * fc/transport-helper-fixes (2013-11-13) 12 commits - remote-bzr: support the new 'force' option - transport-helper: add support to delete branches - fast-export: add support to delete refs - fast-import: add support to delete refs - transport-helper: add support for old:new refspec - fast-export: add new --refspec option - fast-export: improve argument parsing - test-hg.sh: tests are now expected to pass - transport-helper: check for 'forced update' message - transport-helper: add 'force' to 'export' helpers - transport-helper: don't update refs in dry-run - transport-helper: mismerge fix Updates transport-helper, fast-import and fast-export to allow the ref mapping and ref deletion in a way similar to the natively supported transports. The option name --refspec needs to be rethought. It does not mean what refspec usually means, even though it shares the same syntax with refspec; calling it --refspec only because it shares the same syntax is like calling it --asciistring and does not make sense. Not true. remote.name.fetch is a refspec, and doesn't specify what to fetch, so does the refspec capability in remote helpers, and so does the proposed --refspec option. It is exactly what it already means. Not to mention that you can apply the first part of the series without any problems: - fast-export: improve argument parsing - test-hg.sh: tests are now expected to pass - transport-helper: check for 'forced update' message - transport-helper: add 'force' to 'export' helpers - transport-helper: don't update refs in dry-run - transport-helper: mismerge fix Even: - remote-bzr: support the new 'force' option The rest is for old:new :to-delete refspecs. To take hostage the whole patch series because of the name --refspec (which is perfectly fine) is just an excuse to not fix the issues already present. -- Felipe Contreras -- 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 03.12.2013 19:21, schrieb Jeff King: 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. Yes. With pointers, its a very close call regarding space. Let's take bitmap_index.bitmaps / struct stored_bitmap as an example. I'm assuming 8 byte pointers and an average load factor of 0.5. struct stored_bitmap is already kind of an entry structure (key + value) allocated on the heap. This is a very common szenario, all hash.[ch] - hashmap.[ch] conversions were that way. The average khash memory requirement per entry is (on top of the data on the heap): (key + value + flags) / load-factor = (8 + 8 + .25) / .5 = 32.5 bytes For the hashmap conversion, I simply injected struct hashmap_entry into the existing structure, adding 12 bytes per entry. So the total hashmap memory per entry is: hashmap_entry + (entry-pointer / load-factor) = 12 + (8 / .5) = 28 bytes 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. Well, khash_sha1 maps to void *, so I guess its not that important :-) But if you care about type safety, a common core implementation with a few small wrapper macros would be hugely preferable, don't you think? 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. Resizing is reasonably fast and straightforward for both open addressing and chaining. My 'copy three times' remark above was specific to the rehash-in-place stunt in kh_resize (if you haven't wondered what these 64 multi-statement-lines do, you probably don't wanna know... ;-) But its still best if you know the target size and can prevent resizing altogether. 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). The locality advantage of open addressing _only_ applies when storing the data directly in the table, but AFAIK we're not doing that anywhere in git. Compared to open addressing with pointers, chaining in fact has _better_ locality. Iterating a linked list (i.e. chaining) accesses exactly one (1.0) memory location per element. Iterating an array of pointers (i.e. open addressing with linear probing) accesses ~1.125 memory locations per element (assuming 8 byte pointers and 64 byte cache lines, array[8] will be in a different cache line than array[0], thus the +.125). Of course, any implementation can add more pointer-following to that minimum. E.g. khash uses separate flags and keys arrays and triangular numbers as probe sequence, so its up to 3 memory locations per element. Hashmap, on the other hand, allows you to inject it's per-entry data into the
[PATCH v8 1/6] transport-helper: mismerge fix
Commit 9c51558 (transport-helper: trivial code shuffle) moved these
lines above, but 99d9ec0 (Merge branch 'fc/transport-helper-no-refspec')
had a wrong merge conflict and readded them.
Reported-by: Richard Hansen rhan...@bbn.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
transport-helper.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 673b7c2..b66c7fd 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -875,9 +875,6 @@ static int push_refs_with_export(struct transport
*transport,
}
free(private);
- if (ref-deletion)
- die(remote-helpers do not support ref deletion);
-
if (ref-peer_ref) {
if (strcmp(ref-peer_ref-name, ref-name))
die(remote-helpers do not support old:new
syntax);
--
1.8.5.1+fc1
--
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 v8 0/6] transport-helper: fixes
Hi, These patches add support for remote helpers --force, --dry-run, and reporting forced update. No changes since last version. The later patches for renaming branches, deleting them, custom refspecs have beend dropped because Junio doesn't like the name --refspec, although the argument is clearly a refspec as it's used that way extensively through Git. Felipe Contreras (4): transport-helper: mismerge fix transport-helper: don't update refs in dry-run transport-helper: add 'force' to 'export' helpers transport-helper: check for 'forced update' message Richard Hansen (2): test-hg.sh: tests are now expected to pass remote-bzr: support the new 'force' option Documentation/gitremote-helpers.txt | 4 contrib/remote-helpers/git-remote-bzr | 31 ++- contrib/remote-helpers/test-bzr.sh| 22 +- contrib/remote-helpers/test-hg.sh | 4 ++-- git-remote-testgit.sh | 18 ++ t/t5801-remote-helpers.sh | 13 + transport-helper.c| 25 + 7 files changed, 105 insertions(+), 12 deletions(-) -- 1.8.5.1+fc1 -- 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 v8 6/6] remote-bzr: support the new 'force' option
From: Richard Hansen rhan...@bbn.com
Signed-off-by: Richard Hansen rhan...@bbn.com
Acked-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 31 ++-
contrib/remote-helpers/test-bzr.sh| 22 +-
2 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 054161a..f1ba477 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -685,7 +685,8 @@ def do_export(parser):
peer = bzrlib.branch.Branch.open(peers[name],
possible_transports=transports)
try:
-peer.bzrdir.push_branch(branch, revision_id=revid)
+peer.bzrdir.push_branch(branch, revision_id=revid,
+overwrite=force)
except bzrlib.errors.DivergedBranches:
print error %s non-fast forward % ref
continue
@@ -719,8 +720,32 @@ def do_capabilities(parser):
print *import-marks %s % path
print *export-marks %s % path
+print option
print
+class InvalidOptionValue(Exception):
+pass
+
+def get_bool_option(val):
+if val == 'true':
+return True
+elif val == 'false':
+return False
+else:
+raise InvalidOptionValue()
+
+def do_option(parser):
+global force
+opt, val = parser[1:3]
+try:
+if opt == 'force':
+force = get_bool_option(val)
+print 'ok'
+else:
+print 'unsupported'
+except InvalidOptionValue:
+print error '%s' is not a valid value for option '%s' % (val, opt)
+
def ref_is_valid(name):
return not True in [c in name for c in '~^: \\']
@@ -883,6 +908,7 @@ def main(args):
global is_tmp
global branches, peers
global transports
+global force
alias = args[1]
url = args[2]
@@ -896,6 +922,7 @@ def main(args):
branches = {}
peers = {}
transports = []
+force = False
if alias[5:] == url:
is_tmp = True
@@ -931,6 +958,8 @@ def main(args):
do_import(parser)
elif parser.check('export'):
do_export(parser)
+elif parser.check('option'):
+do_option(parser)
else:
die('unhandled command: %s' % line)
sys.stdout.flush()
diff --git a/contrib/remote-helpers/test-bzr.sh
b/contrib/remote-helpers/test-bzr.sh
index 5c50251..ae26dbb 100755
--- a/contrib/remote-helpers/test-bzr.sh
+++ b/contrib/remote-helpers/test-bzr.sh
@@ -65,13 +65,33 @@ test_expect_success 'pushing' '
test_cmp expected actual
'
+test_expect_success 'forced pushing' '
+ (
+ cd gitrepo
+ echo three-new content
+ git commit -a --amend -m three-new
+ git push -f
+ )
+
+ (
+ cd bzrrepo
+ # the forced update overwrites the bzr branch but not the bzr
+ # working directory (it tries to merge instead)
+ bzr revert
+ )
+
+ echo three-new expected
+ cat bzrrepo/content actual
+ test_cmp expected actual
+'
+
test_expect_success 'roundtrip' '
(
cd gitrepo
git pull
git log --format=%s -1 origin/master actual
)
- echo three expected
+ echo three-new expected
test_cmp expected actual
(cd gitrepo git push git pull)
--
1.8.5.1+fc1
--
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 v8 5/6] test-hg.sh: tests are now expected to pass
From: Richard Hansen rhan...@bbn.com Signed-off-by: Richard Hansen rhan...@bbn.com Signed-off-by: Junio C Hamano gits...@pobox.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/test-hg.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh index 72f745d..aacd8a9 100755 --- a/contrib/remote-helpers/test-hg.sh +++ b/contrib/remote-helpers/test-hg.sh @@ -599,7 +599,7 @@ test_expect_success 'remote big push fetch first' ' ) ' -test_expect_failure 'remote big push force' ' +test_expect_success 'remote big push force' ' test_when_finished rm -rf hgrepo gitrepo* setup_big_push @@ -629,7 +629,7 @@ test_expect_failure 'remote big push force' ' check_bookmark hgrepo new_bmark six ' -test_expect_failure 'remote big push dry-run' ' +test_expect_success 'remote big push dry-run' ' test_when_finished rm -rf hgrepo gitrepo* setup_big_push -- 1.8.5.1+fc1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Karsten Blees karsten.bl...@gmail.com writes: Extending 'struct hashmap_entry' with an int-sized member shouldn't waste memory on 64-bit systems. This is already documented in api-hashmap.txt, but needs '__attribute__((__packed__))' to work. Reduces e.g. You'd have to guard __attribute__((__packed__)) with some compiler detection in git-compat-util.h 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: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Am 07.12.2013 23:23, schrieb Thomas Rast: Karsten Blees karsten.bl...@gmail.com writes: Extending 'struct hashmap_entry' with an int-sized member shouldn't waste memory on 64-bit systems. This is already documented in api-hashmap.txt, but needs '__attribute__((__packed__))' to work. Reduces e.g. You'd have to guard __attribute__((__packed__)) with some compiler detection in git-compat-util.h though. Isn't that already handled? __attribute__ is already widely used (e.g. for printf formats), and platforms that don't support it define it as empty (e.g. MSVC). Or do you mean I should account for compiler-specific variants (#pragma pack...)? -- 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] i18n: move the trailing space out of translatable strings
I've got this with Vietnamese translation
$ git status
HEAD được tách rời từorigin/master
One does not need to understand Vietnamese to see that a space is
missing before origin/master and this is because the original string
has a trailing space, but the translated one omits it.
I could fix vi.po alone, but it'd be better to avoid similar mistakes
for all translations by moving the trailing space out of all
translatable strings (*). This is inline with how we handle newlines
(e.g. *printf_ln wrappers) but it's not widespread enough to make new
*printf_space wrappers.
(*) the strings are detected by
make pot; msgcat --no-wrap po/git.pot|grep 'msgid.* $'
and if you do it after this patch, you will see maybe 3 matched lines
from git-bisect.sh and git-am.sh that I didn't bother to fix.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
BTW msgcat...|grep 'msgid.*\n$' gives 159 matches. Low hanging
fruit..
builtin/clean.c | 5 +++--
builtin/clone.c | 4 ++--
wt-status.c | 26 +-
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 615cd57..2b7e694 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -656,7 +656,7 @@ static int filter_by_patterns_cmd(void)
pretty_print_dels();
clean_print_color(CLEAN_COLOR_PROMPT);
- printf(_(Input ignore patterns ));
+ printf(%s , _(Input ignore patterns));
clean_print_color(CLEAN_COLOR_RESET);
if (strbuf_getline(confirm, stdin, '\n') != EOF)
strbuf_trim(confirm);
@@ -754,7 +754,8 @@ static int ask_each_cmd(void)
/* Ctrl-D should stop removing files */
if (!eof) {
qname = quote_path_relative(item-string, NULL, buf);
- printf(_(remove %s? ), qname);
+ printf(_(remove %s?), qname);
+ putchar(' ');
if (strbuf_getline(confirm, stdin, '\n') != EOF) {
strbuf_trim(confirm);
} else {
diff --git a/builtin/clone.c b/builtin/clone.c
index 874e0fd..d48ccee 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -551,12 +551,12 @@ static void update_remote_refs(const struct ref *refs,
if (check_connectivity) {
if (transport-progress)
- fprintf(stderr, _(Checking connectivity... ));
+ fprintf(stderr, _(Checking connectivity...));
if (check_everything_connected_with_transport(iterate_ref_map,
0, rm,
transport))
die(_(remote did not send all necessary objects));
if (transport-progress)
- fprintf(stderr, _(done.\n));
+ fprintf(stderr, %s, _(done.\n));
}
if (refs) {
diff --git a/wt-status.c b/wt-status.c
index 4625cdb..3637656 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -330,11 +330,11 @@ static void wt_status_print_change_data(struct wt_status
*s,
if (d-new_submodule_commits || d-dirty_submodule) {
strbuf_addstr(extra, ();
if (d-new_submodule_commits)
- strbuf_addf(extra, _(new commits, ));
+ strbuf_addf(extra, %s, , _(new commits));
if (d-dirty_submodule DIRTY_SUBMODULE_MODIFIED)
- strbuf_addf(extra, _(modified content, ));
+ strbuf_addf(extra, %s, , _(modified
content));
if (d-dirty_submodule DIRTY_SUBMODULE_UNTRACKED)
- strbuf_addf(extra, _(untracked content, ));
+ strbuf_addf(extra, %s, , _(untracked
content));
strbuf_setlen(extra, extra.len - 2);
strbuf_addch(extra, ')');
}
@@ -1244,30 +1244,30 @@ void wt_status_print(struct wt_status *s)
s-branch !strcmp(s-branch, HEAD));
if (s-branch) {
- const char *on_what = _(On branch );
+ const char *on_what = _(On branch);
const char *branch_name = s-branch;
if (!prefixcmp(branch_name, refs/heads/))
branch_name += 11;
else if (!strcmp(branch_name, HEAD)) {
branch_status_color = color(WT_STATUS_NOBRANCH, s);
if (state.rebase_in_progress ||
state.rebase_interactive_in_progress) {
- on_what = _(rebase in progress; onto );
+ on_what = _(rebase in progress; onto);
branch_name = state.onto;
} else if
Thomas Sabo Charms 2013
Ich mag positiv denken, um für meine Situation Direkt Verwendung als Buch mit Tiffany Schmuck, Wann immer ich tun, die subtile Botschaft zu fahren weniger relevant. Die Schnell bläulich -Boxen sind in der Tat so schnell wie Amors Pfeil durchbohren einer Frau Mitte . Oder vielleicht das Geld maybeit genau, welche spektakulär ist , Thomas Sabo Charms 2013 http://www.markenschmuckonlineoutletsale.com/thomas-sabo-schmuck versteht que . Sie konnte es nicht etwas von Tiffany und Co. auch auch ohne Zerschlagung der Bank und zusätzlich Anzeige eine Delle in Ihre Finanzen Karten aber es Heck, in DEM einem Saugnapf Wenn verrückt in DEM . Selbst ein paar grundlegende geradeaus ein paar metallische itemsrun Vielleicht drei oder Umstände Might Größer als Ihr Wert Einkaufen in der Nähe fast jeden anderen Schmuck-Shop , aber es wieder einmal ist es der Website-Name Tiffany, tatsächlich in den Augen und zusätzlich zu decken Ihren Mann POSSESS . Natürlich ist Tiffany Edelstein Diamant ring . Auswahl eines Ring Zum einen aber ich muss über die Berichte von der Regel der Hand Matte , um Welche es ist sicherlich natürlich vollendete , oder denken, wenn Wann haben sie nicht da heute im Laufe des Beziehen . Ob Sie es glauben oder nicht, vielleicht , Männer aller Altersgruppen des Preises Vielleicht Das könnte oder sie ist stilvoll Akzente. Tiffany Co gezeigt, eine breite Palette von Objekten für die Tiffany- dudes. Diamant-Schmuck wirklich das Gefühl erzeugt Sollte Einbeziehung Personal nicht vergessen Geschmack. Tiffany Halskette, Tiffany- Verlobungsringe , Tiffany Stücke oder vielleicht Tiffany Manschettenknöpfe sind eigentlich menrrrs Besonders geeignet für Herren. Wahrscheinlich bin ich bei Tiffany Schmuck Workflow Betrieb oder weg zu halten Vielleicht finden, abschließen Ergebnis von Tiffany bis Ende Mai Die größten Unternehmen in das Layout unterliegen dem Ausland , ich in der Regel wirklich begonnen, selbstbewusst und fühlen sich wunderbar Acerca bekommen auch Tiffany Design von tiffany Steckdose oben auf alternative , durch die ich kann meine específicamente pflegen mit Beat- Trends halten. In meinem Bekleidungskollektion , könnten Sie eine erhebliche Kosten zu teuer Tiffany Stiefel Low Weibchen nicht finden, und reduziert die Kosten Inhalt Etikett Tiffany , dass alle Taschen können die Kleidung richtig zu erfüllen. In der Tat, Günstige Tiffany Steckdose definitiv nicht enttäuscht mich selbst auf das Layout verbessert werden, um verschiedene Geschmacksrichtungen, die ich nur kann normalerweise im Grunde die Quintessenz Praktisch Sicherlich Layout unseres Unternehmens in Geschäftsstelle , Tiffany Outlet in Wahrheit bauen kann wirklich mit Layout konstant effektiv zu arbeiten. Thomas Ward Tiffany Halskette ist ein wirklich IS hat bekam britischen Mode- Freizeit- Designer-Marke , Rock and Roll, Punk Style Bowl zieht Sehr AA Reihe von Pop-Idol - Promi -Modus. Wird Mit IS Trails mit Rock gefüllt - gefüllt Geschmack Schmiede zu gelangen Einer lesen vor Einzelpersonen sind ohne Freundin kaufte es verurteilt , ob oder wann er gedreht Heraeus Sie sich in einem der Business-Kleidung für immer unauslöschlich eingraviert Impressum ausgeprägt. Frühere Aufzeichnungen selten in betreffend ein Voll Geheimnis , Thomas Sabo Charms Anhänger http://www.markenschmuckonlineoutletsale.com/thomas-sabo-schmuck Berühmtheit, färbt Romantische Da Diamanten, verwässerte , die Sie vielleicht in Betracht ziehen Acerca Menschen , die im Falle die Blätter herabfallende Trümmer Filmstars sterben Außerdem Wäre es absolut Werden Mit der Umwelt von den Kristallen gesehen worden. Der Metallring gezeigt, die grundlegende Hilfe für die Tiffany Und Co Outlet implementiert , zusammen mit mit dem TIFFANY STUDIOS Marke. Könnte Tiffany dann jedes einzelne Muster Unter den Komponenten verringern entfernt und zusätzlich Schatten sie in Gruppen aufgeteilt . Nach fehlerfrei handHandWerksGegenStändeaus farbigem Glas , Tiffany könnte zur Arbeit gehen Ausschneiden jedes einzelne Teil des einzigen Glas. - Thomas Sabo Charms 2013 Thomas Sabo Charms Anhänger Thomas Sabo Charms Armband -- View this message in context: http://git.661346.n2.nabble.com/Thomas-Sabo-Charms-2013-tp7600564.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pandora charms online sale
However, in all of the literature version, the mythology because all-natural theology to explain the existence of sin in pandora charms online sale http://www.designerjewelrycheapsale-usa.com the field. In a word, its one filled with possibility of beauty, and complete of strange charms.The ancient Greek, pan is all meant, DORA is present, it is the gods based on the could of Zeus, has got created the most perfect wisdom and additionally gorgeous physical appearance female.In most cases, Pandora adorn post is principally refers to with those big hole drops, very thick chain made from jewelry, comparing individuality, of simple feeling, comes with the national design. Its beads are elegant manual will keep, the pure beads and also sterling silver 925 metallic tong tube combination becomes, artificial Pandora beads. generating diamond vitamins food supplements which include many projects, including bead, range, buckles, the archipelago, so as to obtain. Because they know that just what possess happened, unfortunately things in individual existence, it doesn question using them. No matter which is in the corridor pause in you, to carry rear do not grumble to him. When they ask, precisely what Pandora Charms occurred? Are you fine? So long as one, I fine, as a consequence of carry on moving forward. To tangible exercise cannot only allow you to keep up good health, spirit, and can effectively alleviate the pressure. Pandora charms are certainly extra fashionable with slip above allow the appropriate overall look in methods to some lady directly. Pandora bracelets are often in high want regardless of the season. Neither absolute sure your wristband size? Not problem, you may make use of tape measure in determining the wrist size. Just hold the fabric cassette measure around your wrist and additionally record accurately. Make in your mind which a smart way of finding the correct size will be to render sure you can to fit a finger stuck between the cassette measure and also your wrist. This excellent will help accommodate the Pandora charms or perhaps Pandora beads that will be added your band therefore is not too tight around your wrist. The bracelets, necklaces, and stores can come in 14k gold, sterling silver, sterling silver with 14k gold, and additionally murano glass. To be able to find the charms, drops or perhaps dangles for your Pandora bracelet, browse thru the many categories, collections, and also implemented bracelets pages online. This will explain to you the best marketing and a large number of famous Pandora Jewelry that's presently in vogue. Photographs of all these Pandora charms makes this very very easy to determine if in case these styles are really what you are actually looking for. Within a heart-shaped appeal, PANDORA even structured the special, a vintage feel of jewellery sets. The Oxidized Sterling Metallic and inlaid jewelry materials, beautiful, bright Karl Sidden gem.The complete set of jewelry such as meant for necklaces and bracelets pendants, rings and also earrings upon elegant pendant. The jewellery designs featured by Karl Sidden diamond in Sterling Metallic Compact scroll, become to each needs to be beloved mom ideal hand-crafted jewelry gift idea The exposure of the Pandora drops since well as bracelets would be that you can style most of them in whatever way you want. Assist to make ten people progress their own Pandora bracelets and also you are going to have ten distinctive styles. Have the same people work at it the next day some time you are going to have 10 pandora charms 2013 http://www.designerjewelrycheapsale-usa.com a whole lot more distinctive styles. With the Pandora drops and additionally bracelets, you can easily create individual distinctive item regarding jewelry. Pandora Jewelry are the biggest range at Pandora. A huge number of artwork are for sale in the Pandora Glass Beads category. Pandora Glass drops consist of OEM single root glass beads, Swarovski Crystal beads, OEM Two fold root glass drops, and others. Our consequently possess a wide selection of glass bead features. - Thomas Sabo Charms 2013 Thomas Sabo Charms Anhänger Thomas Sabo Charms Armband -- View this message in context: http://git.661346.n2.nabble.com/pandora-charms-online-sale-tp7600565.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Trivial patches
Felipe Contreras (7): config: avoid yoda conditions add: avoid yoda conditions abspath: trivial style fix t: trivial whitespace cleanups fetch: add missing documentation sha1_name: cleanup interpret_branch_name() sha1_name: simplify track finding Documentation/git-fetch.txt | 3 +++ abspath.c | 2 +- builtin/add.c | 2 +- config.c| 4 ++-- sha1_name.c | 33 + t/t0002-gitfile.sh | 3 +-- t/t0003-attributes.sh | 1 - 7 files changed, 25 insertions(+), 23 deletions(-) -- 1.8.5.1+fc1.2.gebd1fb1 -- 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/7] config: avoid yoda conditions
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index e1d66a1..7a44414 100644
--- a/config.c
+++ b/config.c
@@ -610,7 +610,7 @@ static int git_config_maybe_bool_text(const char *name,
const char *value)
int git_config_maybe_bool(const char *name, const char *value)
{
int v = git_config_maybe_bool_text(name, value);
- if (0 = v)
+ if (v = 0)
return v;
if (git_parse_int(value, v))
return !!v;
@@ -620,7 +620,7 @@ int git_config_maybe_bool(const char *name, const char
*value)
int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
{
int v = git_config_maybe_bool_text(name, value);
- if (0 = v) {
+ if (v = 0) {
*is_bool = 1;
return v;
}
--
1.8.5.1+fc1.2.gebd1fb1
--
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/7] abspath: trivial style fix
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- abspath.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/abspath.c b/abspath.c index e390994..8b3385a 100644 --- a/abspath.c +++ b/abspath.c @@ -143,7 +143,7 @@ static const char *real_path_internal(const char *path, int die_on_error) error_out: free(last_elem); if (*cwd chdir(cwd)) - die_errno (Could not change back to '%s', cwd); + die_errno(Could not change back to '%s', cwd); return retval; } -- 1.8.5.1+fc1.2.gebd1fb1 -- 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 5/7] fetch: add missing documentation
There's no mention of the 'origin' default, or the fact that the upstream tracking branch remote is used. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-fetch.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index e08a028..a7b245d 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -37,6 +37,9 @@ or from several repositories at once if group is given and there is a remotes.group entry in the configuration file. (See linkgit:git-config[1]). +When no remote is specified, by default the `origin` remote will be used, +unless there's an upstream branch configured for the current branch. + OPTIONS --- include::fetch-options.txt[] -- 1.8.5.1+fc1.2.gebd1fb1 -- 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 4/7] t: trivial whitespace cleanups
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t0002-gitfile.sh| 3 +--
t/t0003-attributes.sh | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index cb14425..37e9396 100755
--- a/t/t0002-gitfile.sh
+++ b/t/t0002-gitfile.sh
@@ -7,7 +7,7 @@ Verify that plumbing commands work when .git is a file
. ./test-lib.sh
objpath() {
-echo $1 | sed -e 's|\(..\)|\1/|'
+ echo $1 | sed -e 's|\(..\)|\1/|'
}
objck() {
@@ -19,7 +19,6 @@ objck() {
fi
}
-
test_expect_success 'initial setup' '
REAL=$(pwd)/.real
mv .git $REAL
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 0b98b6f..b9d7947 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -13,7 +13,6 @@ attr_check () {
test_line_count = 0 err
}
-
test_expect_success 'setup' '
mkdir -p a/b/d a/c b
(
--
1.8.5.1+fc1.2.gebd1fb1
--
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
