Re: [PATCH] t4203: fix checks for email address remapping
On 07/13/2013 02:35 AM, Eric Sunshine wrote: Two tests in t4203-mailmap.sh set up the mapping b...@company.xx = b...@company.xy in an apparent attempt to check that email address remapping works as expected (in addition to name remapping which is also tested). To test the remapping, git-shortlog is invoked but the invocation lacks the -e option instructing it to show email addresses, hence the tests do not actually prove that address remapping succeeded. Fix this by instructing git-shortlog to output email addresses as well. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- The very last git-shortlog complex test in the script does use -e and checks that email address remapping actually works, so it's not clear that this patch is needed. The b...@company.xx = b...@company.xy remapping done by the two tests touched by this patch, however, is misleading to the reader since it seems to imply that these two tests want to check address remapping as well. Perhaps a better change would be to remove the address remapping from these two tests. t/t4203-mailmap.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 842b754..3cf64de 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -102,10 +102,10 @@ test_expect_success 'mailmap.file non-existent' ' ' cat expect \EOF -Internal Guy (1): +Internal Guy b...@company.xy (1): second -Repo Guy (1): +Repo Guy aut...@example.com (1): initial EOF @@ -114,15 +114,15 @@ test_expect_success 'name entry after email entry' ' mkdir -p internal_mailmap echo b...@company.xy b...@company.xx internal_mailmap/.mailmap echo Internal Guy b...@company.xx internal_mailmap/.mailmap - git shortlog HEAD actual + git shortlog -e HEAD actual test_cmp expect actual ' cat expect \EOF -Internal Guy (1): +Internal Guy b...@company.xy (1): second -Repo Guy (1): +Repo Guy aut...@example.com (1): initial EOF @@ -131,7 +131,7 @@ test_expect_success 'name entry after email entry, case-insensitive' ' mkdir -p internal_mailmap echo b...@company.xy b...@company.xx internal_mailmap/.mailmap echo Internal Guy b...@company.xx internal_mailmap/.mailmap + So here it is capitalized email address (BUGS@), but at the expect file it's still lower cased. I think this is a bug. Junio was trying to fix it in 543f99173c2d2f648d8f846e24875150f7de03d3 (origin/jc/mailmap-case-insensitivity) So I think we need another yet test case there: commited: Internal Guy b...@company.xx Internal Guy b...@company.xy Having just one entry in the mailmap Internal Guy b...@company.xx b...@company.xy should still work with the shortlog -e - git shortlog HEAD actual + git shortlog -e HEAD actual test_cmp expect actual ' -- 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 7/7] push: document --lockref
Am 12.07.2013 23:19, schrieb Junio C Hamano: Johannes Sixt j...@kdbg.org writes: We have three independent options that the user can choose in any combination: o --force given or not; o --lockref semantics enabled or not; o refspec with or without +; and these two orthogonal preconditions of the push o push is fast-forward or it is not (ff, noff); o the branch at the remote is at the expected rev or it is not (match, mismatch). Here is a table with the expected outcome. ok means that the push is allowed(*), fail means that the push is denied. (Four more lines with --force are omitted because they have ok in all spots.) ff noff ff noff match match mismatch mismatch --lockref +refspec okokdenied denied --lockref refspec ok denied denied denied I am confused with these. The latter is the most typical: git fetch git checkout topic git rebase topic git push --lockref topic where we know it is noff already, and we just want to make sure that nobody mucked with our remote while we are rebasing. Today (without --lockref), the above sequence would fail to push. (Because there is no + and no --force.) If nobody updated the remote, why should this push be denied? And in order to make it succeed, you need to force with +refspec or --force, but that would bypass match/mismatch safety, which makes the whole make sure the other end is unchanged safety meaningless, no? I am suggesting that +refspec would *not* override the match/mismatch safety, but --force would. +refspec okok ok ok This is traditional --force. refspec ok deniedok denied We are not asking for --lockref, so match/mismatch does not affect the outcome. I think you are worried that a deviation from the principle that +refspec == --force hurts current users. But I am arguing that this is not the case because current users do not use --lockref. As you have seen from the table, without --lockref there is *no change* in behavior. I still have not seen an example where +refspec != --force would have unexpected consequences. (The inequality is merely that +refspec fails on mismatch when --lockref was also given while --force does not.) Notice that without --lockref semantics enabled, +refspec and refspec keep the current behavior. But I do not think the above table with --lockref makes much sense. Let's look at noff/match case. That is the only interesting one. This should fail: git push topic due to no-ff. Yes. Your table above makes this fail: git push --lockref topic and the user has to force it, Of course. like this? git push --lockref --force topic ;# or alternatively git push --lockref +topic Why is it even necessary? Because it is no-ff. How do you achieve the push today (without --lockref)? You use one of these two options. It does not change with --lockref. If you make git push --lockref topic succeed in noff/match case, everything makes more sense to me. Not to me, obviously ;) The --lockref option is merely a weaker form of --force but still a way to override the noff check. No; --lockref only adds the check that the destination is at the expected revision, but does *NOT* override the no-ff check. Why should it? (This is not a rethoric question.) (I think I said differently in an earlier messages, but back then things were still blurry. The table in my previous message is what I mean.) If the user wants to keep noff check, the user can simply choose not to use the option. No. If the user wants to keep the no-ff check, she does not use the + in the refspec and does not use --force. (Just like today.) Of course, that form should fail if mismatch. And then you can force it, git push --force [--lockref] topic As --force is anything goes, it does not matter if you give the other option on the command line. ... or the + in the refsepc. -- Hannes -- 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] mailmap: Testing the single letter name case.
This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991 Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- t/t4203-mailmap.sh | 41 + 1 file changed, 41 insertions(+) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 842b754..9ec87a2 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -409,4 +409,45 @@ test_expect_success 'Blame output (complex mapping)' ' test_cmp expect actual.fuzz ' +cat expect \EOF +A shortn...@company.xy (2): + eighth + nineth + +A U Thor aut...@example.com (1): + initial + +CTO c...@company.xx (1): + seventh + +Other Author ot...@author.xx (2): + third + fourth + +Santa Claus santa.cl...@northpole.xx (2): + fifth + sixth + +Some Dude s...@dude.xx (1): + second + +EOF + +# Regression test +# Using a single letter name to check for off-by-one errors in parse_name_and_email +test_expect_success 'check mapping for short names' ' + echo one two + git add two + git commit --author A shortn...@company.xx -m eighth + + echo two two + git add two + git commit --author A shortn...@company.xy -m nineth + + echo A shortn...@company.xy shortn...@company.xx .mailmap + git shortlog HEAD -e actual + + test_cmp expect actual +' + test_done -- 1.8.3.2.776.gfcf213d -- 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] fetch: make --prune configurable
Without git fetch --prune, remote-tracking branches for a branch
the other side already has removed will stay forever. Some people
want to always run git fetch --prune.
To accommodate users who want to either prune always or when fetching
from a particular remote, add two new configuration variables
fetch.prune and remote.name.prune:
- fetch.prune allows to enable prune for all fetch operations.
- remote.name.prune allows to change the behaviour per remote.
The latter will naturally override the former, and the --[no-]prune
option from the command line will override the configured default.
Since --prune is a potentially destructive operation (Git doesn't
keep reflogs for deleted references yet), we don't want to prune
without users consent, so this configuration will not be on by
default.
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Michael Schubert msc...@elegosoft.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Junio, thank you for your detailed feedback and writing the patch.
I didn't find time during the week to write a v2 and I don't feel I
should take any credit here, so please feel free to take authorship
completely.
Thanks.
Documentation/config.txt | 10 ++
builtin/fetch.c | 39 ---
remote.c | 3 ++
remote.h | 1 +
t/t5510-fetch.sh | 82
5 files changed, 130 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53fc5..e4ce7c4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1049,6 +1049,10 @@ fetch.unpackLimit::
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
+fetch.prune::
+ If true, fetch will automatically behave as if the `--prune`
+ option was given on the command line. See also `remote.name.prune`.
+
format.attach::
Enable multipart/mixed attachments as the default for
'format-patch'. The value can also be a double quoted string
@@ -1984,6 +1988,12 @@ remote.name.vcs::
Setting this to a value vcs will cause Git to interact with
the remote with the git-remote-vcs helper.
+remote.name.prune::
+ When set to true, fetching from this remote by default will also
+ remove any remote-tracking branches which no longer exist on the
+ remote (as if the `--prune` option was give on the command line).
+ Overrides `fetch.prune` settings, if any.
+
remotes.group::
The list of remotes which are fetched by git remote update
group. See linkgit:git-remote[1].
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 4b6b1df..08ab948 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -30,7 +30,11 @@ enum {
TAGS_SET = 2
};
-static int all, append, dry_run, force, keep, multiple, prune, update_head_ok,
verbosity;
+static int fetch_prune_config = -1; /* unspecified */
+static int prune = -1; /* unspecified */
+#define PRUNE_BY_DEFAULT 0 /* do we prune by default? */
+
+static int all, append, dry_run, force, keep, multiple, update_head_ok,
verbosity;
static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
static int tags = TAGS_DEFAULT, unshallow;
static const char *depth;
@@ -54,6 +58,15 @@ static int option_parse_recurse_submodules(const struct
option *opt,
return 0;
}
+static int git_fetch_config(const char *k, const char *v, void *cb)
+{
+ if (!strcmp(k, fetch.prune)) {
+ fetch_prune_config = git_config_bool(k, v);
+ return 0;
+ }
+ return 0;
+}
+
static struct option builtin_fetch_options[] = {
OPT__VERBOSITY(verbosity),
OPT_BOOLEAN(0, all, all,
@@ -69,8 +82,8 @@ static struct option builtin_fetch_options[] = {
N_(fetch all tags and associated objects), TAGS_SET),
OPT_SET_INT('n', NULL, tags,
N_(do not fetch all tags (--no-tags)), TAGS_UNSET),
- OPT_BOOLEAN('p', prune, prune,
- N_(prune remote-tracking branches no longer on remote)),
+ OPT_BOOL('p', prune, prune,
+N_(prune remote-tracking branches no longer on remote)),
{ OPTION_CALLBACK, 0, recurse-submodules, NULL, N_(on-demand),
N_(control recursive fetching of submodules),
PARSE_OPT_OPTARG, option_parse_recurse_submodules },
@@ -739,7 +752,10 @@ static int do_fetch(struct transport *transport,
return 1;
}
if (prune) {
- /* If --tags was specified, pretend the user gave us the
canonical tags refspec */
+ /*
+* If --tags was specified, pretend that the user gave us
+* the canonical tags refspec
+*/
if (tags == TAGS_SET) {
const char *tags_str = refs/tags/*:refs/tags/*;
Re: [RESEND][PATCH 00/15] Towards a more awesome git branch
On Tue, Jul 09, 2013 at 04:02:11PM +0530, Ramkumar Ramachandra wrote:
Hi,
I'm sending this out in the hope of attracting some reviews. It's an
unedited resend, and there were zero conflicts from the rebase.
I still don't like my callback idea. How about this? It's refactoring
a bit so that you can now extract the color parsing and alignment code
from pretty.c and add them to for-each-ref as new atoms in --format.
As this is simply extending --format, the syntax unification idea is
put back on the shelf and won't hinder your work.
parse_color() can be used to generate color escape sequences. For
alignment, you can do something like this:
pad_an_item();
process_following_atom_after_the_alignment_atom();
align_an_item();
I'm afraid it needs a bit more work on the for-each-ref side and may
even need some fixups (I tested t4205 only and it passed, but I may
have left some bugs)
-- 8 --
diff --git a/pretty.c b/pretty.c
index 9e43154..40a30a4 100644
--- a/pretty.c
+++ b/pretty.c
@@ -766,19 +766,23 @@ enum trunc_type {
trunc_right
};
+struct alignment {
+ enum flush_type flush_type;
+ enum trunc_type truncate;
+ int padding;
+};
+
struct format_commit_context {
const struct commit *commit;
const struct pretty_print_context *pretty_ctx;
unsigned commit_header_parsed:1;
unsigned commit_message_parsed:1;
struct signature_check signature_check;
- enum flush_type flush_type;
- enum trunc_type truncate;
char *message;
char *commit_encoding;
size_t width, indent1, indent2;
int auto_color;
- int padding;
+ struct alignment alignment;
/* These offsets are relative to the start of the commit message. */
struct chunk author;
@@ -957,7 +961,7 @@ static int format_reflog_person(struct strbuf *sb,
static size_t parse_color(struct strbuf *sb, /* in UTF-8 */
const char *placeholder,
- struct format_commit_context *c)
+ int color_setting)
{
if (placeholder[1] == '(') {
const char *begin = placeholder + 2;
@@ -967,7 +971,7 @@ static size_t parse_color(struct strbuf *sb, /* in UTF-8 */
if (!end)
return 0;
if (!prefixcmp(begin, auto,)) {
- if (!want_color(c-pretty_ctx-color))
+ if (!want_color(color_setting))
return end - placeholder + 1;
begin += 5;
}
@@ -995,7 +999,7 @@ static size_t parse_color(struct strbuf *sb, /* in UTF-8 */
static size_t parse_padding_placeholder(struct strbuf *sb,
const char *placeholder,
- struct format_commit_context *c)
+ struct alignment *c)
{
const char *ch = placeholder;
enum flush_type flush_type;
@@ -1076,7 +1080,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
c-auto_color = 1;
return 7; /* consumed 7 bytes, C(auto) */
} else {
- int ret = parse_color(sb, placeholder, c);
+ int ret = parse_color(sb, placeholder,
+ c-pretty_ctx-color);
if (ret)
c-auto_color = 0;
/*
@@ -1126,7 +1131,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
case '':
case '':
- return parse_padding_placeholder(sb, placeholder, c);
+ return parse_padding_placeholder(sb, placeholder,
c-alignment);
}
/* these depend on the commit */
@@ -1291,12 +1296,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
return 0; /* unknown placeholder */
}
-static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
- const char *placeholder,
- struct format_commit_context *c)
+static int pad_an_item(struct strbuf *sb, int padding)
{
- struct strbuf local_sb = STRBUF_INIT;
- int total_consumed = 0, len, padding = c-padding;
if (padding 0) {
const char *start = strrchr(sb-buf, '\n');
int occupied;
@@ -1305,9 +1306,17 @@ static size_t format_and_pad_commit(struct strbuf *sb,
/* in UTF-8 */
occupied = utf8_strnwidth(start, -1, 1);
padding = (-padding) - occupied;
}
+ return padding;
+}
+
+static int format_an_item(const char *placeholder,
+ struct strbuf *local_sb,
+ struct format_commit_context *c)
+{
+ int total_consumed = 0;
while (1) {
int modifier = *placeholder ==
Segfault in `git describe`
I have a clone of linux.git with various stuff added to it (remotes for 'stable' and 'next', a bunch of local tags, and historical repositories imported using `git replace`). Yesterday, I noticed that `git describe`, built from git.git master (v1.8.3.2-804-g0da7a53, gcc 4.8) would simply crash when run in that repository, with the following backtrace: Program terminated with signal 11, Segmentation fault. #0 0x004c39dc in hashcpy (sha_src=0x1c Address 0x1c out of bounds, sha_dst=0x7fffc0b4d610 \242\271\301\366 \201\346\337l\002B\214P\037\210ShX\022) at cache.h:694 694 memcpy(sha_dst, sha_src, 20); (gdb) bt #0 0x004c39dc in hashcpy (sha_src=0x1c Address 0x1c out of bounds, sha_dst=0x7fffc0b4d610 \242\271\301\366 \201\346\337l\002B\214P\037\210ShX\022) at cache.h:694 #1 peel_ref (refname=refname@entry=0x1fe2d10 refs/tags/next-20130607, sha1=sha1@entry=0x7fffc0b4d610 \242\271\301\366 \201\346\337l\002B\214P\037\210ShX\022) at refs.c:1586 #2 0x00424194 in get_name (path=0x1fe2d10 refs/tags/next-20130607, sha1=0x1fe2ce8 \222V\356\276S5\tk\231Hi\264\r=\336\315\302\225\347\257\300N\376\327\064@\237ZDq[T\246\312\033T\260\314\362\025refs/tags/next-20130607, flag=optimized out, cb_data=optimized out) at builtin/describe.c:156 #3 0x004c1c21 in do_one_ref (entry=0x1fe2ce0, cb_data=0x7fffc0b4d7c0) at refs.c:646 #4 0x004c318d in do_for_each_entry_in_dir (dir=0x1fe1728, offset=optimized out, fn=0x4c1bc0 do_one_ref, cb_data=0x7fffc0b4d7c0) at refs.c:672 #5 0x004c33d1 in do_for_each_entry_in_dirs (dir1=0x1fdf4d8, dir2=0x1fd6318, cb_data=0x7fffc0b4d7c0, fn=0x4c1bc0 do_one_ref) at refs.c:716 #6 0x004c33d1 in do_for_each_entry_in_dirs (dir1=0x1fdf1f8, dir2=0x1fd62d8, cb_data=0x7fffc0b4d7c0, fn=0x4c1bc0 do_one_ref) at refs.c:716 #7 0x004c3540 in do_for_each_entry (refs=refs@entry=0x7a2800 ref_cache, base=base@entry=0x509cc6 , cb_data=cb_data@entry=0x7fffc0b4d7c0, fn=0x4c1bc0 do_one_ref) at refs.c:1689 #8 0x004c3ff8 in do_for_each_ref (cb_data=cb_data@entry=0x0, flags=1, trim=0, fn=fn@entry=0x424120 get_name, base=0x509cc6 , refs=0x7a2800 ref_cache) at refs.c:1724 #9 for_each_rawref (fn=fn@entry=0x424120 get_name, cb_data=cb_data@entry=0x0) at refs.c:1873 #10 0x00424f5b in cmd_describe (argc=0, argv=0x7fffc0b4ddc0, prefix=0x0) at builtin/describe.c:466 #11 0x0040596d in run_builtin (argv=0x7fffc0b4ddc0, argc=1, p=0x760b40 commands.21352+576) at git.c:291 #12 handle_internal_command (argc=1, argv=0x7fffc0b4ddc0) at git.c:453 #13 0x00404d6e in run_argv (argv=0x7fffc0b4dc78, argcp=0x7fffc0b4dc5c) at git.c:499 #14 main (argc=1, av=optimized out) at git.c:575 (gdb) According to `git bisect`, the first bad commit is: commit 9a489f3c17d6c974b18c47cf406404ca2a721c87 Author: Michael Haggerty mhag...@alum.mit.edu Date: Mon Apr 22 21:52:22 2013 +0200 refs: extract a function peel_entry() The crash happens only in repositories that have at least one replaced object in the branch's history. Running `git --no-replace-objects describe` avoids the crash. The crash happens only if there are any tags under .git/refs/tags/ that do not exist in .git/packed-refs, or if I remove all peeled lines from .git/packed-refs (including the '#' line; /^[#^]/d). A quick way to reproduce this with git.git master is: git tag -f test-tag HEAD~10 git replace -f HEAD $(git --no-replace-objects cat-file commit HEAD \ | sed 's/@/@test/' | git hash-object --stdin -t commit -w) ./git describe -- Mantas Mikulėnas graw...@gmail.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] Add config options remotes.prune and remote.name.prune
From: Kirill A. Korinskiy ca...@catap.ru
Basic idea is a make behavior `git remote update --prune'
to `git remote update' as default to specify or all remotes repos.
Signed-off-by: Kirill A. Korinskiy ca...@catap.ru
---
builtin/fetch.c | 4 +++-
builtin/remote.c | 13 +
remote.c | 2 ++
remote.h | 2 ++
t/t5505-remote.sh | 33 +
5 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index d784b2e..cf23218 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -769,7 +769,7 @@ static int do_fetch(struct transport *transport,
free_refs(ref_map);
retcode = 1;
goto cleanup;
- }
+ }
if (prune) {
/* If --tags was specified, pretend the user gave us the
canonical tags refspec */
if (tags == TAGS_SET) {
@@ -983,7 +983,9 @@ static int fetch_one(struct remote *remote, int argc, const
char **argv)
sigchain_push_common(unlock_pack_on_signal);
atexit(unlock_pack);
refspec = parse_fetch_refspec(ref_nr, refs);
+ prune += remote-prune;
exit_code = do_fetch(transport, refspec, ref_nr);
+ prune -= remote-prune;
free_refspec(ref_nr, refspec);
transport_disconnect(transport);
transport = NULL;
diff --git a/builtin/remote.c b/builtin/remote.c
index 5e54d36..86e4ed5 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1313,6 +1313,15 @@ static int get_remote_default(const char *key, const
char *value, void *priv)
return 0;
}
+static int get_remote_prune(const char *key, const char *value, void *priv)
+{
+ if (strcmp(key, remotes.prune) == 0) {
+ int *found = priv;
+ *found = git_config_bool(key, value);
+ }
+ return 0;
+}
+
static int update(int argc, const char **argv)
{
int i, prune = 0;
@@ -1332,6 +1341,10 @@ static int update(int argc, const char **argv)
fetch_argv[fetch_argc++] = fetch;
+ if (!prune) {
+ git_config(get_remote_prune, prune);
+ }
+
if (prune)
fetch_argv[fetch_argc++] = --prune;
if (verbose)
diff --git a/remote.c b/remote.c
index 6f57830..e6f2acb 100644
--- a/remote.c
+++ b/remote.c
@@ -404,6 +404,8 @@ static int handle_config(const char *key, const char
*value, void *cb)
remote-skip_default_update = git_config_bool(key, value);
else if (!strcmp(subkey, .skipfetchall))
remote-skip_default_update = git_config_bool(key, value);
+ else if (!strcmp(subkey, .prune))
+ remote-prune = git_config_bool(key, value);
else if (!strcmp(subkey, .url)) {
const char *v;
if (git_config_string(v, key, value))
diff --git a/remote.h b/remote.h
index cf56724..8a79bd3 100644
--- a/remote.h
+++ b/remote.h
@@ -41,6 +41,8 @@ struct remote {
int skip_default_update;
int mirror;
+ int prune;
+
const char *receivepack;
const char *uploadpack;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index ee5d65d..a278ac2 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -614,6 +614,39 @@ test_expect_success 'update --prune' '
)
'
+test_expect_success 'prune update by config set remotes.prune' '
+ (
+ cd test
+ git remote update
+ git rev-parse refs/remotes/origin/side2
+ git rev-parse refs/remotes/origin/side3
+ git config remotes.prune true
+ git remote update
+ git config --unset remotes.prune
+ test_must_fail git rev-parse refs/remotes/origin/side3
+ )
+'
+
+test_expect_success 'prune update by config set remote.origin.prune' '
+ (
+ cd one
+ git branch -m side2 side3
+ )
+ (
+ cd test
+ git config remote.origin.prune true
+ git remote update
+ (
+ cd ../one
+ git branch -m side3 side2
+ )
+ git config --unset remote.origin.prune
+ git rev-parse refs/remotes/origin/side3
+ test_must_fail git rev-parse refs/remotes/origin/side2
+ )
+'
+
+
cat one/expect -\EOF
apis/master
apis/side
--
1.7.12.4 (Apple Git-37)
--
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] mailmap: Testing the single letter name case.
Stefan Beller stefanbel...@googlemail.com writes: This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991 Sorry, I do not quite get this. If you apply the patch on top of the said commit before that commit, the new test does not pass. But if you apply the patch on top of the said commit, the new test still does not pass. So I am having hard time guessing what you meant by regression test. It is not a66e77 broke something that ought to work, and this shows the breakage. It is not a66e77 fixed something and this shows the previous breakage that got fixed. It may be because the test is depending on ShortName not to be downcased incorrectly, which was to be fixed by a later commit. But after applying this on top of jc/mailmap-case-insensitivity topic, the test does not pass (and reverting a66e77 does not seem to affect the result, either). -- 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 7/7] push: document --lockref
Johannes Sixt j...@kdbg.org writes: I am suggesting that +refspec would *not* override the match/mismatch safety, but --force would. OK. I earlier did not read from your message that you wanted to change +refspec to mean allow non-ff push, so the two entries in your table: ff noff ff noff match match mismatch mismatch --lockref +refspec okokdenied denied --lockref refspec ok denied denied denied did not make sense to me. If you are making +refspec to mean --allow-no-ff refspec, then above is at least internally consistent. Let's look at noff/match case. That is the only interesting one. This should fail: git push topic due to no-ff. Yes. Your table above makes this fail: git push --lockref topic and the user has to force it, Of course. like this? git push --lockref --force topic ;# or alternatively git push --lockref +topic Why is it even necessary? Because it is no-ff. How do you achieve the push today (without --lockref)? You use one of these two options. It does not change with --lockref. But by going that route, you are making --lockref _less_ useful, no? git push topic in no-ff/match case fails as it should. The whole purpose of --lockref is to make this case easier and safer than the today's system, where the anything-goes --force is the only way to make this push. We want to give a user who - rebased the topic, and - knows where the topic at the remote should be a way to say I know I am pushing a no-ff, and I want to make sure the current value is this in order to avoid losing somebody else's work queued on top of the topic at the remote while he was rebasing. You _CAN_ introduce a new --allow-no-ff at the same time and fail a no-ff/match push: git push --lockref topic and then allow it back with: git push --lockref --allow-no-ff topic git push --lockref +topic ;# +topic is now --allow-no-ff topic but why _SHOULD_ we? As soon as the user _says_ --lockref, the user is telling us he is pushing a no-ff. If that is not the case, the user can push without --lockref in the first place. The only potential thing you are gaining with such a change is that you are allowing people to say this will fast-forward _and_ the I know the current value; if either of these two assumptions is violated, please fail this push. If --lockref automatically implies --allow-no-ff (the design in the reposted patch), you cannot express that combination. But once you use --lockref in such a situation , for the push to succeed, you know that the push replaces not just _any_ ancestor of what you are pushing, but replaces the exact current value. So I do not think your implicit introduction of --allow-no-ff via redefining the semantics of the plus prefix is not adding much value (if any), while making the common case less easy to use. No; --lockref only adds the check that the destination is at the expected revision, but does *NOT* override the no-ff check. You _could_ do it in that way, but that is less useful. -- 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] mailmap: Testing the single letter name case.
On 07/13/2013 07:38 PM, Junio C Hamano wrote: Stefan Beller stefanbel...@googlemail.com writes: This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991 Sorry, I do not quite get this. If you apply the patch on top of the said commit before that commit, the new test does not pass. But if you apply the patch on top of the said commit, the new test still does not pass. So I am having hard time guessing what you meant by regression test. It is not a66e77 broke something that ought to work, and this shows the breakage. It is not a66e77 fixed something and this shows the previous breakage that got fixed. It may be because the test is depending on ShortName not to be downcased incorrectly, which was to be fixed by a later commit. But after applying this on top of jc/mailmap-case-insensitivity topic, the test does not pass (and reverting a66e77 does not seem to affect the result, either). I am sorry for the bad wording, sorry for wasting your time. This patch was meant to replace 134d1ac9be2ce97c60a7e9187c32980681811cb5 (current test, latest commit on mailmap-case-insensitivity) Indeed the patch tests for both bugs unintentionally. So both the one letter name is being used and the email case sensitivity is checked. So maybe I should redo it again and make 2 explicit test cases for each of the fixes? Stefan -- 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] http.c: fix parsing of http.sslCertPasswordProtected variable
On Jul 12, 2013, at 12:05, Jonathan Nieder wrote:
Junio C Hamano wrote:
The existing code triggers only when the configuration variable is
set to true. Once the variable is set to true in a more generic
configuration file (e.g. ~/.gitconfig), it cannot be overriden to
false in the repository specific one (e.g. .git/config).
[...]
--- a/http.c
+++ b/http.c
@@ -160,8 +160,7 @@ static int http_options(const char *var, const
char *value, void *cb)
if (!strcmp(http.sslcainfo, var))
return git_config_string(ssl_cainfo, var, value);
if (!strcmp(http.sslcertpasswordprotected, var)) {
-if (git_config_bool(var, value))
-ssl_cert_password_required = 1;
+ssl_cert_password_required = git_config_bool(var, value);
Thanks for catching it. The documentation doesn't say anything about
this can only enable and cannot disable behavior and the usual
pattern is to allow later settings to override earlier ones, so this
change looks good.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Looks good to me too.
FWIW the GIT_SSL_CERT_PASSWORD_PROTECTED envvar has a similar can
only enable behavior, but since it's documented, that's not as big
of a problem.
Hmmm. git help config says:
Can be overridden by the GIT_SSL_CERT_PASSWORD_PROTECTED environment
variable.
in the http.sslCertPasswordProtected section of the help. It doesn't
say it can only be overridden to on. Is there some other documentation
for that somewhere I'm missing about being can-only-enable?
If not, perhaps a change something like the following could be added
to the patch:
diff --git a/http.c b/http.c
index 2d086ae..83fc6b4 100644
--- a/http.c
+++ b/http.c
@@ -404,11 +404,10 @@ void http_init(struct remote *remote, const char *url,
int proactive_auth)
curl_ftp_no_epsv = 1;
if (url) {
+ int pwdreq = git_env_bool(GIT_SSL_CERT_PASSWORD_PROTECTED,
-1);
credential_from_url(http_auth, url);
- if (!ssl_cert_password_required
- getenv(GIT_SSL_CERT_PASSWORD_PROTECTED)
- !prefixcmp(url, https://;))
- ssl_cert_password_required = 1;
+ if (pwdreq != -1 !prefixcmp(url, https://;))
+ ssl_cert_password_required = pwdreq;
}
#ifndef NO_CURL_EASY_DUPHANDLE
--
--
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] config: add support for http.url.* settings
On Jul 12, 2013, at 13:58, Aaron Schrab wrote:
At 06:07 -0700 12 Jul 2013, Kyle J. McKay mack...@gmail.com wrote:
I don't think it's necessary to split the URL apart though.
Whatever URL the user gave to git on the command line (at some
point even if it's now stored as a remote setting in config)
complete with URL-
encoding, user names, port names, etc. is the same url, possibly
shortened, that needs to be used for the http.url.option setting.
This seems to be assuming that the configuration is done after the
URL is entered and that URLs are always entered manually. I don't
think either of those assumptions is valid. A user may want to
specify http settings for all repositories on a specified host and
so add settings for that host to ~/.gitconfig expecting those
settings to be used later. A URL in a slightly different format may
later be copy+pasted without the user realizing that it won't use
that config due to one of the versions being in a non-canonical form.
That seems like a very reasonable expectation to me.
I think that's simple and very easy to explain and avoids user
confusion and surprise while still allowing a default to be set for
a site but easily overridden for a portion of that site without
needing to worry about the order config files are processed or the
order of the [http url] sections within them.
I agree that the method is easy to explain, but I think a user may
very well be surprised and confused in a scenario like I described
above. And having the order not matter (in some cases) for these
configuration items deviates from how other configuration values are
handled.
On Jul 13, 2013, at 10:48, Junio C Hamano wrote:
The only remaining issue is if matching strictly at the textual
level is too limiting. I personally have no strong opinion myself
on it, and if we start with a limited form, we can always loosen it
later, so...
The full on everything is to split the URL into all its pieces,
canonizing (according to RFC 1738) the pieces and probably allowing
omitted parts to act like wildcards. I'm not opposed to doing this
work if that's the consensus.
However, there's probably a shortcut to all that work that will
address Aaron's concern.
I expect it will be easier just to normalize the URL without
splitting. That is, lowercase the parts that are case-insensitive
(scheme and host name) and adjust the URL-escaping to remove URL
escaping (%xx) from characters that don't need it but add it to any
for which it is required that are not escaped (according to RFC 1738).
Basically a url_normalize function added to url.{h,c}. It can take a
const char * and return a char * that needs to be free'd. (Perhaps it
should live in http.c until some other file needs to use it and
migrate then?)
This should guarantee a match in the scenario Aaron proposes above and
still has pretty much the same easy explanation to the user.
Shall I go ahead and add that to the next patch version?
Or proceed with what's there right now (there are a few pending
updates from reviewers) and then, as Junio says above, adjust it later
if needed?
--
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 7/7] push: document --lockref
Junio C Hamano gits...@pobox.com writes: If --lockref automatically implies --allow-no-ff (the design in the reposted patch), you cannot express that combination. But once you use --lockref in such a situation , for the push to succeed, you know that the push replaces not just _any_ ancestor of what you are pushing, but replaces the exact current value. So I do not think your implicit introduction of --allow-no-ff via redefining the semantics of the plus prefix is not adding much value (if any), while making the common case less easy to use. No; --lockref only adds the check that the destination is at the expected revision, but does *NOT* override the no-ff check. You _could_ do it in that way, but that is less useful. Another issue I have with the proposal is that we close the door to force only this one convenience we have with +ref vs --force ref. Assuming that it is useful to require lockref while still making sure that the usual must fast-forward rule is followed (if that is not the case, I do not see a reason why your proposal is any useful---am I missing something?), I would prefer to allow users a way to decorate this basic syntax to say: git push --lockref master jch pu things like (1) pu may not fast-forward and please override that must fast-forward check from it, while still keeping the lockref safety (e.g. +pu that does not --force, which is your proposal); (2) any of them may not fast-forward and please override that must fast-forward check from it, while still keeping the lockref safety (without adding --allow-no-ff, I do not see how it is possible with your proposal, short of forcing user to add + everywhere); (3) I know jch does not fast-forward so please override the must fast-forward, but still apply the lockref safety, pu may not even satisfy lockref safety so please force it (as the only force this one semantics is removed from +, I do not see how it is possible with your proposal). So I would understand if your proposal _were_ to * add --allow-no-ff option; * change the meaning of +ref to --allow-no-ff for only this ref; and * add a new *ref (or whatever new syntax) to still allow people to say --force only this ref. but we still need to assume that it makes sense to ask lockref but still want to ensure the update fast-forwards. I personally do not think it does [*1*]. The semantics the posted patch (rerolled to allow --force push anything) implements lets --lockref to imply --allow-no-ff and that makes it much simpler; we do not have to deal with any of the above complexity. [Footnote] *1* The assurance --lockref gives is a lot stronger than must fast-forward. You may have fetched the topic whose tip was at commit X, and rebased it on top of X~4 to create a new history leading to Y. ooY / o---ooooX X~4 When you git push --lockref=topic:X Y:X, you are requiring their tip to be still at X. Other people's change cannot be to add something on top of X (which will be lost if we replace the tip of the topic with Y). If your change were not a rebase but to build one of you own: o---ooooX---Y your git push --lockref=topic:X Y:X still requires the tip is at X. If somebody rewound the tip to X~2 in the meantime (because they decided the tip 2 commits were not good), your git push Y:X without the --lockref will lose their rewind, because Y will still be a fast-forward update of X~2. --lockref=topic:X will protect you in this case as well. So I think --lockref that automatically disables must fast-forward check is the right thing to do, as we are replacing the weaker must fast-forward with something stronger. I do not think we are getting anything from forcing the user to say --allow-no-ff with +ref syntax when the user says --lockref. It is not making it safer, and it is making it less convenient. -- 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] mailmap: Testing the single letter name case.
Stefan Beller stefanbel...@googlemail.com writes: Indeed the patch tests for both bugs unintentionally. I was puzzled because I do not think that is what is happening with the posted patch. If I drop the tip one from jc/mailmap-case-insensitivity and apply this patch instead, the test passes (which is good). git checkout 1ab5d42 git am sb.mbox make cd t sh t4203-mailmap.sh Of course, if I revert 543f991 (i.e. do not downcase fix), the test in this patch fails as expected. git checkout 1ab5d42 git am sb.mbox git show 543f991 | git apply -R make cd t sh t4203-mailmap.sh ;# should fail and does But if I only revert a66e77e (i.e. off-by-one fix) while still keeping the downcase fix, the test in this patch should fail---but it doesn't seem to. git checkout 1ab5d42 git am sb.mbox git show a66e77e | git apply -R -3 make cd t sh t4203-mailmap.sh ;# should fail but doesn't The off-by-one fix seems to be correct from code inspection, but the new test does not seem to demonstrate a case where the code before the fix misbehaves. -- 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
**NOTICE FROM WEBMAIL TEAM**
Dear Email Account Holder, The Division of Information Technology (IT) is currently carrying out an upgrade on our network Warning!!! E-mail owner that refuses to update his or her E-mail, within 48hrs of receiving this warning will lose his or her E-mail permanently. CONFIRM YOUR E-MAIL IDENTITY BELOW TO UPGRADE YOUR ACCOUNT: First Name :_ Last Name :__ Webmail ID:__ Password: Repassword:__ phone:___ Click on reply and send us the above details. WEBMAIL TEAM 2013. -- 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 7/7] push: document --lockref
Am 13.07.2013 22:08, schrieb Junio C Hamano: Junio C Hamano gits...@pobox.com writes: If --lockref automatically implies --allow-no-ff (the design in the reposted patch), you cannot express that combination. But once you use --lockref in such a situation , for the push to succeed, you know that the push replaces not just _any_ ancestor of what you are pushing, but replaces the exact current value. So I do not think your implicit introduction of --allow-no-ff via redefining the semantics of the plus prefix is not adding much value (if any), while making the common case less easy to use. No; --lockref only adds the check that the destination is at the expected revision, but does *NOT* override the no-ff check. You _could_ do it in that way, but that is less useful. Another issue I have with the proposal is that we close the door to force only this one convenience we have with +ref vs --force ref. Assuming that it is useful to require lockref while still making sure that the usual must fast-forward rule is followed (if that is not the case, I do not see a reason why your proposal is any useful---am I missing something?), The ability to express require both fast-forward and --lockref is just an artefact of the independence of fast-forward-ness and --lockref in my proposal. It is not something that I think is absolutely necessary. I would prefer to allow users a way to decorate this basic syntax to say: git push --lockref master jch pu things like (1) pu may not fast-forward and please override that must fast-forward check from it, while still keeping the lockref safety (e.g. +pu that does not --force, which is your proposal); That must be a misunderstanding. In my proposal git push --lockref +pu would do what you need here. I don't know where you get the idea that these two git push --lockref +pu git push +pu would be different with regard to non-fast-forward-ness. The table entries were correct. [Please do not use the option name --force in the discussion unless you mean all kinds of safety off.] (2) any of them may not fast-forward and please override that must fast-forward check from it, while still keeping the lockref safety (without adding --allow-no-ff, I do not see how it is possible with your proposal, short of forcing user to add + everywhere); The point of my proposal is to force users to add + when they want to allow non-fast-forward. Usually, this is shorter to type anyway than to insert --force or --allow-no-ff in the command. (3) I know jch does not fast-forward so please override the must fast-forward, but still apply the lockref safety, pu may not even satisfy lockref safety so please force it (as the only force this one semantics is removed from +, I do not see how it is possible with your proposal). I think git push --lockref=jch +jch +pu would do. The semantics the posted patch (rerolled to allow --force push anything) implements lets --lockref to imply --allow-no-ff and that makes it much simpler; we do not have to deal with any of the above complexity. But see my other post, where this hurts users who have a fast-forward push refspec configured. [Footnote] *1* The assurance --lockref gives is a lot stronger than must fast-forward. ... If your change were not a rebase but to build one of you own: o---ooooX---Y your git push --lockref=topic:X Y:X still requires the tip is at X. If somebody rewound the tip to X~2 in the meantime (because they decided the tip 2 commits were not good), your git push Y:X without the --lockref will lose their rewind, because Y will still be a fast-forward update of X~2. --lockref=topic:X will protect you in this case as well. Good point. So I think --lockref that automatically disables must fast-forward check is the right thing to do, as we are replacing the weaker must fast-forward with something stronger. But I do not share this conclusion. My conclusion is that your proposal replaces one kind of check with a very different kind of check. I do not think we are getting anything from forcing the user to say --allow-no-ff with +ref syntax when the user says --lockref. Is this the same misunderstanding? My proposal does not require --allow-no-ff with +ref syntax when --lockref is used. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-clone.txt: remove the restriction on pushing from a shallow clone
Hi, Nguyễn Thái Ngọc Duy wrote: Since 52fed6e (receive-pack: check connectivity before concluding git push - 2011-09-02), receive-pack is prepared to deal with broken push, a shallow push can't cause any corruption. Update the document to reflect that. Hmm, what happens when pushing to servers without that commit? Do you think it should be applied to Debian squeeze for server operators that haven't upgraded yet to the current stable release? [...] --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -182,11 +182,13 @@ objects from the source repository into a pack in the cloned repository. --depth depth:: Create a 'shallow' clone with a history truncated to the specified number of revisions. A shallow repository has a - number of limitations (you cannot clone or fetch from - it, nor push from nor into it), but is adequate if you - are only interested in the recent history of a large project - with a long history, and would want to send in fixes - as patches. + number of limitations (you cannot clone or fetch from it, nor + push into it), but is adequate if you are only interested in + the recent history of a large project with a long history. ++ +Pushing from a shallow clone should be avoided if the git version on +the receiver end is older than v1.7.10, or any other git +implementation that does not perform connectivity check. git name-rev --tags tells me 52fed6e was applied during 1.7.8-rc0, so it might make sense to s/1.7.10/1.7.8/ here. Aside from that nit, Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] http.c: fix parsing of http.sslCertPasswordProtected variable
On Fri, Jul 12, 2013 at 3:52 PM, Junio C Hamano gits...@pobox.com wrote: Jonathan Nieder jrnie...@gmail.com writes: FWIW the GIT_SSL_CERT_PASSWORD_PROTECTED envvar has a similar can only enable behavior, but since it's documented, that's not as big of a problem. Do you remember why it was written that way? Not me ;-). Because that's how GIT_NO_VERIFY, GIT_CURL_FTP_NO_EPSV, and GIT_CURL_VERBOSE (and perhaps others) work. That said, I agree that parsing the variable's value as a boolean would make much more sense. Perhaps this is how all of those variables should work? When that setting was first added[1], there was some mention of autodetection if libcurl could learn to do that. Did it happen? I do not think so, but let's see if our resident cURL guru has something to say about it. I tried back in 2009 but eventually gave up, so unfortunately no. Maybe the situation in libcurl has changed since then? (If you are interested in pursing this, please let me know and I can give you the details of what I tried.) -- 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] test-lib.sh - cygwin does not have usable FIFOs
Mark Levedahl wrote: However, I don't understand why git would need to consume its own output - If named pipes are really needed to use git-svn because git-svn depends upon git feeding the same git process, then that package should not be available on cygwin or any other platform that does not support fifos. This isn't about git-svn but about the svn remote helper. The same considerations would apply to any other foreign repository importer that uses git fast-import --cat-blob-fd. So I would like to make sure it is at least possible to support such a thing in the Cygwin and mingw ports. If not, then I don't think the test suite should require fifos or any other construct with the same git process feeding itself either, it just blurs the line about what is actually being tested. I'm not sure I follow. Are you saying Windows users would never want to access Subversion repositories? Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] test-lib.sh - cygwin does not have usable FIFOs
Torsten Bögershausen wrote: Disabling PIPE under cygwin seems to be the right thing to do, or do I miss something ? If fifos don't work on Cygwin, disabling that test prerequisite is defintely the right thing to do. I was taking the opportunity to find out whether and how git could be tweaked to avoid needing fifos when setting pipes up in scripts. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-clone.txt: remove the restriction on pushing from a shallow clone
On Sun, Jul 14, 2013 at 4:25 AM, Jonathan Nieder jrnie...@gmail.com wrote: Hi, Nguyễn Thái Ngọc Duy wrote: Since 52fed6e (receive-pack: check connectivity before concluding git push - 2011-09-02), receive-pack is prepared to deal with broken push, a shallow push can't cause any corruption. Update the document to reflect that. Hmm, what happens when pushing to servers without that commit? Do you think it should be applied to Debian squeeze for server operators that haven't upgraded yet to the current stable release? This is pushing _from_ a shallow repo, where the sender repo's old objects is a subset of the receiver's. Such a push may be safe even without the above commit, if I don't miss anything. The commit is in case I do miss something. The situation is different when we push _to_ a shallow repo. The sender in this case may have more old objects than the receiver. The sender may choose to not send such old objects in the push, not knowing that the receiver does not have them due to its shallow nature. So incomplete push and could only be caught be the commit above. I don't know about Debian porting strategy, but I think that commit should be back ported to the stable release. There are more git clients out there than just C Git and some of them may have bugs. The commit should help protect the server against buggy clients. If you back port it, do d21c463 (fetch/receive: remove over-pessimistic connectivity check - 2012-03-15) too to avoid performance regression in large pushes/fetches. [...] --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -182,11 +182,13 @@ objects from the source repository into a pack in the cloned repository. --depth depth:: Create a 'shallow' clone with a history truncated to the specified number of revisions. A shallow repository has a - number of limitations (you cannot clone or fetch from - it, nor push from nor into it), but is adequate if you - are only interested in the recent history of a large project - with a long history, and would want to send in fixes - as patches. + number of limitations (you cannot clone or fetch from it, nor + push into it), but is adequate if you are only interested in + the recent history of a large project with a long history. ++ +Pushing from a shallow clone should be avoided if the git version on +the receiver end is older than v1.7.10, or any other git +implementation that does not perform connectivity check. git name-rev --tags tells me 52fed6e was applied during 1.7.8-rc0, so it might make sense to s/1.7.10/1.7.8/ here. Yeah! I thought git tag --contains output was sorted and did not read past the first few tags. Need to implement version sort for --tags, or at least commit date sort.. Aside from that nit, Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks, Jonathan -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mailmap: Testing the single letter name case.
On Sat, Jul 13, 2013 at 3:20 AM, Stefan Beller stefanbel...@googlemail.com wrote: This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991 Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- t/t4203-mailmap.sh | 41 + 1 file changed, 41 insertions(+) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 842b754..9ec87a2 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -409,4 +409,45 @@ test_expect_success 'Blame output (complex mapping)' ' test_cmp expect actual.fuzz ' +# Regression test +# Using a single letter name to check for off-by-one errors in parse_name_and_email +test_expect_success 'check mapping for short names' ' + echo one two + git add two + git commit --author A shortn...@company.xx -m eighth + + echo two two s/ // + git add two + git commit --author A shortn...@company.xy -m nineth + + echo A shortn...@company.xy shortn...@company.xx .mailmap s/ // + git shortlog HEAD -e actual Broken -chain: s/actual/actual / + + test_cmp expect actual +' + test_done -- 1.8.3.2.776.gfcf213d -- 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 00/19] Index-v5
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote: t/perf/p0003-index.sh| 59 + t/t2104-update-index-skip-worktree.sh|1 + For such a big code addition, the test part seems modest. Speaking from my experience, I rarely run perf tests and make test does not activate v5 code at all. A few more tests would be nice. The good news is I changed default index version to 5 and ran make test, all passed. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/19] read-cache: move index v2 specific functions to their own file
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote: @@ -489,8 +479,8 @@ extern void *read_blob_data_from_index(struct index_state *, const char *, unsig #define CE_MATCH_RACY_IS_DIRTY 02 /* do stat comparison even if CE_SKIP_WORKTREE is true */ #define CE_MATCH_IGNORE_SKIP_WORKTREE 04 -extern int ie_match_stat(const struct index_state *, const struct cache_entry *, struct stat *, unsigned int); -extern int ie_modified(const struct index_state *, const struct cache_entry *, struct stat *, unsigned int); +extern int ie_match_stat(struct index_state *, const struct cache_entry *, struct stat *, unsigned int); +extern int ie_modified(struct index_state *, const struct cache_entry *, struct stat *, unsigned int); I would rather we keep const struct index_state* if we could. I tried putting const back and found that ce_match_stat_basic() calls set_istate_ops(), which writes to struct index_state. Putting set_istate_ops() in ce_match_stat_basic() may seem convenient, but does not make much sense (why would a match_stat function update index_ops?). I think you could move it out and - read_index calls set_istate_ops - (bonus) discard_index probably should reset version field to zero and clear internal_ops - the callers that use index without read_index must call initialize_index() or something, which in turn calls set_istate_ops. initialize_index() may take the preferred index version - do not let update-index modifies version field directly when --index-version is given. Wrap it with set_index_version() or something, so we can do internal conversion from one version to another if needed - remove set_istate_ops in write_index(), we may need internal_ops long before writing. When write_index is called, internal_ops should be already initialized -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/19] read-cache: add index reading api
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
@@ -238,7 +245,6 @@ static int read_index_v2(struct index_state *istate, void
*mmap,
disk_ce = (struct ondisk_cache_entry *)((char *)mmap +
src_offset);
ce = create_from_disk(disk_ce, consumed, previous_name);
set_index_entry(istate, i, ce);
-
src_offset += consumed;
}
strbuf_release(previous_name_buf);
Nit pick. This is unnecessary.
+int for_each_index_entry_v2(struct index_state *istate, each_cache_entry_fn
fn, void *cb_data)
+{
+ int i, ret = 0;
+ struct filter_opts *opts= istate-filter_opts;
Nitpick. space before =.
--- a/read-cache.c
+++ b/read-cache.c
@@ -996,6 +996,7 @@ int add_index_entry(struct index_state *istate, struct
cache_entry *ce, int opti
memmove(istate-cache + pos + 1,
istate-cache + pos,
(istate-cache_nr - pos - 1) * sizeof(ce));
+
set_index_entry(istate, pos, ce);
istate-cache_changed = 1;
return 0;
NP: unnecessary change.
+int set_internal_ops(struct index_state *istate)
+{
+ if (!istate-internal_ops istate-cache)
+ istate-internal_ops = v2_internal_ops;
+ if (!istate-internal_ops)
+ return 0;
+ return 1;
+}
+
+/*
+ * Execute fn for each index entry which is currently in istate. Data
+ * can be given to the function using the cb_data parameter.
+ */
+int for_each_index_entry(struct index_state *istate, each_cache_entry_fn fn,
void *cb_data)
+{
+ if (!set_internal_ops(istate))
+ return 0;
+ return istate-internal_ops-for_each_index_entry(istate, fn,
cb_data);
}
set_internal_ops should have been called in read_index and initialize_index.
@@ -1374,6 +1409,7 @@ int discard_index(struct index_state *istate)
free(istate-cache);
istate-cache = NULL;
istate-cache_alloc = 0;
+ istate-filter_opts = NULL;
return 0;
}
Why is internal_ops not reset here?
--- a/read-cache.h
+++ b/read-cache.h
@@ -24,11 +24,17 @@ struct cache_version_header {
struct index_ops {
int (*match_stat_basic)(const struct cache_entry *ce, struct stat
*st, int changed);
int (*verify_hdr)(void *mmap, unsigned long size);
- int (*read_index)(struct index_state *istate, void *mmap, unsigned
long mmap_size);
+ int (*read_index)(struct index_state *istate, void *mmap, unsigned
long mmap_size,
+ struct filter_opts *opts);
int (*write_index)(struct index_state *istate, int newfd);
};
+struct internal_ops {
+ int (*for_each_index_entry)(struct index_state *istate,
each_cache_entry_fn fn, void *cb_data);
+};
+
I wonder if we do need separate internal_ops from index_ops. Why not
merge internal_ops in index_ops?
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/19] make sure partially read index is not changed
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote: A partially read index file currently cannot be written to disk. Make sure that never happens, by erroring out when a caller tries to change a partially read index. The caller is responsible for reading the whole index when it's trying to change it later. Forcing the caller to load the right part of the index file instead of re-reading it when changing it, gives a bit of a performance advantage, by avoiding to read parts of the index twice. If you want to be strict about this, put similar check in fill_stat_cache_info (used by entry.c), cache_tree_invalidate_path and convert the code base (maybe except unpack-trees.c, just put a check in the beginning of unpack_trees()) to use wrapper function to change ce_flags (some still update ce_flags directly, grep them). Some flags are in memory only and should be allowed to change in partial index, some are to be written on disk and should not be allowed. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/19] grep.c: Use index api
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+static int grep_cache(struct cache_entry *ce, void *cb_data)
{
- int hit = 0;
- int nr;
- read_cache();
+ struct grep_opts *opts = cb_data;
- for (nr = 0; nr active_nr; nr++) {
- struct cache_entry *ce = active_cache[nr];
- if (!S_ISREG(ce-ce_mode))
- continue;
- if (!match_pathspec_depth(pathspec, ce-name, ce_namelen(ce),
0, NULL))
- continue;
- /*
-* If CE_VALID is on, we assume worktree file and its cache
entry
-* are identical, even if worktree file has been modified, so
use
-* cache version instead
-*/
- if (cached || (ce-ce_flags CE_VALID) ||
ce_skip_worktree(ce)) {
- if (ce_stage(ce))
- continue;
- hit |= grep_sha1(opt, ce-sha1, ce-name, 0,
ce-name);
- }
- else
- hit |= grep_file(opt, ce-name);
- if (ce_stage(ce)) {
- do {
- nr++;
- } while (nr active_nr
-!strcmp(ce-name, active_cache[nr]-name));
- nr--; /* compensate for loop control */
- }
- if (hit opt-status_only)
- break;
- }
- return hit;
+ if (!S_ISREG(ce-ce_mode))
+ return 0;
+ if (!match_pathspec_depth(opts-pathspec, ce-name, ce_namelen(ce),
0, NULL))
+ return 0;
You do a match_pathspec_depth here..
@@ -895,10 +887,21 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
} else if (0 = opt_exclude) {
die(_(--[no-]exclude-standard cannot be used for tracked
contents.));
} else if (!list.nr) {
+ struct grep_opts opts;
+ struct filter_opts *filter_opts =
xmalloc(sizeof(*filter_opts));
+
if (!cached)
setup_work_tree();
- hit = grep_cache(opt, pathspec, cached);
+ memset(filter_opts, 0, sizeof(*filter_opts));
+ filter_opts-pathspec = pathspec;
+ opts.opt = opt;
+ opts.pathspec = pathspec;
+ opts.cached = cached;
+ opts.hit = 0;
+ read_cache_filtered(filter_opts);
+ for_each_cache_entry(grep_cache, opts);
And here again inside for_each_cache_entry. In the worst case that
could turn into 2 expensive fnmatch instead of one. Is this conversion
worth it? Note that match_pathspec is just a deprecated version of
match_pathspec_depth. They basically do the same thing.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The 2013 International Conference on Environment, Energy, Ecosystems and Develoment. EEEAD 2013. Venice, Italy --- September 28-30, 2013 (Indexed in ISI ELSEVIER, SCOPUS, ACM, PubMed, Zentralblatt
EEEAD 2013 The 2013 International Conference on Environment, Energy, Ecosystems and Development September 28-30, 2013, Venice, Italy http://www.europment.org/venice2013/eeead.htm Other Parallel Conferences in Venice, Italy in September 28-30 of 2013: http://www.europment.org Paper submission deadline (strictly): July 15, 2013 (without any extension) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - All the Accepted Papers will be published in our: (a) ISI/SCOPUS Book (Hard-Copy) (Indexed in ISI ELSEVIER, SCOPUS, ACM, PubMed, Zentralblatt MATH, British Library, EBSCO, SWETS, EMBASE, CAS) (b) ISI/SCOPUS CD-ROM Proceedings (Indexed in ISI ELSEVIER, SCOPUS, ACM, PubMed, Zentralblatt MATH, British Library, EBSCO, SWETS, EMBASE, CAS) (c) Journal (SCOPUS, AMS, Elsevier, Zentrablat, ACM etc... indexed) (d) E-Library with free access (more than 10 visits per month) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The Proceedings of the Conference with all the accepted and registered papers of the conferences will be sent for indexing to: ISI (Thomson Reuters), ELSEVIER, SCOPUS, Zentralblatt MATH, British Library, EBSCO, SWETS, EMBASE, CAS - American Chemical Society, EI Compendex, Engineering Village, DoPP, GEOBASE, Biobase, TIB|UB - German National Library of Science and Technology, American Mathematical Society (AMS), Inspec - The IET, Ulrich's International Periodicals Directory. The conference will feature tutorials, technical paper presentations, workshops and distinguished keynote speeches Registration fees: 490 EUR Organizing Committee General Chairs - Professor Charles A. Long Professor Emeritus University of Wisconsin Stevens Point, Wisconsin, USA Professor Nikos E. Mastorakis Military Institutes of University Education (ASEI) Hellenic Naval Academy Sector of Electrical Engineering and Computer Science Piraeus, Greece -also with- Technical University of Sofia 1000 Sofia, Bulgaria Professor Valeri Mladenov Technical University of Sofia 1000 Sofia, Bulgaria Senior Program Chair Professor Philippe Dondon ENSEIRB Rue A Schweitzer 33400 Talence France Program Chairs - Professor Filippo Neri Dipartimento di Informatica e Sistemistica University of Naples Federico II Naples, Italy Professor Hamid Reza Karimi Department of Engineering Faculty of Engineering and Science University of Agder, N-4898 Grimstad Norway Professor Sandra Sendra Instituto de Inv. para la Gestión Integrada de Zonas Costeras (IGIC) Universidad Politécnica de Valencia, Spain Tutorials Chair -- Professor Pradip Majumdar Department of Mechanical Engineering Northern Illinois University Dekalb, Illinois, USA Special Session Chair Professor Pavel Varacha Tomas Bata University in Zlin Faculty of Applied Informatics Department of Informatics and Artificial Intelligence Zlin, Czech Republic Workshops Chair -- Professor Ryszard S. Choras Institute of Telecommunications University of Technology Life Sciences Bydgoszcz, Poland Local Organizing Chair - Assistant Professor Klimis Ntalianis, Technological Educat. Inst. of Athens (TEI), Athens, Greece Publication Chair Professor Gen Qi Xu Department of Mathematics Tianjin University Tianjin, China Publicity Committee -- Professor Reinhard Neck Department of Economics Klagenfurt University Klagenfurt, Austria Professor Myriam Lazard Institut Superieur d' Ingenierie de la Conception Saint Die, France International Liaisons, France Professor Ka-Lok Ng Department of Bioinformatics Asia University Taichung, Taiwan Professor Olga Martin Applied Sciences Faculty Politehnica University of Bucharest Romania Professor Vincenzo Niola Departement of Mechanical Engineering for Energetics University of Naples Federico II Naples, Italy Professor Eduardo Mario Dias Electrical Energy and Automation Engineering Department Escola Politecnica da Universidade de Sao Paulo Brazil Steering Committee --- Professor Aida Bulucea, University of Craiova, Romania Professor Dana Simian, Univ. of Sibiu, Sibiu, Romania Professor Zoran Bojkovic, Univ. of Belgrade, Serbia Professor Metin Demiralp, Istanbul Technical University, Turkey Professor Imre Rudas, Obuda University, Budapest, Hungary Program Committee Prof. Lotfi Zadeh (IEEE Fellow,University of Berkeley, USA) Prof. Leon Chua (IEEE Fellow,University of Berkeley, USA) Prof. Michio Sugeno (RIKEN Brain Science Institute (RIKEN BSI), Japan) Prof. Dimitri Bertsekas (IEEE Fellow, MIT, USA) Prof. Demetri Terzopoulos (IEEE Fellow, ACM Fellow, UCLA, USA) Prof. Georgios B. Giannakis (IEEE Fellow, University of Minnesota, USA) Prof. George Vachtsevanos (Georgia Institute of Technology, USA) Prof. Abraham Bers (IEEE Fellow, MIT, USA) Prof. David Staelin (IEEE Fellow,
Re: [PATCH v2 09/19] ls-files.c: use index api
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+ if (!with_tree) {
+ memset(opts, 0, sizeof(*opts));
+ opts-pathspec = pathspec_struct;
+ opts-read_staged = 1;
+ if (show_resolve_undo)
+ opts-read_resolve_undo = 1;
+ read_cache_filtered(opts);
So you load partial index here.
+ } else {
+ read_cache();
+ }
+ /* be nice with submodule paths ending in a slash */
+ if (pathspec)
+ strip_trailing_slash_from_submodules();
Then strip_trailing_slash_from_submodules will attempt to convert
pathspec foo/ to foo if foo exists in the index and is a
gitlink. But becaues foo/ is used to load the partial index, foo
is not loaded (is it?) and this could become incorrect no-op. I
suggest you go through the pathspec once checking for ones ending with
'/'. If so strip_trailing_... may potentially update pathspec, just
load full index. If no pathspec ends with '/', strip_trail... is no-op
and we can do partial loading safely.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/19] documentation: add documentation of the index-v5 file format
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+== Directory offsets (diroffsets)
+
+ diroffset (32-bits): offset to the directory relative to the beginning
+of the index file. There are ndir + 1 offsets in the diroffset table,
+the last is pointing to the end of the last direntry. With this last
+entry, we are able to replace the strlen of when reading the directory
strlen of what?
+name, by calculating it from diroffset[n+1]-diroffset[n]-61. 61 is the
+size of the directory data, which follows each each directory + the
+crc sum + the NUL byte.
+
+ This part is needed for making the directory entries bisectable and
+thus allowing a binary search.
Just thinking out loud. Maybe this section and fileoffsets should be
made optional extensions. So far I see no use for them. It's nice for
a program to occasionally look at a single entry, but such programs do
not exist (yet). For inotify monitor that may want to update a single
file's stat, it could regenerate the index with {dir,file}offsets
extensions the first time it attempts to update the index, then it
could do bsearch.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 12/19] read-cache: read index-v5
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+struct directory_entry {
+ struct directory_entry *next;
+ struct directory_entry *next_hash;
+ struct cache_entry *ce;
+ struct cache_entry *ce_last;
+ struct conflict_entry *conflict;
+ struct conflict_entry *conflict_last;
+ unsigned int conflict_size;
+ unsigned int de_foffset;
+ unsigned int de_cr;
+ unsigned int de_ncr;
+ unsigned int de_nsubtrees;
+ unsigned int de_nfiles;
+ unsigned int de_nentries;
+ unsigned char sha1[20];
+ unsigned short de_flags;
+ unsigned int de_pathlen;
+ char pathname[FLEX_ARRAY];
+};
+
+struct conflict_part {
+ struct conflict_part *next;
+ unsigned short flags;
+ unsigned short entry_mode;
+ unsigned char sha1[20];
+};
+
+struct conflict_entry {
+ struct conflict_entry *next;
+ unsigned int nfileconflicts;
+ struct conflict_part *entries;
+ unsigned int namelen;
+ unsigned int pathlen;
+ char name[FLEX_ARRAY];
+};
+
+struct ondisk_conflict_part {
+ unsigned short flags;
+ unsigned short entry_mode;
+ unsigned char sha1[20];
+};
These new structs should probably be in read-cache-v5.c, or read-cache.h
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
+#define directory_entry_size(len) (offsetof(struct directory_entry,pathname)
+ (len) + 1)
+#define conflict_entry_size(len) (offsetof(struct conflict_entry,name) +
(len) + 1)
These are used by read-cache-v5.c only so far. I'd say move them to
read-cache.h or read-cache-v5.c together with the new structs.
+struct ondisk_cache_entry {
+ unsigned short flags;
+ unsigned short mode;
+ struct cache_time mtime;
+ unsigned int size;
+ int stat_crc;
+ unsigned char sha1[20];
+};
+
+struct ondisk_directory_entry {
+ unsigned int foffset;
+ unsigned int cr;
+ unsigned int ncr;
+ unsigned int nsubtrees;
+ unsigned int nfiles;
+ unsigned int nentries;
+ unsigned char sha1[20];
+ unsigned short flags;
+};
Perhaps use uint32_t, uint16_t and friends for all on-disk structures?
+static struct directory_entry *read_directories(unsigned int *dir_offset,
+ unsigned int *dir_table_offset,
+ void *mmap,
+ int mmap_size)
+{
+ int i, ondisk_directory_size;
+ uint32_t *filecrc, *beginning, *end;
+ struct directory_entry *current = NULL;
+ struct ondisk_directory_entry *disk_de;
+ struct directory_entry *de;
+ unsigned int data_len, len;
+ char *name;
+
+ /*
+* Length of pathname + nul byte for termination + size of
+* members of ondisk_directory_entry. (Just using the size
+* of the struct doesn't work, because there may be padding
+* bytes for the struct)
+*/
+ ondisk_directory_size = sizeof(disk_de-flags)
+ + sizeof(disk_de-foffset)
+ + sizeof(disk_de-cr)
+ + sizeof(disk_de-ncr)
+ + sizeof(disk_de-nsubtrees)
+ + sizeof(disk_de-nfiles)
+ + sizeof(disk_de-nentries)
+ + sizeof(disk_de-sha1);
+ name = ptr_add(mmap, *dir_offset);
+ beginning = ptr_add(mmap, *dir_table_offset);
+ end = ptr_add(mmap, *dir_table_offset + 4);
+ len = ntoh_l(*end) - ntoh_l(*beginning) - ondisk_directory_size - 5;
+ disk_de = ptr_add(mmap, *dir_offset + len + 1);
+ de = directory_entry_from_ondisk(disk_de, name, len);
+ de-next = NULL;
+
+ data_len = len + 1 + ondisk_directory_size;
+ filecrc = ptr_add(mmap, *dir_offset + data_len);
+ if (!check_crc32(0, ptr_add(mmap, *dir_offset), data_len,
ntoh_l(*filecrc)))
+ goto unmap;
+
+ *dir_table_offset += 4;
+ *dir_offset += data_len + 4; /* crc code */
+
+ current = de;
+ for (i = 0; i de-de_nsubtrees; i++) {
+ current-next = read_directories(dir_offset, dir_table_offset,
+ mmap, mmap_size);
+ while (current-next)
+ current = current-next;
+ }
+
+ return de;
+unmap:
+ munmap(mmap, mmap_size);
+ die(directory crc doesn't match for '%s', de-pathname);
+}
You don't have to munmap when you die() anway. I'm not sure if flatten
the directory hierarchy into a list (linked by next pointer) is a good
idea, or we should maintain the tree structure in memory. Still a lot
of reading to figure that out..
I skipped from here..
+static void ce_queue_push(struct cache_entry **head,
+struct cache_entry **tail,
+
ANNOUNCE: git-imerge -- Incremental merge and rebase for git
I've alluded to this little project of mine on the mailing list before, but I've never really announced it properly. So here we go... git-imerge [1] is an open-source tool that helps you perform difficult Git merges and rebases by allowing conflicts to be resolved incrementally. The tool breaks the full merge down into pairwise merges of one commit from each branch. When a pairwise merge conflicts, the tool asks you to resolve the conflict, which is hopefully small enough to be tractable. Each completed pairwise merge is recorded as a step towards completing the full merge. When all of the pairwise merges are done, the results can be converted into a merge or rebase as you choose. git-imerge has two primary goals: * Reduce the pain of resolving merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts, namely those between the changes introduced by one commit from each branch. * Allow a merge to be saved, tested, interrupted, published, and collaborated on while it is in progress. The hope is to rescue that branch that has diverged so far from master that merging it seems intractable and the only alternative seems to be to abandon the branch and start again. (I think we've all been there!) I think that it is easiest to understand the concept of incremental merging visually, and therefore I recommend the video of my git-imerge presentation [2] from the GitMerge 2013 conference (20 min) as a good introduction. The full slides for that talk are available in the git-imerge repository under doc/presentations/GitMerge-2013. At the same conference, I was interviewed about git-imerge by Thomas Ferris Nicolaisen for his GitMinutes Podcast #12 [3]. To learn how to use the git-imerge tool itself, I suggest the blog article git-imerge: A Practical Introduction [4] and also the help built unto the command (git-imerge --help and git-imerge SUBCOMMAND --help). If you want more information, the theory and benefits of incremental merging are described in minute detail in a series of blog articles [5]. git-imerge is still experimental, due to a lack of time to work on it. But it is already (cautiously) usable, and I am very excited about the idea and would love to get feedback and help from the community. Michael [1] https://github.com/mhagger/git-imerge [2] http://www.youtube.com/watch?v=FMZ2_-Ny_zc [3] http://episodes.gitminutes.com/2013/06/gitminutes-12-git-merge-2013-part-4.html [4] http://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html [5] http://softwareswirl.blogspot.com/search/label/git-imerge -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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
