Re: [L10N] please review a batch l10n update for Git 2.2.0 final
2014-11-21 7:00 GMT+08:00 Junio C Hamano gits...@pobox.com: I've pushed out what should be -rc3 minus l10n changes and try to make sure there will be no N_() and _() changes. Let's do a 2.2-rc3 as the last round of this cycle tomorrow. I've fetched up to your 7ba2ba7 but haven't merged it yet, just in case you will have further updates. Otherwise, 2.2-rc3 will be what is at the tip of 'master' today with 7ba2ba7 merged in. Hi Junio, Please pull the following changes since commit ca0107e279df1465946970113d68b4ee26ffbcc4: Merge branch 'sv/submitting-final-patch' (2014-11-19 13:48:01 -0800) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 7ba2ba7d12163a8f9a9947d7880bd26f2970d4c5: l10n: remove a superfluous translation for push.c (2014-11-20 16:23:43 +0800) Jiang Xin (3): l10n: git.pot: v2.2.0 round 2 (1 updated) l10n: batch updates for one trivial change l10n: remove a superfluous translation for push.c Ralf Thielow (2): l10n: de.po: translate 2 new messages l10n: de.po: translate 2 messages po/bg.po| 114 ++- po/ca.po| 60 +++--- po/de.po| 631 +++- po/fr.po| 94 + po/git.pot | 48 ++--- po/sv.po| 80 po/vi.po| 60 +++--- po/zh_CN.po | 60 +++--- 8 files changed, 578 insertions(+), 569 deletions(-) -- Jiang Xin -- 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] mergetools: stop setting $status in merge_cmd()
No callers rely on $status so there's don't need to set
it during merge_cmd() for diffmerge, emerge, and kdiff3.
Signed-off-by: David Aguilar dav...@gmail.com
---
This is based on the mergetool/difftool cleanup patches.
mergetools/diffmerge | 1 -
mergetools/emerge| 1 -
mergetools/kdiff3| 1 -
3 files changed, 3 deletions(-)
diff --git a/mergetools/diffmerge b/mergetools/diffmerge
index 85ac720..f138cb4 100644
--- a/mergetools/diffmerge
+++ b/mergetools/diffmerge
@@ -11,5 +11,4 @@ merge_cmd () {
$merge_tool_path --merge \
--result=$MERGED $LOCAL $REMOTE
fi
- status=$?
}
diff --git a/mergetools/emerge b/mergetools/emerge
index f96d9e5..7b895fd 100644
--- a/mergetools/emerge
+++ b/mergetools/emerge
@@ -15,7 +15,6 @@ merge_cmd () {
$LOCAL $REMOTE \
$(basename $MERGED)
fi
- status=$?
}
translate_merge_tool_path() {
diff --git a/mergetools/kdiff3 b/mergetools/kdiff3
index a30034f..793d129 100644
--- a/mergetools/kdiff3
+++ b/mergetools/kdiff3
@@ -20,5 +20,4 @@ merge_cmd () {
-o $MERGED $LOCAL $REMOTE \
/dev/null 21
fi
- status=$?
}
--
2.2.0.rc2.26.g6d3471d.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] copy.c: make copy_fd preserve meaningful errno
On 11/21/2014 10:14 AM, Michael Haggerty wrote: Couldn't we save ourselves a lot of this save_errno boilerplate by making error() and warning() preserve errno? [...] Never mind; I see that Peff already submitted a patch to this effect. Michael -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] lock_ref_sha1_basic: simplify errno handling
On 11/19/2014 02:37 AM, Jeff King wrote:
Now that error() does not clobber errno, we do not have to
take pains to save it ourselves.
Signed-off-by: Jeff King p...@peff.net
---
refs.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 5ff457e..169a46d 100644
--- a/refs.c
+++ b/refs.c
@@ -2232,7 +2232,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
char *ref_file;
const char *orig_refname = refname;
struct ref_lock *lock;
- int last_errno = 0;
int type, lflags;
int mustexist = (old_sha1 !is_null_sha1(old_sha1));
int resolve_flags = 0;
@@ -2260,7 +2259,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
*/
ref_file = git_path(%s, orig_refname);
if (remove_empty_directories(ref_file)) {
- last_errno = errno;
error(there are still refs under '%s', orig_refname);
goto error_return;
}
@@ -2270,7 +2268,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
if (type_p)
*type_p = type;
if (!refname) {
- last_errno = errno;
error(unable to resolve reference %s: %s,
orig_refname, strerror(errno));
goto error_return;
@@ -2283,7 +2280,7 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
*/
if (missing
!is_refname_available(refname, skip, get_packed_refs(ref_cache)))
{
- last_errno = ENOTDIR;
+ errno = ENOTDIR;
goto error_return;
}
@@ -2311,7 +2308,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
goto retry;
/* fall through */
default:
- last_errno = errno;
error(unable to create directory for %s, ref_file);
goto error_return;
}
@@ -2332,7 +2328,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
error_return:
unlock_ref(lock);
- errno = last_errno;
return NULL;
}
error() doesn't clobber errno anymore, but unlock_ref() still might.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] Improve the filemode trustability check
Some file systems do not support the executable bit: a) The user executable bit is always 0, e.g. VFAT mounted with -onoexec b) The user executable bit is always 1, e.g. cifs mounted with -ofile_mode=0755 c) There are system where user executable bit is 1 even if it should be 0 like b), but the file mode can be maintained locally. chmod -x changes the file mode from 0766 to 0666, until the file system is unmounted and remounted and the file mode is 0766 again. This been observed when a Windows machine with NTFS exports a share to Mac OS X via smb or afp. Case a) and b) are handled by the current code. Case c) qualifies as non trustable executable bit and core.filemode should be false, but this is currently not done. Detect when .git/config has the user executable bit set after creat(.git/config, 0666) and set core.filemode to false. Signed-off-by: Torsten Bögershausen tbo...@web.de --- Thanks for the review, I never paid attention to the re-init. The following works for me: builtin/init-db.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/init-db.c b/builtin/init-db.c index aab44d2..2619ca5 100644 --- a/builtin/init-db.c +++ b/builtin/init-db.c @@ -256,6 +256,8 @@ static int create_default_files(const char *template_path) !lstat(path, st2) st1.st_mode != st2.st_mode !chmod(path, st1.st_mode)); + if (filemode !reinit (st1.st_mode S_IXUSR)) + filemode = 0; } git_config_set(core.filemode, filemode ? true : false); -- 2.0.0.GIT -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] Fix the Visual Studio 2008 .sln generator
Hi Philip, On Thu, 20 Nov 2014, Philip Oakley wrote: Are the patches going in the right direction? Yes. A couple of general comments: - please do not comment out code. Just remove it. - the first three commit messages look funny, being indented by 4 spaces... unintentional? Is the processing of the .obj file in engine.pl sensible? Yes, but instead of adding dead code, it would be better to use the comment # ignore. I would also strongly suggest to hard-code the complete file name instead of just the extension. We know exactly which file name we want to ignore, and if there should be another .obj file eventually, it would be wrong to ignore it, too. and the extra care with s/\.o$/.c/ avoiding s/obj/cbj/. Technically, you need to use a group \($\|[ \t]\), but I think that that would be overkill. Does it affect the Qmake capability? (I've no idea) Frankly, neither do I ;-) But since you touched only engine.pl, I would expect Qmake not to be affected at all, right? Is the quoting of filenames correct? (my perl foo is cargo cult!) IANAPME (I am not a Perl Monk either), but it looks good to me. I've also updated the vcbuild/README to mention Msysgit (which will be replaced soon by the newer/better Git-for-windows/SDK (https://github.com/git-for-windows/sdk), but the benefits still apply. The path you used is /msysgit/bin/msvc-build, but the real path would be /bin/msvc-build. Obviously, the patches will need squashing together, To the contrary, I like the current separation of concerns. Ciao, Johannes -- 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: [RFC 1/4] Fix i18n -o option in msvc engine.pl
Hi Philip,
On Thu, 20 Nov 2014, Philip Oakley wrote:
The i18n 5e9637c6 introduced an extra '-o' option
into the make file,
I take it you are referring to
https://github.com/git/git/commit/5e9637c6#diff-b67911656ef5d18c4ae36cb6741b7965R2195
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 23da787..9144ea7 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -140,6 +140,18 @@ sub parseMakeOutput
next;
}
+if ($text =~ /^mkdir /) {
+# options to the Portable Object translations in the line
+# mkdir -p po/... msgfmt ... (eg -o) may be mistaken for
linker options
Maybe better
# the line mkdir ... msgfmt ... contains no linker options
+next;
+}
+
+if ($text =~ /^msgfmt /) {
+# options to the Portable Object translations in the line
+# mkdir -p po/... msgfmt ... (eg -o) may be mistaken for
linker options
+next;
+}
These two if clauses do the same, maybe call it
if ($test =~ /^(mkdir|msgfmt) /)
Ciao,
Johannes
--
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: [RFC 2/4] Properly accept quoted space in filenames
Hi Philip,
apart from adding dead code:
On Thu, 20 Nov 2014, Philip Oakley wrote:
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 9144ea7..8e41808 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -243,7 +244,8 @@ sub removeDuplicates
sub handleCompileLine
{
my ($line, $lineno) = @_;
-my @parts = split(' ', $line);
+# my @parts = split(' ', $line);
+my @parts = quotewords('\s+', 0, $line);
my $sourcefile;
(i.e. the commented-out line) it looks good to me.
Ciao,
Johannes
--
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: [RFC 3/4] engine.pl: split the .o and .obj processing
Hi Philip,
On Thu, 20 Nov 2014, Philip Oakley wrote:
Commit 4b623d80f7352 added an .obj file (invalidcontinue.obj) which was not
processed correctly.
The generate engine then mistakenly did a s/.o/.c/ to create a request
to compile invalidcontinue.cbj.
This is good. However, this:
Split the '/\.(o|obj)$' in engine.pl#L353 into:
} elsif ($part =~ /\.o$/) { # was '/\.(o|obj)$'
push(@objfiles, $part);
} elsif ($part =~ /\.obj$/) { # was '/\.(o|obj)$'
# push(@objfiles, $part); # do nothing
} else {
just repeats what the diff says, so it is unnecessary in the commit
message.
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 8e41808..16c3dd5 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -264,7 +264,9 @@ sub handleCompileLine
} elsif ($part =~ /\.(c|cc|cpp)$/) {
$sourcefile = $part;
} else {
-die Unhandled compiler option @ line $lineno: $part;
+print full line: $line\n;
+print A:-Unhandled compiler option @ line $lineno: $part\n; #
die (if !DEBUG)
+#die Unhandled compiler option @ line $lineno: $part;
This needs to be backed out. I agree that it is nice to get going and to
debug, so I would split it out into its own commit while working on the
branch, but then drop it before submitting.
@@ -290,14 +292,15 @@ sub handleLibLine
[...]
foreach (@objfiles) {
my $sourcefile = $_;
-$sourcefile =~ s/\.o/.c/;
+$sourcefile =~ s/\.o$/.c/;
Ah, I see from the context that my earlier comment about the white-space
delimiter was wrong: at this stage, we already have split the list. So
this is groovy.
@@ -343,8 +346,10 @@ sub handleLinkLine
} elsif ($part =~ /\.(a|lib)$/) {
$part =~ s/\.a$/.lib/;
push(@libs, $part);
-} elsif ($part =~ /\.(o|obj)$/) {
+} elsif ($part =~ /\.o$/) { # was '/\.(o|obj)$'
push(@objfiles, $part);
+} elsif ($part =~ /\.obj$/) { # was '/\.(o|obj)$'
+# push(@objfiles, $part); # do nothing
How about the following instead?
+ } elsif ($part eq 'invalidcontinue.obj') {
+ # ignore
} elsif ($part =~ /\.(o|obj)$/) {
? After all, this change is really only about handling the newly
introduced invalidcontinue.obj correctly.
Ciao,
Johannes
--
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: [RFC 4/4] Improve layout and reference msvc-build script
Hi Philip, On Thu, 20 Nov 2014, Philip Oakley wrote: [...] +Or, use the msvc-build script; also in /msysgit/bin/msvc-build As I mentioned before, from a Git Bash on Windows, the path is /bin/msvc-build (no /msysgit/). That is quite likely to stay the same with the upcoming Git for Windows SDK, too (once I add the file to the SDK). By the way, I think we should also start thinking about a Jenkins job to verify that upstream changes such as invalidcontinue.obj do not break the MSVC build. Please let me know if you want to give it a try, I have a Windows Azure instance with a Jenkins instance, sponsored by Microsoft. Ciao, Johannes -- 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 RFC] t0027: check the eol conversion warnings
On 20.11.14 23:37, Junio C Hamano wrote: --- At a glance it is very hard to see what we might be _losing_ with this change that claims to add new kinds of tests on top of existing ones. I am guessing that add-check-warn roughly corresponds to the old create-file-in-repo but they have different calling conventions, or something? Perhaps split it into two patches (or more), each of which does one thing and one thing well? I suspect that even with a two-patch split (e.g. the first of which only renames the function without adding the new grep in error messages that could be localized and give false failures code, and the second adds the lf/crlf stuff) might make this at least readable. I dunno. We shouldn't loose anything. The diff is hard to read, as some code is re-defined and re-used (and a diff side-by-side looks nicer than the patch) I will come back with a new commit message, which should explain things better ( or a 2-stepped patch) The long term idea is to improve the gray areas in convert.c, and to do that we need a reliable test frame work, to see what is improved or broken. -- 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
Add an alias for --abort option
Hello, is it allowed add alias '--abandone' for --abort option in git commands (git am, git rebase, etc.)? The word 'abort' have too negative meaning in the russian language. For example, for git am we have three option names for continue operation: --continue, -r, --resolved -- Vitaly Lipatov, Etersoft -- 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/6] prune_remote(): exit early if there are no stale references
Aside from making the logic clearer, this avoids a call to
warn_dangling_symrefs(), which always does a for_each_rawref()
iteration.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 39 +--
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 7f28f92..d2b684c 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1325,25 +1325,28 @@ static int prune_remote(const char *remote, int dry_run)
memset(states, 0, sizeof(states));
get_remote_ref_states(remote, states, GET_REF_STATES);
- if (states.stale.nr) {
- printf_ln(_(Pruning %s), remote);
- printf_ln(_(URL: %s),
- states.remote-url_nr
- ? states.remote-url[0]
- : _((no URL)));
-
- delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
- for (i = 0; i states.stale.nr; i++)
- delete_refs[i] = states.stale.items[i].util;
- if (!dry_run) {
- struct strbuf err = STRBUF_INIT;
- if (repack_without_refs(delete_refs, states.stale.nr,
- err))
- result |= error(%s, err.buf);
- strbuf_release(err);
- }
- free(delete_refs);
+ if (!states.stale.nr) {
+ free_remote_ref_states(states);
+ return 0;
+ }
+
+ printf_ln(_(Pruning %s), remote);
+ printf_ln(_(URL: %s),
+ states.remote-url_nr
+ ? states.remote-url[0]
+ : _((no URL)));
+
+ delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
+ for (i = 0; i states.stale.nr; i++)
+ delete_refs[i] = states.stale.items[i].util;
+ if (!dry_run) {
+ struct strbuf err = STRBUF_INIT;
+ if (repack_without_refs(delete_refs, states.stale.nr,
+ err))
+ result |= error(%s, err.buf);
+ strbuf_release(err);
}
+ free(delete_refs);
for (i = 0; i states.stale.nr; i++) {
const char *refname = states.stale.items[i].util;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] repack_without_refs(): make the refnames argument a string_list
All of the callers have string_lists available already, whereas two of
them had to read data out of a string_list into an array of strings
just to call this function. So change repack_without_refs() to take
the list of refnames to omit as a string_list, and change the callers
accordingly.
Suggested-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 14 ++
refs.c | 38 --
refs.h | 11 ++-
3 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 7d5c8d2..63a6709 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -750,16 +750,11 @@ static int mv(int argc, const char **argv)
static int remove_branches(struct string_list *branches)
{
struct strbuf err = STRBUF_INIT;
- const char **branch_names;
int i, result = 0;
- branch_names = xmalloc(branches-nr * sizeof(*branch_names));
- for (i = 0; i branches-nr; i++)
- branch_names[i] = branches-items[i].string;
- if (repack_without_refs(branch_names, branches-nr, err))
+ if (repack_without_refs(branches, err))
result |= error(%s, err.buf);
strbuf_release(err);
- free(branch_names);
for (i = 0; i branches-nr; i++) {
struct string_list_item *item = branches-items + i;
@@ -1317,7 +1312,6 @@ static int prune_remote(const char *remote, int dry_run)
int result = 0, i;
struct ref_states states;
struct string_list delete_refs_list = STRING_LIST_INIT_NODUP;
- const char **delete_refs;
const char *dangling_msg = dry_run
? _( %s will become dangling!)
: _( %s has become dangling!);
@@ -1336,19 +1330,16 @@ static int prune_remote(const char *remote, int dry_run)
? states.remote-url[0]
: _((no URL)));
- delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
for (i = 0; i states.stale.nr; i++) {
const char *refname = states.stale.items[i].util;
- delete_refs[i] = refname;
string_list_append(delete_refs_list, refname);
}
sort_string_list(delete_refs_list);
if (!dry_run) {
struct strbuf err = STRBUF_INIT;
- if (repack_without_refs(delete_refs, states.stale.nr,
- err))
+ if (repack_without_refs(delete_refs_list, err))
result |= error(%s, err.buf);
strbuf_release(err);
}
@@ -1369,7 +1360,6 @@ static int prune_remote(const char *remote, int dry_run)
warn_dangling_symrefs(stdout, dangling_msg, delete_refs_list);
- free(delete_refs);
string_list_clear(delete_refs_list, 0);
free_remote_ref_states(states);
return result;
diff --git a/refs.c b/refs.c
index 5ff457e..b675e01 100644
--- a/refs.c
+++ b/refs.c
@@ -2639,22 +2639,25 @@ static int curate_packed_ref_fn(struct ref_entry
*entry, void *cb_data)
return 0;
}
-int repack_without_refs(const char **refnames, int n, struct strbuf *err)
+int repack_without_refs(struct string_list *refnames, struct strbuf *err)
{
struct ref_dir *packed;
struct string_list refs_to_delete = STRING_LIST_INIT_DUP;
- struct string_list_item *ref_to_delete;
- int i, ret, removed = 0;
+ struct string_list_item *refname, *ref_to_delete;
+ int ret, needs_repacking = 0, removed = 0;
assert(err);
/* Look for a packed ref */
- for (i = 0; i n; i++)
- if (get_packed_ref(refnames[i]))
+ for_each_string_list_item(refname, refnames) {
+ if (get_packed_ref(refname-string)) {
+ needs_repacking = 1;
break;
+ }
+ }
/* Avoid locking if we have nothing to do */
- if (i == n)
+ if (!needs_repacking)
return 0; /* no refname exists in packed refs */
if (lock_packed_refs(0)) {
@@ -2664,8 +2667,8 @@ int repack_without_refs(const char **refnames, int n,
struct strbuf *err)
packed = get_packed_refs(ref_cache);
/* Remove refnames from the cache */
- for (i = 0; i n; i++)
- if (remove_entry(packed, refnames[i]) != -1)
+ for_each_string_list_item(refname, refnames)
+ if (remove_entry(packed, refname-string) != -1)
removed = 1;
if (!removed) {
/*
@@ -3738,10 +3741,11 @@ static int ref_update_reject_duplicates(struct
ref_update **updates, int n,
int ref_transaction_commit(struct ref_transaction *transaction,
struct strbuf *err)
{
- int ret = 0, delnum = 0, i;
- const char **delnames;
+ int ret = 0, i;
int n = transaction-nr;
[PATCH 5/6] prune_remote(): rename local variable
Rename delete_refs_list to refs_to_prune. The new name is more
self-explanatory.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 63a6709..efbf5fb 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1311,7 +1311,7 @@ static int prune_remote(const char *remote, int dry_run)
{
int result = 0, i;
struct ref_states states;
- struct string_list delete_refs_list = STRING_LIST_INIT_NODUP;
+ struct string_list refs_to_prune = STRING_LIST_INIT_NODUP;
const char *dangling_msg = dry_run
? _( %s will become dangling!)
: _( %s has become dangling!);
@@ -1333,13 +1333,13 @@ static int prune_remote(const char *remote, int dry_run)
for (i = 0; i states.stale.nr; i++) {
const char *refname = states.stale.items[i].util;
- string_list_append(delete_refs_list, refname);
+ string_list_append(refs_to_prune, refname);
}
- sort_string_list(delete_refs_list);
+ sort_string_list(refs_to_prune);
if (!dry_run) {
struct strbuf err = STRBUF_INIT;
- if (repack_without_refs(delete_refs_list, err))
+ if (repack_without_refs(refs_to_prune, err))
result |= error(%s, err.buf);
strbuf_release(err);
}
@@ -1358,9 +1358,9 @@ static int prune_remote(const char *remote, int dry_run)
abbrev_ref(refname, refs/remotes/));
}
- warn_dangling_symrefs(stdout, dangling_msg, delete_refs_list);
+ warn_dangling_symrefs(stdout, dangling_msg, refs_to_prune);
- string_list_clear(delete_refs_list, 0);
+ string_list_clear(refs_to_prune, 0);
free_remote_ref_states(states);
return result;
}
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] prune_remote(): initialize both delete_refs lists in a single loop
Also free them together at the end of the function.
In a moment, the array version will become redundant. Managing them
together makes later steps more obvious.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index d2b684c..d5a5a16 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1337,8 +1337,13 @@ static int prune_remote(const char *remote, int dry_run)
: _((no URL)));
delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs));
- for (i = 0; i states.stale.nr; i++)
- delete_refs[i] = states.stale.items[i].util;
+ for (i = 0; i states.stale.nr; i++) {
+ const char *refname = states.stale.items[i].util;
+
+ delete_refs[i] = refname;
+ string_list_insert(delete_refs_list, refname);
+ }
+
if (!dry_run) {
struct strbuf err = STRBUF_INIT;
if (repack_without_refs(delete_refs, states.stale.nr,
@@ -1346,13 +1351,10 @@ static int prune_remote(const char *remote, int dry_run)
result |= error(%s, err.buf);
strbuf_release(err);
}
- free(delete_refs);
for (i = 0; i states.stale.nr; i++) {
const char *refname = states.stale.items[i].util;
- string_list_insert(delete_refs_list, refname);
-
if (!dry_run)
result |= delete_ref(refname, NULL, 0);
@@ -1365,8 +1367,9 @@ static int prune_remote(const char *remote, int dry_run)
}
warn_dangling_symrefs(stdout, dangling_msg, delete_refs_list);
- string_list_clear(delete_refs_list, 0);
+ free(delete_refs);
+ string_list_clear(delete_refs_list, 0);
free_remote_ref_states(states);
return result;
}
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] prune_remote(): iterate using for_each_string_list_item()
Iterate over refs_to_prune using for_each_string_list_item() rather
than writing out the loop in longhand.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index efbf5fb..7fec170 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1309,9 +1309,10 @@ static int set_head(int argc, const char **argv)
static int prune_remote(const char *remote, int dry_run)
{
- int result = 0, i;
+ int result = 0;
struct ref_states states;
struct string_list refs_to_prune = STRING_LIST_INIT_NODUP;
+ struct string_list_item *item;
const char *dangling_msg = dry_run
? _( %s will become dangling!)
: _( %s has become dangling!);
@@ -1330,11 +1331,8 @@ static int prune_remote(const char *remote, int dry_run)
? states.remote-url[0]
: _((no URL)));
- for (i = 0; i states.stale.nr; i++) {
- const char *refname = states.stale.items[i].util;
-
- string_list_append(refs_to_prune, refname);
- }
+ for_each_string_list_item(item, states.stale)
+ string_list_append(refs_to_prune, item-util);
sort_string_list(refs_to_prune);
if (!dry_run) {
@@ -1344,8 +1342,8 @@ static int prune_remote(const char *remote, int dry_run)
strbuf_release(err);
}
- for (i = 0; i states.stale.nr; i++) {
- const char *refname = states.stale.items[i].util;
+ for_each_string_list_item(item, states.stale) {
+ const char *refname = item-util;
if (!dry_run)
result |= delete_ref(refname, NULL, 0);
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] repack_without_refs(): convert to string_list
This is basically an atomized version of Ronnie/Jonathan/Stefan's patch [1] refs.c: use a stringlist for repack_without_refs. But I've actually rewritten most of it from scratch, using the original patch as a reference. I was reviewing the original patch and it looked mostly OK [2], but I found it hard to read because it did several steps at once. So I tried to make the same basic change, but one baby step at a time. This is the result. I'm a known fanatic about making the smallest possible changes in each commit. The goal is to make the patch series as readable as possible, because reviewers' time is in shorter supply than coders' time. * Tiny little patches are IMO usually much easier to read than big ones, because there is less to keep in mind at a time. * Often tiny changes (e.g., renaming variables or functions) are so blindingly obvious that one only has to skim them, or even trust that the author, with the help of the compiler, could hardly have made a mistake [3]. * Using baby steps keeps the author from introducing unnecessary changes (code churn), by forcing him/her to justify each change on its own merits. * Using baby steps makes it harder for substantive changes to get overlooked or to sneak in without discussion [4]. * If there is a problem, baby commits can be bisected, usually making it obvious why the bug arose. * If the mailing list doesn't like part of the series, it is usually easier to omit a patch from the next reroll than to extract one change out of a patch that contains multiple logical changes. * It is often possible to arrange the order of the patches to give the patch series a good narrative. Some members of the community probably disagree with me. Using baby step patches means that there is more mailing list traffic and more commits that accumulate in the project's history. There is sometimes a bit of extra to-and-fro as code is mutated incrementally. Or maybe other people can just keep more complicated changes in their heads at one time than I can. Nevertheless, I submit this version of the patch series for your amusement. Feel free to ignore it. [1] http://mid.gmane.org/1416434399-2303-1-git-send-email-sbel...@google.com [2] Problems that I noticed: * The commit message refers to stringlist where it should be string_list. * One of the loops in prune_remote() iterates using indexes, while another loop (over the same string_list) uses for_each_string_list_item(). * The change from using string_list_insert() to string_list_append() in the same function, followed by sort_string_list(), doesn't remove duplicates as the old version did. The commit message should justify that this is OK. [3] I love the quote from C. A. R. Hoare: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. I think the same thing applies to patches. [4] Case in point: when I was writing the commit message for patch 3/6, I realized that string_list_insert() omits duplicates whereas string_list_append() obviously doesn't. This aspect of the change wasn't justified. Do we have to add a call to string_list_remove_duplicates()? It turns out that the list cannot contain duplicates, but it took some digging to verify this. Michael Haggerty (6): prune_remote(): exit early if there are no stale references prune_remote(): initialize both delete_refs lists in a single loop prune_remote(): sort delete_refs_list references en masse repack_without_refs(): make the refnames argument a string_list prune_remote(): rename local variable prune_remote(): iterate using for_each_string_list_item() builtin/remote.c | 59 ++-- refs.c | 38 +++- refs.h | 11 ++- 3 files changed, 57 insertions(+), 51 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] prune_remote(): sort delete_refs_list references en masse
Inserting items into a list in sorted order is O(N^2) whereas
appending them unsorted and then sorting the list all at once is
O(N lg N).
string_list_insert() also removes duplicates, and this change loses
that functionality. But the strings in this list, which ultimately
come from a for_each_ref() iteration, cannot contain duplicates.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index d5a5a16..7d5c8d2 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1341,8 +1341,9 @@ static int prune_remote(const char *remote, int dry_run)
const char *refname = states.stale.items[i].util;
delete_refs[i] = refname;
- string_list_insert(delete_refs_list, refname);
+ string_list_append(delete_refs_list, refname);
}
+ sort_string_list(delete_refs_list);
if (!dry_run) {
struct strbuf err = STRBUF_INIT;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] repack_without_refs(): convert to string_list
On 11/21/2014 03:09 PM, Michael Haggerty wrote: This is basically an atomized version of Ronnie/Jonathan/Stefan's patch [1] refs.c: use a stringlist for repack_without_refs. But I've actually rewritten most of it from scratch, using the original patch as a reference. Naturally, right after I emailed this series I realized that there have been two more iterations on the original patch, which I overlooked because I was not CCed on them. (I'm not complaining, just explaining.) I don't think that those iterations changed anything substantial that overlaps with my version, but TBH it's such a pain in the ass working with patches in email that I don't think I'll go to the effort of checking for sure unless somebody shows interest in actually using my version. Sorry for being grumpy today :-( Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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-new-workdir: Don't fail if the target directory is empty
On Thu, 2014-11-20 at 09:13 -0800, Junio C Hamano wrote: Paul Smith p...@mad-scientist.net writes: +# don't recreate a workdir over an existing directory, unless it's empty +if test -d $new_workdir then - die destination directory '$new_workdir' already exists. + if test $(ls -a1 $new_workdir/. | wc -l) -ne 2 You used to quote this as if test $(ls -a1 $new_workdir/. | wc -l) -ne 2 and I think that made a lot more sense than the new quoting. Just personal script coding style. I tend to quote just variables, in case I want to add globbing or whatever later. I've run into people who think that $foo/bar needs quotes because it concatenates two strings, but you don't need to quote $foo by itself; quoting just the variable helps avoid that impression. But this doesn't matter much to me. Case arms come at the same indentation level as case/esac. OK. Why these changes? I thought you are making sure $cleandir is absolute so that you do not have to do this and can just cd into the new working tree, the same way the user would do once it is set up. I made cleandir absolute mainly because you asked me to :-). I didn't realize that the implication behind that request was that I'd put back the original cd as well. I personally distrust and avoid raw cd in shell scripts. It's action-at-a-distance and can cause all sorts of problems, sometimes disastrous ones. If I need to change directories I localize it, e.g.: (cd $somedir do some command) so it's clear that it's in effect only for that command. I understand that in this particular situation the cd is right before the end so this doesn't hurt (as the script stands today). If you prefer the cd explicitly I'll add it back. You're the one that needs to be happy with it :-). What if I move the cd down to right before the checkout command, and use $new_workdir in the copy of HEAD? At least it won't be in effect until after the workdir is completely set up. I would feel better about it then :-). -# now setup the workdir -cd $new_workdir # copy the HEAD from the original repository as a default branch -cp $git_dir/HEAD .git/HEAD -# checkout the branch (either the same as HEAD from the original repository, or -# the one that was asked for) -git checkout -f $branch -- 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: [RFD/PATCH] add: ignore only ignored files
Jeff King schrieb am 20.11.2014 um 19:20: On Thu, Nov 20, 2014 at 09:23:21AM -0800, Junio C Hamano wrote: diff --git a/builtin/add.c b/builtin/add.c index ae6d3e2..1074e32 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -284,7 +284,7 @@ static int add_files(struct dir_struct *dir, int flags) for (i = 0; i dir-ignored_nr; i++) fprintf(stderr, %s\n, dir-ignored[i]-name); fprintf(stderr, _(Use -f if you really want to add them.\n)); - die(_(no files added)); + exit_status = 1; } for (i = 0; i dir-nr; i++) It needs a tweak to t3700.35, which expects the fatal: line on stderr. But other than that, it passes all tests. So it must be good, right? :) ;-) It indeed is a behaviour change, but I do not expect it would be too heavy a change to require us a transition period or major version bump. But because that is just my expectation, which is not what real world users would expect, so I'd prefer to cook such a change for at least a cycle and a half in 'next'. Oh, definitely. Showing the patch at all was my not-so-subtle attempt to convince Michael to take over the topic so I did not have to worry about such things. :) Well, given that I figured out how to do it with the option, it may come at no additional surprise that I figured out how to do it without the option, as well. The real extra surprise is - not only that test fix is in my tree already - it even comes with a test that actually tests the new intended behavior. Whoaaa! I'll resend it soon so that Jeff can take over and adjust the commit message ;) Michael, just kidding -- 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: Add an alias for --abort option
Vitaly Lipatov schrieb am 21.11.2014 um 13:41:
Hello,
is it allowed add alias '--abandone' for --abort option in git commands
(git am, git rebase, etc.)?
The word 'abort' have too negative meaning in the russian language.
But that is the english localisation. We do have git in other languages
- maybe not Russian yet, but it would be great and welcome to change that!
('abort' is negative in german, too).
For example, for git am we have three option names for continue
operation:
--continue, -r, --resolved
I think it's a bad precedence. We should rather fight option bloat.
Michael
--
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
Cannot set the commit-message editor
I have downloaded the latest git from git-scm on my windows machine. I am using git on windows, I am having trouble trying to get notepad++ as my commit message editor. I have created a shell script called npp.sh which has the following content /c/Program\ Files\ \(x86\)/Notepad++/notepad++.exe -multiInst -nosession -noPlugin $1 I figured this is how paths are accepted in git-bash Now I configured core.editor this way git config --global core.editor /c/path/to/npp.sh when I try to commit, using the following command git commit I get the following error $ git commit error: cannot spawn c:/path/to/npp.sh: No such file or directory error: unable to start editor 'c:/dev/tools/cmd/npp.sh' Please supply the message using either -m or -F option. when I run the following command ls c:/ I get the directory for my repository's root, not C drive's root When I run the following command through git-bash /c/path/to/npp.sh It works but when git commit invokes, it does not. Here is more of what I found when 'git commit' launches npp.sh, it changes /c/path/to/npp.sh to c:/path/to/npp.sh c:/ is not the root of my C drive according to git-bash, c:/ is root of my repository because when I run 'ls c:/' I get files from root of my repository. so may be if 'git commit' does not change /c/path/to/npp.sh to c:/path/to/npp.sh, it would work... Or if git-bash does not mount c:/ to /c/path/to/myrepository and keep it to /c it would work too. Please let me know if you need more info on this Thanks Fahad -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] add: ignore only ignored files
git add foo bar adds neither foo nor bar when bar is ignored, but dies to let the user recheck their command invocation. This becomes less helpful when git add foo.* is subject to shell expansion and some of the expanded files are ignored. git add --ignore-errors is supposed to ignore errors when indexing some files and adds the others. It does ignore errors from actual indexing attempts, but does not ignore the error file is ignored as outlined above. This is unexpected. Change git add foo bar to add foo when bar is ignored, but issue a warning and return a failure code as before the change. That is, in the case of trying to add ignored files we now act the same way (with or without --ignore-errors) in which we act for more severe indexing errors when --ignore-errors is specified. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- As discussed, we change behavior even without the option. I.a.w.: We declare add ignored file as a minor error compared to an actual indexing error. My sincere thanks go out to Jeff without whom I could not possibly have come up with a patch like this :) builtin/add.c | 2 +- t/t3700-add.sh | 8 +++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/builtin/add.c b/builtin/add.c index ae6d3e2..1074e32 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -284,7 +284,7 @@ static int add_files(struct dir_struct *dir, int flags) for (i = 0; i dir-ignored_nr; i++) fprintf(stderr, %s\n, dir-ignored[i]-name); fprintf(stderr, _(Use -f if you really want to add them.\n)); - die(_(no files added)); + exit_status = 1; } for (i = 0; i dir-nr; i++) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index fe274e2..f7ff1f5 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -91,6 +91,13 @@ test_expect_success 'error out when attempting to add ignored ones without -f' ' ! (git ls-files | grep \\.ig) ' +test_expect_success 'error out when attempting to add ignored ones but add others' ' + touch a.if + test_must_fail git add a.?? + ! (git ls-files | grep \\.ig) + (git ls-files | grep a.if) +' + test_expect_success 'add ignored ones with -f' ' git add -f a.?? git ls-files --error-unmatch a.ig @@ -311,7 +318,6 @@ cat expect.err \EOF The following paths are ignored by one of your .gitignore files: ignored-file Use -f if you really want to add them. -fatal: no files added EOF cat expect.out \EOF add 'track-this' -- 2.2.0.rc2.293.gc05a35d -- 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 3/6] prune_remote(): sort delete_refs_list references en masse
On Fri, Nov 21, 2014 at 6:09 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Inserting items into a list in sorted order is O(N^2) whereas
appending them unsorted and then sorting the list all at once is
O(N lg N).
string_list_insert() also removes duplicates, and this change loses
that functionality. But the strings in this list, which ultimately
come from a for_each_ref() iteration, cannot contain duplicates.
A similar conversion in other places we may do in the future
might find a need for an equivalent to -u option of sort in the
string_list_sort() function, but the above nicely explains why
it is not necessary for this one. Good.
Eh, why is that called sort_string_list()? Perhaps it is a good
opening to introduce string_list_sort(list, flag) where flag would
be a bitmask that represents ignore-case, uniquify, etc., and
then either deprecate the current one or make it a thin wrapper
of the one that is more consistently named.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/remote.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index d5a5a16..7d5c8d2 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1341,8 +1341,9 @@ static int prune_remote(const char *remote, int dry_run)
const char *refname = states.stale.items[i].util;
delete_refs[i] = refname;
- string_list_insert(delete_refs_list, refname);
+ string_list_append(delete_refs_list, refname);
}
+ sort_string_list(delete_refs_list);
if (!dry_run) {
struct strbuf err = STRBUF_INIT;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-new-workdir: Don't fail if the target directory is empty
Paul Smith p...@mad-scientist.net writes: Why these changes? I thought you are making sure $cleandir is absolute so that you do not have to do this and can just cd into the new working tree, the same way the user would do once it is set up. I made cleandir absolute mainly because you asked me to :-). I didn't realize that the implication behind that request was that I'd put back the original cd as well. This is about not changing unnecessarily the original that has been battle-tested and keeping the result resistant to future mistakes (i.e. somebody going elsewhere without realizing a relative cleandir will cause problems). Once $cleandir is fixed, there no longer is a good reason to change how HEAD is pointed in the $new_workdir or its working tree populated; the change in the earlier round in that area was necessary when $cleandir was not absolute, but not anymore. -- 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: Cannot set the commit-message editor
From: Fahad Ashfaque fahad...@gmail.com I have downloaded the latest git from git-scm on my windows machine. I am using git on windows, I am having trouble trying to get notepad++ as my commit message editor. I have created a shell script called npp.sh which has the following content /c/Program\ Files\ \(x86\)/Notepad++/notepad++.exe -multiInst -nosession -noPlugin $1 I figured this is how paths are accepted in git-bash Now I configured core.editor this way git config --global core.editor /c/path/to/npp.sh I simply have (from 'git config -l'): core.editor='C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noplugin when I try to commit, using the following command git commit I get the following error $ git commit error: cannot spawn c:/path/to/npp.sh: No such file or directory error: unable to start editor 'c:/dev/tools/cmd/npp.sh' Please supply the message using either -m or -F option. when I run the following command ls c:/ I get the directory for my repository's root, not C drive's root When I run the following command through git-bash /c/path/to/npp.sh It works but when git commit invokes, it does not. Here is more of what I found when 'git commit' launches npp.sh, it changes /c/path/to/npp.sh to c:/path/to/npp.sh c:/ is not the root of my C drive according to git-bash, Correct. The Linux bash is rooted, _usually_, at the base of your personal 'c:/documents and settings' (or whatever on your Windows version), with the MS drives under /c/ and /d/ etc. i.e. a load of virtualisation. use 'pwd -W' to get the true (Windows) path of your current/present working directory. (I had to ask just a few days ago ;-) c:/ is root of my repository because when I run 'ls c:/' I get files from root of my repository. I wouldn't have expected that to play nice (confusion between windows and linux path styles). so may be if 'git commit' does not change /c/path/to/npp.sh to c:/path/to/npp.sh, it would work... Or if git-bash does not mount c:/ to /c/path/to/myrepository and keep it to /c it would work too. Please let me know if you need more info on this I've also copied in the Git user / Git for Human beings list (for reference) which can be useful for Windows based issues. Thanks Fahad -- -- 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] copy.c: make copy_fd preserve meaningful errno
Michael Haggerty mhag...@alum.mit.edu writes: On 11/21/2014 10:14 AM, Michael Haggerty wrote: Couldn't we save ourselves a lot of this save_errno boilerplate by making error() and warning() preserve errno? [...] Never mind; I see that Peff already submitted a patch to this effect. My understanding of the conclusion of those four patches was that only a single updated one is needed, and moving save/restore inside error() did not have to survive. http://article.gmane.org/gmane.comp.version-control.git/259911 -- 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] copy.c: make copy_fd preserve meaningful errno
On Fri, Nov 21, 2014 at 09:48:19AM -0800, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: On 11/21/2014 10:14 AM, Michael Haggerty wrote: Couldn't we save ourselves a lot of this save_errno boilerplate by making error() and warning() preserve errno? [...] Never mind; I see that Peff already submitted a patch to this effect. My understanding of the conclusion of those four patches was that only a single updated one is needed, and moving save/restore inside error() did not have to survive. http://article.gmane.org/gmane.comp.version-control.git/259911 Yeah, the callsite I had intended ended up needing to save it across more than just error(). And I think that is probably why we have never done any errno-handling inside error() before (it is certainly not the first time I thought of doing such a thing): real-world cases tend to be a little more complicated. That being said, if this copy() case is one that could benefit, I do not have any problem with picking up (or just reusing the concept of) my 1/4 from that series. It probably does not _hurt_ anything, and if it can help in even a few cases, it may be worth it. -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: Add an alias for --abort option
Michael J Gruber писал 2014-11-21 18:44:
Vitaly Lipatov schrieb am 21.11.2014 um 13:41:
Hello,
is it allowed add alias '--abandone' for --abort option in git
commands
(git am, git rebase, etc.)?
The word 'abort' have too negative meaning in the russian language.
But that is the english localisation. We do have git in other
languages
- maybe not Russian yet, but it would be great and welcome to change
that!
I sure the git in any language has the same options. It is not language
specific really.
('abort' is negative in german, too).
And my suggest is add more correct word. Definitely, we never can just
change option's name.
For example, for git am we have three option names for continue
operation:
--continue, -r, --resolved
I think it's a bad precedence. We should rather fight option bloat.
By my mind, if we have compatibility names it helps our brain to
operate with command line in more intuitive manner.
--
Vitaly Lipatov,
Etersoft
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] repack_without_refs(): convert to string_list
Michael Haggerty mhag...@alum.mit.edu writes: I don't think that those iterations changed anything substantial that overlaps with my version, but TBH it's such a pain in the ass working with patches in email that I don't think I'll go to the effort of checking for sure unless somebody shows interest in actually using my version. Sorry for being grumpy today :-( Is the above meant as a grumpy rant to be ignored, or as a discussion starter to improve the colaboration to allow people to work better together instead of stepping on each other's patches? FWIW, I liked your rationale for many smaller steps. One small uncomfort in that approach is that it often is not very obvious by reading log -p master.. alone how well the end result fits together. Each individual step may make sense, or at least it may not make it any worse than the original, but until you apply the whole series and read diff master... in a sitting, it is somewhat hard to tell where you are going. But this is not risk or bad thing; just something that may make readers feel uncomfortable---we are not losing anything by splitting a series into small logical chunks. Thanks. -- 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: [PATCHv2] add: ignore only ignored files
On Fri, Nov 21, 2014 at 05:08:19PM +0100, Michael J Gruber wrote: git add foo bar adds neither foo nor bar when bar is ignored, but dies to let the user recheck their command invocation. This becomes less helpful when git add foo.* is subject to shell expansion and some of the expanded files are ignored. git add --ignore-errors is supposed to ignore errors when indexing some files and adds the others. It does ignore errors from actual indexing attempts, but does not ignore the error file is ignored as outlined above. This is unexpected. Change git add foo bar to add foo when bar is ignored, but issue a warning and return a failure code as before the change. That is, in the case of trying to add ignored files we now act the same way (with or without --ignore-errors) in which we act for more severe indexing errors when --ignore-errors is specified. Thanks, this looks pretty good to me. I agree with Junio's sense that we should cook it extra long to give people time to react. My sincere thanks go out to Jeff without whom I could not possibly have come up with a patch like this :) :) Sorry if I was being obnoxious before. Sometimes contributors need a gentle push to keep going, but I should know by now that you are not such a person. diff --git a/t/t3700-add.sh b/t/t3700-add.sh index fe274e2..f7ff1f5 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -91,6 +91,13 @@ test_expect_success 'error out when attempting to add ignored ones without -f' ' ! (git ls-files | grep \\.ig) ' +test_expect_success 'error out when attempting to add ignored ones but add others' ' + touch a.if + test_must_fail git add a.?? + ! (git ls-files | grep \\.ig) + (git ls-files | grep a.if) +' I am somewhat allergic to pipes in our test suite, because they can mask errors (especially with a negated grep, because we do not know if they correctly produced any output at all). But I guess this is matching the surrounding code, and it is quite unlikely for `ls-files` to fail in any meaningful way here. So I think it's fine. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git merge a b when a == b but neither == o is always a successful merge?
On Mon, Nov 17, 2014 at 05:21:03PM -0500, Daniel Hagerty wrote: I don't think there is an easy way to get what you want. You would have to write a new merge 3-way strategy that handles this case differently. And most of the file-level heavy lifting in merge strategies is done by the low-level unpack_trees code, which handles this case. From git help I have a very rough draft that seems to do what I want, exposed through .gitattributes (below). Given that this is something you probably want tightly scoped, does it make sense to expose it anywhere else? This is the first use of gitattributes in the unpack-trees code path. I cannot think offhand of any philosophical reason that should not be OK, but it is something worth considering (i.e., this code path is deep plumbing; are there cases where we would not want to support gitattributes?). Is it accurate to speak of this as exposing merge minimal? I am not 100% sure they are not orthogonal concepts. The tree-diff is about just because two separate changes ended at the same place does not mean they should be merged into the same change. I am actually not sure what XDL_MERGE_MINIMAL entails exactly. Is it only about coalescing overlapping endpoints in the merge? Documentation is sparse. The patch itself doesn't look too bad. It covers the file-level case and the content-level case. Is there additional code needed to handle the directory-level case? That is, if I have a tree that starts at sha1 X, and ends up at sha1 Y in both sides of the merge, do we still descend into it to make the file-level comparisons, or do we optimize that out? diff --git a/ll-merge.c b/ll-merge.c index da59738..2a06ac9 100644 --- a/ll-merge.c +++ b/ll-merge.c @@ -84,7 +84,16 @@ static int ll_xdl_merge(const struct ll_merge_driver *drv_unused, } memset(xmp, 0, sizeof(xmp)); - xmp.level = XDL_MERGE_ZEALOUS; + + struct git_attr_check check; + check.attr = git_attr(merge-minimal); + (void) git_check_attr(path, 1, check); Please void C99 decl-after-statement, as we build on older compilers that do not like it. We also do not typically annotate ignored return values. + if(ATTR_TRUE(check.value)) + xmp.level = XDL_MERGE_MINIMAL; + else + xmp.level = XDL_MERGE_ZEALOUS; ..and indentations should be a single tab. Other than those minor style nits, I do not see anything obviously _wrong_ with the patch, but I am far from an expert in the area. It would need documentation and tests, of course. The next step may be to wrap it up with those things and post it to the list, which will likely get more attention. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] copy.c: make copy_fd preserve meaningful errno
Jeff King p...@peff.net writes: On Fri, Nov 21, 2014 at 09:48:19AM -0800, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: On 11/21/2014 10:14 AM, Michael Haggerty wrote: Couldn't we save ourselves a lot of this save_errno boilerplate by making error() and warning() preserve errno? [...] Never mind; I see that Peff already submitted a patch to this effect. My understanding of the conclusion of those four patches was that only a single updated one is needed, and moving save/restore inside error() did not have to survive. http://article.gmane.org/gmane.comp.version-control.git/259911 Yeah, the callsite I had intended ended up needing to save it across more than just error(). And I think that is probably why we have never done any errno-handling inside error() before (it is certainly not the first time I thought of doing such a thing): real-world cases tend to be a little more complicated. That being said, if this copy() case is one that could benefit, I do not have any problem with picking up (or just reusing the concept of) my 1/4 from that series. It probably does not _hurt_ anything, and if it can help in even a few cases, it may be worth it. Yeah, I agree. My summary was did not have to survive, not had to die. Like you, I do not mind the change as long as other code paths benefit from it. -- 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 merge a b when a == b but neither == o is always a successful merge?
Jeff King p...@peff.net writes: This is the first use of gitattributes in the unpack-trees code path. I cannot think offhand of any philosophical reason that should not be OK, but it is something worth considering (i.e., this code path is deep plumbing; are there cases where we would not want to support gitattributes?). It is not about not want to support, but mroe about not want to be affected (by user preference), and it is a valid concern. ... if I have a tree that starts at sha1 X, and ends up at sha1 Y in both sides of the merge, do we still descend into it to make the file-level comparisons, or do we optimize that out? The code to look at is unpack-trees.c::unpack_callback(); even though it does try to be clever to do that exact optimization when it is used for diff-index --cached, I do not think we do it during a real merge. +struct git_attr_check check; +check.attr = git_attr(merge-minimal); +(void) git_check_attr(path, 1, check); Please void C99 decl-after-statement, as we build on older compilers that do not like it. Also I do not think we want to keep calling git_attr() interning function. All existing uses (well, at least the ones that were written by those who know what they are doing ;-) should be avoiding repeated look-ups, and if we are to use an attribute for this, we should do the same. Do we name our attributes with dashes-in-its-name? I am not asking if dashes are allowed (I know it is), but if that breaks the pattern already established for the core part of the system and makes this new one an oddball. We also do not typically annotate ignored return values. True. +if(ATTR_TRUE(check.value)) + xmp.level = XDL_MERGE_MINIMAL; +else + xmp.level = XDL_MERGE_ZEALOUS; ..and indentations should be a single tab. True, too. Other than those minor style nits, I do not see anything obviously _wrong_ with the patch, but I am far from an expert in the area. I agree that the approach taken here is a sensible way to implement the design, _if_ the design and the problem it tries to solve makes sense. I am not sure about that yet myself, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mergetool/difftool cleanup
David Aguilar dav...@gmail.com writes:
This is a cleanup series to remove the use of the $status
global variable in mergetool/difftool.
This should wait until after the current RC series is
over but figured I'd send it out.
David Aguilar (3):
mergetool--lib: remove use of $status global
difftool--helper: add explicit exit statement
mergetool: simplify conditionals
git-difftool--helper.sh | 2 ++
git-mergetool--lib.sh | 20 +---
git-mergetool.sh| 16 +---
3 files changed, 12 insertions(+), 26 deletions(-)
Looked quite straight-forward from a cursory read.
I tentatively inserted the attached patch before 1/3. If the series
was done with that extra step as preliminary clean-up, I wouldn't
have had to wonder if the hunk at @@ -130,13 was correct.
-- 8 --
From: Junio C Hamano gits...@pobox.com
Date: Fri, 21 Nov 2014 11:17:57 -0800
Subject: [PATCH] mergetool--lib: remove no-op assignment to $status from
setup_user_tool
Even though setup_user_tool assigns the exit status from eval
$merge_tool_cmd to $status, the variable is overwritten by the
function it calls next, check_unchanged, without ever getting looked
at by anybody. And return $status at the end of this function
returns the value check_unchanged assigned to it (which is the same
as the value the function returns). Which makes the assignment a
no-op.
Remove it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-mergetool--lib.sh | 1 -
1 file changed, 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 2b66351..3e06389 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -130,7 +130,6 @@ setup_user_tool () {
then
touch $BACKUP
( eval $merge_tool_cmd )
- status=$?
check_unchanged
else
( eval $merge_tool_cmd )
--
2.2.0-rc2-128-ge2b5e8e
--
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: [L10N] please review a batch l10n update for Git 2.2.0 final
Jiang Xin worldhello@gmail.com writes: 2014-11-21 7:00 GMT+08:00 Junio C Hamano gits...@pobox.com: I've pushed out what should be -rc3 minus l10n changes and try to make sure there will be no N_() and _() changes. Let's do a 2.2-rc3 as the last round of this cycle tomorrow. I've fetched up to your 7ba2ba7 but haven't merged it yet, just in case you will have further updates. Otherwise, 2.2-rc3 will be what is at the tip of 'master' today with 7ba2ba7 merged in. Hi Junio, Please pull the following changes since commit ca0107e279df1465946970113d68b4ee26ffbcc4: Merge branch 'sv/submitting-final-patch' (2014-11-19 13:48:01 -0800) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 7ba2ba7d12163a8f9a9947d7880bd26f2970d4c5: l10n: remove a superfluous translation for push.c (2014-11-20 16:23:43 +0800) Thanks. Done. -- 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: Cannot set the commit-message editor
still don't get it. I run /c/path/to/npp.sh just fine, Its only 'git commit' that is teleporting me to a different world. So there is NO way I can refer to folders outside of my repository in a shell script when it is used in a config param ? I will try setting the core.editor to the value you suggested. On Fri, Nov 21, 2014 at 12:48 PM, Philip Oakley philipoak...@iee.org wrote: From: Fahad Ashfaque fahad...@gmail.com I have downloaded the latest git from git-scm on my windows machine. I am using git on windows, I am having trouble trying to get notepad++ as my commit message editor. I have created a shell script called npp.sh which has the following content /c/Program\ Files\ \(x86\)/Notepad++/notepad++.exe -multiInst -nosession -noPlugin $1 I figured this is how paths are accepted in git-bash Now I configured core.editor this way git config --global core.editor /c/path/to/npp.sh I simply have (from 'git config -l'): core.editor='C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noplugin when I try to commit, using the following command git commit I get the following error $ git commit error: cannot spawn c:/path/to/npp.sh: No such file or directory error: unable to start editor 'c:/dev/tools/cmd/npp.sh' Please supply the message using either -m or -F option. when I run the following command ls c:/ I get the directory for my repository's root, not C drive's root When I run the following command through git-bash /c/path/to/npp.sh It works but when git commit invokes, it does not. Here is more of what I found when 'git commit' launches npp.sh, it changes /c/path/to/npp.sh to c:/path/to/npp.sh c:/ is not the root of my C drive according to git-bash, Correct. The Linux bash is rooted, _usually_, at the base of your personal 'c:/documents and settings' (or whatever on your Windows version), with the MS drives under /c/ and /d/ etc. i.e. a load of virtualisation. use 'pwd -W' to get the true (Windows) path of your current/present working directory. (I had to ask just a few days ago ;-) c:/ is root of my repository because when I run 'ls c:/' I get files from root of my repository. I wouldn't have expected that to play nice (confusion between windows and linux path styles). so may be if 'git commit' does not change /c/path/to/npp.sh to c:/path/to/npp.sh, it would work... Or if git-bash does not mount c:/ to /c/path/to/myrepository and keep it to /c it would work too. Please let me know if you need more info on this I've also copied in the Git user / Git for Human beings list (for reference) which can be useful for Windows based issues. Thanks Fahad -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] repack_without_refs(): convert to string_list
On Fri, Nov 21, 2014 at 10:00 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I don't think that those iterations changed anything substantial that
overlaps with my version, but TBH it's such a pain in the ass working
with patches in email that I don't think I'll go to the effort of
checking for sure unless somebody shows interest in actually using my
version.
Sorry for being grumpy today :-(
Sorry for causing the grumpyness.
I have compared the versions, and they do look pretty similar.
In refs.{c,h} we're just talking about variable names and comments,
that are different.
In remote.c prune_remote however we did have slight differences,
* early exit vs a large body below an if
* your approach seems more elegant to me as you seem to know what you're doing:
for_each_string_list_item(item, states.stale)
string_list_append(refs_to_prune, item-util);
instead of
for (i = 0; i states.stale.nr; i++)
string_list_append(delete_refs, states.stale.items[i].util);
* You do not have a sort_string_list at the end before warn_dangling_symrefs,
but you explained that it is not necessary.
On my continued journey on this mailing list I'll try to follow your
example and write lots of
small easy to review patches, as they are indeed way easier to follow.
However as Junio mentioned, we get other problems having too small changes.
In the review for the [PATCH v3 00/14] ref-transactions-reflog series you said:
I was reviewing this patch series (I left some comments in Gerrit about
the first few patches) when I realized that I'm having trouble
understanding the big picture of where you want to go with this.
Maybe that was just my fault, not having stated the intentions in
the cover letter explicit enough. But having many patches will also not help
on presenting the big picture easily.
Thanks for bearing with me,
Stefan
Is the above meant as a grumpy rant to be ignored, or as a
discussion starter to improve the colaboration to allow people to
work better together instead of stepping on each other's patches?
FWIW, I liked your rationale for many smaller steps.
One small uncomfort in that approach is that it often is not very
obvious by reading log -p master.. alone how well the end result
fits together. Each individual step may make sense, or at least it
may not make it any worse than the original, but until you apply the
whole series and read diff master... in a sitting, it is somewhat
hard to tell where you are going. But this is not risk or bad
thing; just something that may make readers feel uncomfortable---we
are not losing anything by splitting a series into small logical
chunks.
Thanks.
--
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: [RFC 0/4] Fix the Visual Studio 2008 .sln generator
From: Johannes Schindelin johannes.schinde...@gmx.de Hi Philip, On Thu, 20 Nov 2014, Philip Oakley wrote: Are the patches going in the right direction? Yes. Magic. Glad of the confirmation A couple of general comments: - please do not comment out code. Just remove it. It's my debugging style until I get it working ;-0 - the first three commit messages look funny, being indented by 4 spaces... unintentional? I think that was from one of the tools I was using at the time. They'll be tidied and reflowed for the final version(s). Is the processing of the .obj file in engine.pl sensible? Yes, but instead of adding dead code, it would be better to use the comment # ignore. I would also strongly suggest to hard-code the complete file name instead of just the extension. True, I realised that after posting (isnt it always the way). We know exactly which file name we want to ignore, and if there should be another .obj file eventually, it would be wrong to ignore it, too. My concern was more about why a 'make' would produce .obj files (rather than .o files) in the first place. As I understand it we should never see .obj files generated from make with the exception of these ones that are library files implicitly known to MSVC - any thoughts? and the extra care with s/\.o$/.c/ avoiding s/obj/cbj/. Technically, you need to use a group \($\|[ \t]\), but I think that that would be overkill. Does it affect the Qmake capability? (I've no idea) Frankly, neither do I ;-) But since you touched only engine.pl, I would expect Qmake not to be affected at all, right? As I understood the call sequence merry go round, the engine can pull in either function depending on command line options, hence the open question. But like you say, why expect it to be affected, and no-one has mentioned on list for years;-) Is the quoting of filenames correct? (my perl foo is cargo cult!) IANAPME (I am not a Perl Monk either), but it looks good to me. OK. I've also updated the vcbuild/README to mention Msysgit (which will be replaced soon by the newer/better Git-for-windows/SDK (https://github.com/git-for-windows/sdk), but the benefits still apply. The path you used is /msysgit/bin/msvc-build, but the real path would be /bin/msvc-build. Obviously, the patches will need squashing together, To the contrary, I like the current separation of concerns. At the moment the first patch doesn't fully cure the .sln build, but there's no test anyway so bisecting would be problematic. I'm happy to keep them small separate and clean ;-) Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/4] Fix i18n -o option in msvc engine.pl
From: Johannes Schindelin johannes.schinde...@gmx.de
Hi Philip,
On Thu, 20 Nov 2014, Philip Oakley wrote:
The i18n 5e9637c6 introduced an extra '-o' option
into the make file,
I take it you are referring to
https://github.com/git/git/commit/5e9637c6#diff-b67911656ef5d18c4ae36cb6741b7965R2195
Yes, Makefile#L2195 (of the new version)
diff --git a/contrib/buildsystems/engine.pl
b/contrib/buildsystems/engine.pl
index 23da787..9144ea7 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -140,6 +140,18 @@ sub parseMakeOutput
next;
}
+if ($text =~ /^mkdir /) {
+# options to the Portable Object translations in the
line
+# mkdir -p po/... msgfmt ... (eg -o) may be mistaken
for linker options
Maybe better
# the line mkdir ... msgfmt ... contains no linker options
OK will use.
+next;
+}
+
+if ($text =~ /^msgfmt /) {
+# options to the Portable Object translations in the
line
+# mkdir -p po/... msgfmt ... (eg -o) may be mistaken
for linker options
+next;
+}
These two if clauses do the same, maybe call it
if ($test =~ /^(mkdir|msgfmt) /)
That's good, will use.
Ciao,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/4] engine.pl: split the .o and .obj processing
From: Johannes Schindelin johannes.schinde...@gmx.de
Hi Philip,
On Thu, 20 Nov 2014, Philip Oakley wrote:
Commit 4b623d80f7352 added an .obj file (invalidcontinue.obj) which
was not
processed correctly.
The generate engine then mistakenly did a s/.o/.c/ to create a
request
to compile invalidcontinue.cbj.
This is good. However, this:
Split the '/\.(o|obj)$' in engine.pl#L353 into:
} elsif ($part =~ /\.o$/) { # was '/\.(o|obj)$'
push(@objfiles, $part);
} elsif ($part =~ /\.obj$/) { # was '/\.(o|obj)$'
# push(@objfiles, $part); # do nothing
} else {
just repeats what the diff says, so it is unnecessary in the commit
message.
OK.
diff --git a/contrib/buildsystems/engine.pl
b/contrib/buildsystems/engine.pl
index 8e41808..16c3dd5 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -264,7 +264,9 @@ sub handleCompileLine
} elsif ($part =~ /\.(c|cc|cpp)$/) {
$sourcefile = $part;
} else {
-die Unhandled compiler option @ line $lineno: $part;
+print full line: $line\n;
+print A:-Unhandled compiler option @ line $lineno:
$part\n; # die (if !DEBUG)
+#die Unhandled compiler option @ line $lineno: $part;
This needs to be backed out. I agree that it is nice to get going and
to
debug, so I would split it out into its own commit while working on
the
branch, but then drop it before submitting.
I'll probably split this improvement in error reporting (by providing
the full offending line) into a separate patch, on the basis that we
want (Windows) folks to start helping, so let's make the error messages
more useful to those who don't know these scripting languages yet.
@@ -290,14 +292,15 @@ sub handleLibLine
[...]
foreach (@objfiles) {
my $sourcefile = $_;
-$sourcefile =~ s/\.o/.c/;
+$sourcefile =~ s/\.o$/.c/;
Ah, I see from the context that my earlier comment about the
white-space
delimiter was wrong: at this stage, we already have split the list. So
this is groovy.
@@ -343,8 +346,10 @@ sub handleLinkLine
} elsif ($part =~ /\.(a|lib)$/) {
$part =~ s/\.a$/.lib/;
push(@libs, $part);
-} elsif ($part =~ /\.(o|obj)$/) {
+} elsif ($part =~ /\.o$/) { # was '/\.(o|obj)$'
push(@objfiles, $part);
+} elsif ($part =~ /\.obj$/) { # was '/\.(o|obj)$'
+# push(@objfiles, $part); # do nothing
How about the following instead?
+ } elsif ($part eq 'invalidcontinue.obj') {
+ # ignore
} elsif ($part =~ /\.(o|obj)$/) {
Looks good, I'll use that (after deciding whether .obj files should be
expected in a 'make' output anyway)
? After all, this change is really only about handling the newly
introduced invalidcontinue.obj correctly.
Did it ever handle .obj's correctly (rhet) - I dunno.
Ciao,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/4] Improve layout and reference msvc-build script
From: Johannes Schindelin johannes.schinde...@gmx.de Hi Philip, On Thu, 20 Nov 2014, Philip Oakley wrote: [...] +Or, use the msvc-build script; also in /msysgit/bin/msvc-build As I mentioned before, from a Git Bash on Windows, the path is /bin/msvc-build (no /msysgit/). That is quite likely to stay the same with the upcoming Git for Windows SDK, too (once I add the file to the SDK). I was trying to identify the source file (as I see it in my Msysgit install). However it will all need tidying to distinguish what is seen if you have G4W-SDK, rather just installing the new G4W (when ready) By the way, I think we should also start thinking about a Jenkins job to verify that upstream changes such as invalidcontinue.obj do not break the MSVC build. Please let me know if you want to give it a try, I have a Windows Azure instance with a Jenkins instance, sponsored by Microsoft. This is not something I'm familiar with, but it's something I could have a look at. On my list is also the 'git bundle' symref problem, which we've got a solution for that 'just' needs coding, along with thoughts about narrow/sparse checkout/clone/fetch. One of the confusions I have is the distinction between building with the MSVC compiler (cl command line) and building within VS2008, and whether they are different things (i.e. does VS2008 bring extra baggage?). -- Philip Ciao, Johannes -- 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: Cannot set the commit-message editor
From: Fahad Ashfaque fahad...@gmail.com still don't get it. Do check each instance of bash separately. Each can have a different virtual root. I was caught by this just last week on Msysgit (the msys.bat) where that has a different base address to the Git bash version in C:\program files. https://groups.google.com/d/msg/msysgit/prLaAOCF9Ig/l1zRsYfVrqwJ I run /c/path/to/npp.sh just fine, Its only 'git commit' that is teleporting me to a different world. So there is NO way I can refer to folders outside of my repository in a shell script when it is used in a config param ? I will try setting the core.editor to the value you suggested. On Fri, Nov 21, 2014 at 12:48 PM, Philip Oakley philipoak...@iee.org wrote: From: Fahad Ashfaque fahad...@gmail.com I have downloaded the latest git from git-scm on my windows machine. I am using git on windows, I am having trouble trying to get notepad++ as my commit message editor. I have created a shell script called npp.sh which has the following content /c/Program\ Files\ \(x86\)/Notepad++/notepad++.exe -multiInst -nosession -noPlugin $1 I figured this is how paths are accepted in git-bash Now I configured core.editor this way git config --global core.editor /c/path/to/npp.sh I simply have (from 'git config -l'): core.editor='C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noplugin when I try to commit, using the following command git commit I get the following error $ git commit error: cannot spawn c:/path/to/npp.sh: No such file or directory error: unable to start editor 'c:/dev/tools/cmd/npp.sh' Please supply the message using either -m or -F option. when I run the following command ls c:/ I get the directory for my repository's root, not C drive's root When I run the following command through git-bash /c/path/to/npp.sh It works but when git commit invokes, it does not. Here is more of what I found when 'git commit' launches npp.sh, it changes /c/path/to/npp.sh to c:/path/to/npp.sh c:/ is not the root of my C drive according to git-bash, Correct. The Linux bash is rooted, _usually_, at the base of your personal 'c:/documents and settings' (or whatever on your Windows version), with the MS drives under /c/ and /d/ etc. i.e. a load of virtualisation. use 'pwd -W' to get the true (Windows) path of your current/present working directory. (I had to ask just a few days ago ;-) c:/ is root of my repository because when I run 'ls c:/' I get files from root of my repository. I wouldn't have expected that to play nice (confusion between windows and linux path styles). so may be if 'git commit' does not change /c/path/to/npp.sh to c:/path/to/npp.sh, it would work... Or if git-bash does not mount c:/ to /c/path/to/myrepository and keep it to /c it would work too. Please let me know if you need more info on this I've also copied in the Git user / Git for Human beings list (for reference) which can be useful for Windows based issues. Thanks Fahad -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] Properly accept quoted space in filenames
Philip Oakley philipoak...@iee.org writes:
sub handleCompileLine
{
my ($line, $lineno) = @_;
-my @parts = split(' ', $line);
+# my @parts = split(' ', $line);
+my @parts = quotewords('\s+', 0, $line);
Can somebody enlighten me why/if quotewords is preferrable over
shellwords in the context of this patch?
--
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: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?
Dear git developers! Jeff King wrote: On Sun, Nov 16, 2014 at 03:31:10PM +, Patrick Schleizer wrote: How safe are signed git tags? Especially because git uses SHA-1. There is contradictory information around. So if one verifies a git tag (`git tag -v tagname`), then `checksout`s the tag, and checks that `git status` reports no untracked/modified files, without further manually auditing the code, how secure is this actually? Is it only as safe as SHA-1? Yes, it is only as safe as SHA-1 in the sense that you have GPG-signed only a SHA-1 hash. If somebody can find a collision with a hash you have signed, they can substitute the colliding data for the data you signed. Of course, safe as SHA-1 and find a collision are vague. If pre-image attacks are feasible (i.e., given already-published SHA-1, I can find a different input with the same SHA-1), then attacks are trivial. But when people talk about attacks on SHA-1, they are usually referring to finding a collision between two new pieces of data. You can also use that in an attack, but it's much less straightforward (basically, you need to get somebody to sign one of the colliding pieces of data and then replace it with the other). Sounds pretty sad. Isn't this a security issue that should be fixed? Rather than discussing how feasible collisions in SHA-1 are... Attacks on SHA-1 are only getting worse, no? Since the Snowden revelations we know that powerful adversaries that are working on such things and would use such weaknesses to exploit users. Dear git developers, could you please make a long story short? Change to some stronger hash algorithm? (sha256, sha512, or so?) Or provide an option for that? And of course there is the question of getting the colliding data to the victim. Git does collision checks whenever a remote (e.g., from a git fetch) gives us data that we already have. So you could poison new cloners with bad data, but you could not convince a repository with the existing good half of the collision to fetch the evil half. Poison git cloners with bad data is exactly my point here. Because sometimes I am a cloner of my own code - cloning it on a separate machine - then verify it using gpg - but don't check it any further. In such cases, I'd prefer if security wouldn't depend on SHA-1. Cheers, Patrick -- 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: [RFC 2/4] Properly accept quoted space in filenames
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
sub handleCompileLine
{
my ($line, $lineno) = @_;
-my @parts = split(' ', $line);
+# my @parts = split(' ', $line);
+my @parts = quotewords('\s+', 0, $line);
Can somebody enlighten me why/if quotewords is preferrable over
shellwords in the context of this patch?
No - Ignorance is bliss ;-) I think my cargo culting was the result of
some googling for quoting perl variables or some such, which obviously
came up with quotewords - I'm happy to take advice on this one!
quotewords did appear to work though back when I wrote this: 86dcfcf
(Properly accept quoted space in filenames, 2012-05-06)
--
Philip
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RelNotes: Spelling grammar tweaks.
Signed-off-by: Marc Branchaud marcn...@xiplink.com --- Documentation/RelNotes/2.2.0.txt | 102 +++ 1 file changed, 51 insertions(+), 51 deletions(-) diff --git a/Documentation/RelNotes/2.2.0.txt b/Documentation/RelNotes/2.2.0.txt index d4001c5..9d9d5d5 100644 --- a/Documentation/RelNotes/2.2.0.txt +++ b/Documentation/RelNotes/2.2.0.txt @@ -9,20 +9,20 @@ Ports * Building on older MacOS X systems automatically sets the necessary NO_APPLE_COMMON_CRYPTO build-time option. - * The support to build with NO_PTHREADS has been resurrected. + * Building with NO_PTHREADS has been resurrected. - * Compilation options has been updated a bit to support z/OS port - better. + * Compilation options have been updated a bit to better support the + z/OS port. UI, Workflows Features - * git archive learned to filter what gets archived with pathspec. + * git archive learned to filter what gets archived with a pathspec. * git config --edit --global starts from a skeletal per-user configuration file contents, instead of a total blank, when the - user does not already have any. This immediately reduces the - need for a later Have you forgotten setting core.user? and we + user does not already have any global config. This immediately reduces the + need later Have you forgotten to set core.user? messages, and we can add more to the template as we gain more experience. * git stash list -p used to be almost always a no-op because each @@ -33,35 +33,35 @@ UI, Workflows Features * Sometimes users want to report a bug they experience on their repository, but they are not at liberty to share the contents of the repository. fast-export was taught an --anonymize option - to replace blob contents, names of people and paths and log + to replace blob contents, names of people, paths and log messages with bland and simple strings to help them. * git difftool learned an option to stop feeding paths to the diff backend when it exits with a non-zero status. - * git grep allows to paint (or not paint) partial matches on + * git grep learned to paint (or not paint) partial matches on context lines when showing grep -Cnum output in color. - * log --date=iso uses a slight variant of ISO 8601 format that is - made more human readable. A new --date=iso-strict option gives - datetime output that is more strictly conformant. + * log --date=iso uses a slight variant of the ISO 8601 format that is + more human readable. A new --date=iso-strict option gives + datetime output that conforms more strictly. * The logic git prune uses is more resilient against various corner cases. * A broken reimplementation of Git could write an invalid index that - records both stage #0 and higher stage entries for the same path. + records both stage #0 and higher-stage entries for the same path. We now notice and reject such an index, as there is no sensible fallback (we do not know if the broken tool wanted to resolve and - forgot to remove higher stage entries, or if it wanted to unresolve - and forgot to remove the stage#0 entry). + forgot to remove the higher-stage entries, or if it wanted to unresolve + and forgot to remove the stage #0 entry). - * The temporary files git mergetool uses are named to avoid too + * The temporary files git mergetool uses are renamed to avoid too many dots in them (e.g. a temporary file for hello.c used to be named e.g. hello.BASE.4321.c but now uses underscore instead, e.g. hello_BASE_4321.c). - * The temporary files git mergetools uses can be placed in a newly + * The temporary files git mergetool uses can be placed in a newly created temporary directory, instead of the current directory, by setting the mergetool.writeToTemp configuration variable. @@ -73,7 +73,7 @@ UI, Workflows Features to consume their input fully (not following this requirement used to result in intermittent errors in git push). - * The pretty-format specifier %d, which expanded to (tagname) + * The pretty-format specifier %d, which expands to (tagname) for a tagged commit, gained a cousin %D that just gives the tagname without frills. @@ -86,14 +86,14 @@ UI, Workflows Features without having to trust the server. * git interpret-trailers is a new filter to programmatically edit -the tail end of the commit log messages. + the tail end of the commit log messages. * git help everyday shows the Everyday Git in 20 commands or so document, whose contents have been updated to more modern Git practice. - * On the git svn front, work to reduce memory consumption and - to improve handling of mergeinfo progresses. + * On the git svn front, work progresses to reduce memory consumption and + to improve handling of mergeinfo. Performance, Internal Implementation, etc. @@ -106,18 +106,18 @@ Performance, Internal Implementation, etc. *
Re: [RFC 2/4] Properly accept quoted space in filenames
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
sub handleCompileLine
{
my ($line, $lineno) = @_;
-my @parts = split(' ', $line);
+# my @parts = split(' ', $line);
+my @parts = quotewords('\s+', 0, $line);
Can somebody enlighten me why/if quotewords is preferrable over
shellwords in the context of this patch?
No - Ignorance is bliss ;-) I think my cargo culting was the result
of some googling for quoting perl variables or some such, which
obviously came up with quotewords - I'm happy to take advice on this
one!
quotewords did appear to work though back when I wrote this: 86dcfcf
(Properly accept quoted space in filenames, 2012-05-06)
A quick websearch shows me:
http://cpansearch.perl.org/src/CHORNY/Text-ParseWords-3.29/ParseWords.pm
and comparing the implementations of the two, the difference boils
down to just one line to me.
sub shellwords {
my (@lines) = @_;
my @allwords;
foreach my $line (@lines) {
$line =~ s/^\s+//;
my @words = parse_line('\s+', 0, $line);
pop @words if (@words and !defined $words[-1]);
return() unless (@words || !length($line));
push(@allwords, @words);
}
return(@allwords);
}
In quotewords, the call to parse_line uses $keep not hardcoded 0
(which would not make any difference in the context of your patch),
and it assumes parse_line() never returns a singleton undef so the
line pop ... if @words is a list with 'undef' as its sole element
is missing.
Of course, the caller would become smaller and sweeter, i.e.
my @parts = shellwords($line);
I am not familiar with if Perl folks have certain convention to
decide when to use which one, though ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v2.2.0-rc3
A release candidate Git v2.2.0-rc3 is now available for testing at the usual places. I was planning to do the final one but we found and fixed last-minute bugs in the code in -rc2, so this is to doubly make sure the result is fit for the final one, which I am planning to tag mid next week. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.2.0-rc3' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.2 Release Notes (draft) == Updates since v2.1 -- Ports * Building on older MacOS X systems automatically sets the necessary NO_APPLE_COMMON_CRYPTO build-time option. * The support to build with NO_PTHREADS has been resurrected. * Compilation options has been updated a bit to support z/OS port better. UI, Workflows Features * git archive learned to filter what gets archived with pathspec. * git config --edit --global starts from a skeletal per-user configuration file contents, instead of a total blank, when the user does not already have any. This immediately reduces the need for a later Have you forgotten setting core.user? and we can add more to the template as we gain more experience. * git stash list -p used to be almost always a no-op because each stash entry is represented as a merge commit. It learned to show the difference between the base commit version and the working tree version, which is in line with what git stash show gives. * Sometimes users want to report a bug they experience on their repository, but they are not at liberty to share the contents of the repository. fast-export was taught an --anonymize option to replace blob contents, names of people and paths and log messages with bland and simple strings to help them. * git difftool learned an option to stop feeding paths to the diff backend when it exits with a non-zero status. * git grep allows to paint (or not paint) partial matches on context lines when showing grep -Cnum output in color. * log --date=iso uses a slight variant of ISO 8601 format that is made more human readable. A new --date=iso-strict option gives datetime output that is more strictly conformant. * The logic git prune uses is more resilient against various corner cases. * A broken reimplementation of Git could write an invalid index that records both stage #0 and higher stage entries for the same path. We now notice and reject such an index, as there is no sensible fallback (we do not know if the broken tool wanted to resolve and forgot to remove higher stage entries, or if it wanted to unresolve and forgot to remove the stage#0 entry). * The temporary files git mergetool uses are named to avoid too many dots in them (e.g. a temporary file for hello.c used to be named e.g. hello.BASE.4321.c but now uses underscore instead, e.g. hello_BASE_4321.c, to allow us to have multiple variants). * The temporary files git mergetool uses can be placed in a newly created temporary directory, instead of the current directory, by setting the mergetool.writeToTemp configuration variable. * git mergetool understands --tool bc now, as version 4 of BeyondCompare can be driven the same way as its version 3 and it feels awkward to say --tool bc3 to run version 4. * The pre-receive and post-receive hooks are no longer required to consume their input fully (not following this requirement used to result in intermittent errors in git push). * The pretty-format specifier %d, which expanded to (tagname) for a tagged commit, gained a cousin %D that just gives the tagname without frills. * git push learned --signed push, that allows a push (i.e. request to update the refs on the other side to point at a new history, together with the transmission of necessary objects) to be signed, so that it can be verified and audited, using the GPG signature of the person who pushed, that the tips of branches at a public repository really point the commits the pusher wanted to, without having to trust the server. * git interpret-trailers is a new filter to programmatically edit the tail end of the commit log messages, e.g. Signed-off-by:. * git help everyday shows the Everyday Git in 20 commands or so document, whose contents have been updated to match more modern Git practice. * On the git svn front, work to reduce memory consumption and to improve handling of mergeinfo progresses. Performance, Internal Implementation, Development Support etc. * The API to manipulate the refs has
Re: [PATCH 0/3] mergetool/difftool cleanup
On Fri, Nov 21, 2014 at 11:28:03AM -0800, Junio C Hamano wrote:
David Aguilar dav...@gmail.com writes:
This is a cleanup series to remove the use of the $status
global variable in mergetool/difftool.
This should wait until after the current RC series is
over but figured I'd send it out.
David Aguilar (3):
mergetool--lib: remove use of $status global
difftool--helper: add explicit exit statement
mergetool: simplify conditionals
git-difftool--helper.sh | 2 ++
git-mergetool--lib.sh | 20 +---
git-mergetool.sh| 16 +---
3 files changed, 12 insertions(+), 26 deletions(-)
Looked quite straight-forward from a cursory read.
I tentatively inserted the attached patch before 1/3. If the series
was done with that extra step as preliminary clean-up, I wouldn't
have had to wonder if the hunk at @@ -130,13 was correct.
That makes a lot of sense, please do insert this patch before
1/3 (actually 1/4 with the additional patch I sent after the
initial submission).
Thanks,
David
-- 8 --
From: Junio C Hamano gits...@pobox.com
Date: Fri, 21 Nov 2014 11:17:57 -0800
Subject: [PATCH] mergetool--lib: remove no-op assignment to $status from
setup_user_tool
Even though setup_user_tool assigns the exit status from eval
$merge_tool_cmd to $status, the variable is overwritten by the
function it calls next, check_unchanged, without ever getting looked
at by anybody. And return $status at the end of this function
returns the value check_unchanged assigned to it (which is the same
as the value the function returns). Which makes the assignment a
no-op.
Remove it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-mergetool--lib.sh | 1 -
1 file changed, 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 2b66351..3e06389 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -130,7 +130,6 @@ setup_user_tool () {
then
touch $BACKUP
( eval $merge_tool_cmd )
- status=$?
check_unchanged
else
( eval $merge_tool_cmd )
--
2.2.0-rc2-128-ge2b5e8e
--
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: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?
-Original Message- From: Patrick Schleizer Sent: Friday, November 21, 2014 18:01 Dear git developers! Jeff King wrote: On Sun, Nov 16, 2014 at 03:31:10PM +, Patrick Schleizer wrote: How safe are signed git tags? Especially because git uses SHA-1. There is contradictory information around. So if one verifies a git tag (`git tag -v tagname`), then `checksout`s the tag, and checks that `git status` reports no untracked/modified files, without further manually auditing the code, how secure is this actually? Is it only as safe as SHA-1? Yes, it is only as safe as SHA-1 in the sense that you have GPG-signed only a SHA-1 hash. If somebody can find a collision with a hash you have signed, they can substitute the colliding data for the data you signed. The whole issue is a lot better than this makes it sound. Yes it is just a SHA1 hash, but it is a hash of a structured data format. You have very observable parts of that well structured data providede to the hash. The commit message, the directory contents, and lastly the files themselves. For a collision to occur, the commit message would have to likely have garbage in the message of a large nature. To generate a colision by commited file contents is unlikely because the file contents is reduced to a hash in the directory structure, which is in turn reduced to a hash in a commit structure. This would be noticed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
From: Ingars Holsts
Good afternoon http://www.juliemazziotta.com/wasnt.php?doesnt=60mqk35wyxzgc ingarshol...@yahoo.no Sent from my iPhone -- 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
