[ANNOUNCE] Git v1.7.11.7
A maintenance release Git v1.7.11.7 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 30c7aafaa31002ca52bc45dbd0908e63b00015dd git-1.7.11.7.tar.gz bdcd5009498bc961757915dae30f5fefd6435c59 git-htmldocs-1.7.11.7.tar.gz 9fb4bb051822168e41424524a4a325207f308507 git-manpages-1.7.11.7.tar.gz Also the following public repositories all have a copy of the v1.7.11.7 tag and the maint-1.7.11 branch that the tag points at: 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 v1.7.11.7 Release Notes === Fixes since v1.7.11.6 - * The synopsis said "checkout [-B branch]" to make it clear the branch name is a parameter to the option, but the heading for the option description was "-B::", not "-B branch::", making the documentation misleading. * Git ships with a fall-back regexp implementation for platforms with buggy regexp library, but it was easy for people to keep using their platform regexp. A new test has been added to check this. * "git apply -p0" did not parse pathnames on "diff --git" line correctly. This caused patches that had pathnames in no other places to be mistakenly rejected (most notably, binary patch that does not rename nor change mode). Textual patches, renames or mode changes have preimage and postimage pathnames in different places in a form that can be parsed unambiguously and did not suffer from this problem. * After "gitk" showed the contents of a tag, neither "Reread references" nor "Reload" did not update what is shown as the contents of it, when the user overwrote the tag with "git tag -f". * "git for-each-ref" did not currectly support more than one --sort option. * "git log .." errored out saying it is both rev range and a path when there is no disambiguating "--" is on the command line. Update the command line parser to interpret ".." as a path in such a case. * Pushing to smart HTTP server with recent Git fails without having the username in the URL to force authentication, if the server is configured to allow GET anonymously, while requiring authentication for POST. * "git show --format='%ci'" did not give timestamp correctly for commits created without human readable name on "committer" line. (merge e27ddb6 jc/maint-ident-missing-human-name later to maint). * "git show --quiet" ought to be a synonym for "git show -s", but wasn't. -- 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: Please pull git-l10n updates for git v1.7.12-146-g16d26
On Sat, Sep 15, 2012 at 8:34 AM, Jiang Xin wrote: > 2012/9/14 Nguyen Thai Ngoc Duy : >> (Dropping translators as they probably are not interested in this) >> >> I saw a gnu project does this (I don't remember what project). If we >> update .po* files with --no-location, we can avoid a lot of diff >> noises due to line number changes. A typical translator does not care >> about these lines anyway. Those who do can easily search the string in >> source files without them. > > I believe some translators need these location infomation to find the > context. Unless you are also a git developer, I doubt if sha1_file.c makes sense to any translators. In my 8 years of being translator/programmer to open source world, I rarely look at those lines (though I admit I do). A slightly modified suggestion is just drop line number, not the file name, but xgettext does not support that, unfortunately. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
A huge update of git.pot is coming with 825 new, 24 removed messages
Dear l10n team members, New "git.pot" is generated from v1.7.12-437-g1084f in the master branch. l10n: Update git.pot (825 new, 24 removed messages) Generate po/git.pot from v1.7.12-437-g1084f with these i18n update(s): * i18n: mark more index-pack strings for translation * i18n: write-tree: mark parseopt strings for translation * i18n: verify-tag: mark parseopt strings for translation * i18n: verify-pack: mark parseopt strings for translation * i18n: update-server-info: mark parseopt strings for translation * i18n: update-ref: mark parseopt strings for translation * i18n: update-index: mark parseopt strings for translation * i18n: tag: mark parseopt strings for translation * i18n: symbolic-ref: mark parseopt strings for translation * i18n: show-ref: mark parseopt strings for translation * i18n: show-branch: mark parseopt strings for translation * i18n: shortlog: mark parseopt strings for translation * i18n: rm: mark parseopt strings for translation * i18n: revert, cherry-pick: mark parseopt strings for translation * i18n: rev-parse: mark parseopt strings for translation * i18n: reset: mark parseopt strings for translation * i18n: rerere: mark parseopt strings for translation * i18n: status: mark parseopt strings for translation * i18n: replace: mark parseopt strings for translation * i18n: remote: mark parseopt strings for translation * i18n: read-tree: mark parseopt strings for translation * i18n: push: mark parseopt strings for translation * i18n: prune: mark parseopt strings for translation * i18n: prune-packed: mark parseopt strings for translation * i18n: pack-refs: mark parseopt strings for translation * i18n: pack-objects: mark parseopt strings for translation * i18n: notes: mark parseopt strings for translation * i18n: name-rev: mark parseopt strings for translation * i18n: mv: mark parseopt strings for translation * i18n: mktree: mark parseopt strings for translation * i18n: merge: mark parseopt strings for translation * i18n: merge-file: mark parseopt strings for translation * i18n: merge-base: mark parseopt strings for translation * i18n: ls-tree: mark parseopt strings for translation * i18n: ls-files: mark parseopt strings for translation * i18n: log: mark parseopt strings for translation * i18n: init-db: mark parseopt strings for translation * i18n: help: mark parseopt strings for translation * i18n: hash-object: mark parseopt strings for translation * i18n: grep: mark parseopt strings for translation * i18n: gc: mark parseopt strings for translation * i18n: fsck: mark parseopt strings for translation * i18n: format-patch: mark parseopt strings for translation * i18n: for-each-ref: mark parseopt strings for translation * i18n: fmt-merge-msg: mark parseopt strings for translation * i18n: fetch: mark parseopt strings for translation * i18n: fast-export: mark parseopt strings for translation * i18n: describe: mark parseopt strings for translation * i18n: config: mark parseopt strings for translation * i18n: count-objects: mark parseopt strings for translation * i18n: commit: mark parseopt strings for translation * i18n: column: mark parseopt strings for translation * i18n: clone: mark parseopt strings for translation * i18n: clean: mark parseopt strings for translation * i18n: cherry: mark parseopt strings for translation * i18n: checkout: mark parseopt strings for translation * i18n: checkout-index: mark parseopt strings for translation * i18n: check-attr: mark parseopt strings for translation * i18n: cat-file: mark parseopt strings for translation * i18n: branch: mark parseopt strings for translation * i18n: blame: mark parseopt strings for translation * i18n: add: mark parseopt strings for translation * i18n: bisect--helper: mark parseopt strings for translation * i18n: archive: mark parseopt strings for translation * i18n: mark "style" in OPT_COLUMN() for translation Signed-off-by: Jiang Xin It's time for a new round of translation. * Fetch new commits from git://github.com/git-l10n/git-po * Update your "XX.po" according to the new "git.pot" file. * Start your translation and review your commits inside your l10n team. * Send a pull request to git-l10n/git-po on GitHub. -- 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
Re: [PATCH] Revert diffstat back to English
On Fri, Sep 14, 2012 at 11:54 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Nguyễn Thái Ngọc Duy writes: >> >>> This reverts the i18n part of 7f81463 (Use correct grammar in diffstat >>> summary line - 2012-02-01) but still keeps the grammar correctness for >>> English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on >>> diffstat - 2012-08-27). The result is diffstat always in English >>> for all commands. >>> >>> This helps stop users from accidentally sending localized >>> format-patch'd patches. >>> >>> Signed-off-by: Nguyễn Thái Ngọc Duy > > Why am I getting this from t3300? > > --- expected2012-09-14 16:43:09.0 + > +++ current 2012-09-14 16:43:09.0 + > @@ -1,2 +1,2 @@ > "tabs\t,\" (dq) and spaces" > - 1 file changed, 0 insertions(+), 0 deletions(-) > + 1 files changed, 0 insertion(+), 0 deletion(-) > > Ah, your rewrite of Q_() is wrong. Will squash the attached in > before queueing this for maint. Arghhh I found that and fixed it, but probably sent an old version. Thanks. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull git-l10n updates for git v1.7.12-146-g16d26
2012/9/14 Nguyen Thai Ngoc Duy : > (Dropping translators as they probably are not interested in this) > > I saw a gnu project does this (I don't remember what project). If we > update .po* files with --no-location, we can avoid a lot of diff > noises due to line number changes. A typical translator does not care > about these lines anyway. Those who do can easily search the string in > source files without them. I believe some translators need these location infomation to find the context. In order to squelch noise, users can: 1. Define a new diff driver, such as: $ git config --global diff.podiff.textconv "sed -e '/^#/ d'" 2. Add two lines in .git/info/attributes to use this driver for po/pot files: *.po diff=podiff *.pot diff=podiff -- 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] git-gui: Fix semi-working shortcuts for unstage and revert
From: Vitaly _Vi Shukela
Make Ctrl+U for unstaging and Ctrl+J for reverting selection behave
more like Ctrl+T for adding.
They were working only when one area was focused (diff or commit message),
now they should work everywhere.
Signed-off-by: Vitaly _Vi Shukela
---
Sending the patch the third time (haven't got any replies to previous two
attempts).
git-gui/git-gui.sh |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index ba4e5c1..6618016 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -3710,6 +3710,8 @@ bind $ui_diff <$M1B-Key-v> {break}
bind $ui_diff <$M1B-Key-V> {break}
bind $ui_diff <$M1B-Key-a> {%W tag add sel 0.0 end;break}
bind $ui_diff <$M1B-Key-A> {%W tag add sel 0.0 end;break}
+bind $ui_diff <$M1B-Key-j> {do_revert_selection;break}
+bind $ui_diff <$M1B-Key-J> {do_revert_selection;break}
bind $ui_diff {catch {%W yview scroll -1 units};break}
bind $ui_diff{catch {%W yview scroll 1 units};break}
bind $ui_diff{catch {%W xview scroll -1 units};break}
@@ -3742,6 +3744,8 @@ bind . <$M1B-Key-s> do_signoff
bind . <$M1B-Key-S> do_signoff
bind . <$M1B-Key-t> do_add_selection
bind . <$M1B-Key-T> do_add_selection
+bind . <$M1B-Key-u> do_unstage_selection
+bind . <$M1B-Key-U> do_unstage_selection
bind . <$M1B-Key-j> do_revert_selection
bind . <$M1B-Key-J> do_revert_selection
bind . <$M1B-Key-i> do_add_all
--
1.7.8.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Junio C Hamano writes:
> Elia Pinto writes:
>
>> Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
>> include a malloc() implementation which is tunable via environment
>> variables. When MALLOC_CHECK_ is set, a special (less efficient)
>> implementation is used which is designed to be tolerant against
>> simple errors, such as double calls of free() with the same argument,
>> or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_
>> is set to 3, a diagnostic message is printed on stderr
>> and the program is aborted.
>> ...
>> Signed-off-by: Elia Pinto
>> ---
>> This the third reroll of the original patch.
>
> Well written. I have one suggestion and a question, though.
After looking at it a bit more, there are a few more things I would
suggest, in the form of an squashable patch on top.
Points to note:
- When test-lib.sh is used from perf-lib, we would not want to be
affected with MALLOC_CHECK_; we would want to run as vanilla as
possible in that case.
- We are interested in checking "git" and whatever we test using
the test harness, i.e. what comes inside test_expect_success.
Setting MALLOC_CHECK_ at the beginning will cover a lot more than
what we want to test.
- That "165" thing I mentioned earlier.
- Update the "expr" expression to make sure the --valgrind we catch
is indeed an option, not a substring of something else. Also
there is no need to capture the substring.
t/perf/perf-lib.sh | 1 +
t/test-lib.sh | 26 --
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git i/t/perf/perf-lib.sh w/t/perf/perf-lib.sh
index a1361e5..1d0bb9d 100644
--- i/t/perf/perf-lib.sh
+++ w/t/perf/perf-lib.sh
@@ -42,6 +42,7 @@ else
fi
TEST_NO_CREATE_REPO=t
+TEST_NO_MALLOC_=t
. ../test-lib.sh
diff --git i/t/test-lib.sh w/t/test-lib.sh
index b0c0c84..aad4606 100644
--- i/t/test-lib.sh
+++ w/t/test-lib.sh
@@ -95,12 +95,24 @@ export EDITOR
# Add libc MALLOC and MALLOC_PERTURB test
# only if we are not executing the test with valgrind
-expr "$GIT_TEST_OPTS" : ".*\(--valgrind\)" >/dev/null || {
- MALLOC_CHECK_=3
- export MALLOC_CHECK_
- MALLOC_PERTURB_="$( expr \( $$ % 255 \) + 1)"
- export MALLOC_PERTURB_
-}
+if expr " $GIT_TEST_OPTS " : ".* --valgrind " >/dev/null ||
+ test -n "TEST_NO_MALLOC_"
+then
+ setup_malloc_check () {
+ : nothing
+ }
+ teardown_malloc_check () {
+ : nothing
+ }
+else
+ setup_malloc_check () {
+ MALLOC_CHECK_=3 MALLOC_PERTURB_=165
+ export MALLOC_CHECK_ MALLOC_PERTURB_
+ }
+ teardown_malloc_check () {
+ unset MALLOC_CHECK_ MALLOC_PERTURB_
+ }
+fi
# Protect ourselves from common misconfiguration to export
# CDPATH into the environment
@@ -311,7 +323,9 @@ test_run_ () {
if test -z "$immediate" || test $eval_ret = 0 || test -n
"$expecting_failure"
then
+ setup_malloc_check
test_eval_ "$test_cleanup"
+ teardown_malloc_check
fi
if test "$verbose" = "t" && test -n "$HARNESS_ACTIVE"
then
--
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 stash data loss
Jeff King writes: >> > Hrm. The problem is that after creating the stash, we then run "git >> > reset --hard" to drop the changes that we just stashed. But that is not >> > always accurate. It will not usually touch untracked files, but it might >> > if they have D/F conflicts with tracked files. So we need to replace >> > that "git reset --hard" with some safer command that will notice we are >> > about to overwrite untracked files. But I am not sure what that command >> > would be. >> >> Is this something we still want to keep track of? > > Yeah, I think it is worth fixing. It's a somewhat rare case, but data > loss is bad. I was hoping you would respond with "...and here is the > magical incantation of git commands to make the working directory look > like we want". I couldn't come up with one. We may need a new option to > reset or read-tree. ls-files has an ancient option to show the files "killed"; perhaps that is the closest thing to what you are looking for. -- 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: [PATCHv3] clone: fix refspec on "--single-branch" option
Ralf Thielow writes:
> + if (option_mirror || !option_bare) {
> + strbuf_reset(&value);
> + if (option_single_branch) {
> + if (option_branch)
> + strbuf_addf(&value, "+%s%s:%s%s",
> + src_ref_prefix, option_branch,
> + branch_top.buf, option_branch);
> + else if (remote_head_points_at)
> + strbuf_addf(&value, "+%s:%s%s",
> + remote_head_points_at->name,
> branch_top.buf,
> +
> skip_prefix(remote_head_points_at->name, "refs/heads/"));
We have already set "remote.origin.url" to this repository, so the
next "git fetch" would simply fetch from "HEAD" per default.
Perhaps worth commenting that here?
Other than that, looks good. Perhaps we would want a test or two,
too?
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: Using Format/export-subst Howto.
Junio C Hamano writes: > Michael J Gruber writes: > >> you need to "rm file && git checkout file"). If the user has to update >> $Id$ to match the current sha1 >> (by remembering to do a more forceful checkout than checkout -f) then >> one half of that feature is useless. > > As if there is any value in "$Id$" _feature_. It's a checkbox item, > nothing more ;-). Having said that, I think you could do something along this line (I am thinking aloud, so there may be leaps in the logic below). * Introduce a new on-disk flag in the index. Call it X. After entry.c:write_entry() writes it out to the working tree, this flag is cleared. And this codepath is the only place that clears this flag. * When applying a clean filter (from here on, everything that breaks byte-for-byte identity between the copy on the working tree and the contents that is hashed and stored in the object store are considered "clean filter", including CRLF->LF and ident), internally apply the corresponding smudge filter to the cleaned result and compare it with the original input we obtained from the working tree. If they differ, flip the X bit on for the path in the index. * When "checkout" and any potential callers of write_entry() decide whether it is worth calling write_entry() [*1*], consider any path with the X bit on as "dirty" and call write_entry(). You have to be very careful when designing the third point, though. There will now be two kinds of "the working tree file is different from the version registerd in the index" once you do the above. Different only because of "clean->smudge" roundtrip comparison, and different because it does have a real local modification. The former must be considered "no local modification" for the purpose of merges and branch switching (otherwise you will get "cannot merge, you have local modifications" error). [Footnote] *1* This currently is done primarily with ie_match_stat(), that essentially is "Does the result of applying 'clean' to the working tree contents match what is registered to the index? Do not bother doing this check over and over again once you checked this until the file in the working tree is modified again". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] test-generation: compute generation numbers and clock skews
main() is missing a return here: test-generation.c:105:1: warning: control reaches end of non-void function [-Wreturn-type] -- 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 svn: Only follow first parents when populating svn:mergeinfo properties
I'm awaiting Sam's comment on this patch.
Avishay Lavie wrote:
> Subject: [PATCH] git svn: Only follow first parents when populating
> svn:mergeinfo
> properties.
>
> When svn.pushmergeinfo is set, git-svn tries to correctly populate mergeinfo
> properties when encountering a merge commit. It does so by first aggregating
> the mergeinfo property of the merged parent into the target, and then
> adding to it the SVN revision number of any commit reachable from the
> merged parent but not from the first (target) parent.
>
> If a third branch was merged into the merged parent (e.g. X was merged into Y
> and Y was then merged into Z), its revisions will be listed twice --
> once as part
> of aggregating Y's mergeinfo property into Z's, and once more when walking
> the tree and finding X's commits reachable from Y's tip. While the first
> listing
> correctly lists those revisions as merged from X, the second listing
> will list them
> as merged from Y, creating incorrect mergeinfo properties that later cause
> unnecessary lookups and warnings when git-svn-fetching.
>
> Adding '--first-parent' to the rev-list command fixes this by only walking the
> part of the tree that's directly included in the merged branch (Y) and not any
> branches merged into it (X).
>
> Signed-off-by: Avishay Lavie
> ---
> git-svn.perl |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 828b8f0..f69a4d6 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -728,7 +728,7 @@ sub populate_merge_info {
>
> next if $parent eq $parents[0]; # Skip first parent
> # Add new changes being placed in tree by merge
> - my @cmd = (qw/rev-list --reverse/,
> + my @cmd = (qw/rev-list --first-parent --reverse/,
> $parent, qw/--not/);
> foreach my $par (@parents) {
> unless ($par eq $parent) {
> --
Your patch seems badly whitespace mangled. Fortunately it's a small
change and I can fix it by hand.
--
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] Make git-svn branch patterns match complete URL
Junio C Hamano wrote: > Any comment from "git svn" stakeholders on this one? Looks good to me. Signed-off-by: Eric Wong Pushed to master of git://bogomips.org/git-svn.git (commit 059058765ea2b0abd88001ea1f0f866daf7d0e4c) Ammon Riley (1): Make git-svn branch patterns match complete URL Robert Luberda (1): t9164: Add missing quotes in test Steven Walter (2): git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tip git-svn.perl: keep processing all commits in parents_exclude Will followup on some other pending patches soon... -- 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: Using Format/export-subst Howto.
Michael J Gruber writes: > you need to "rm file && git checkout file"). If the user has to update > $Id$ to match the current sha1 > (by remembering to do a more forceful checkout than checkout -f) then > one half of that feature is useless. As if there is any value in "$Id$" _feature_. It's a checkbox item, nothing more ;-). -- 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
[PATCHv3] clone: fix refspec on "--single-branch" option
After a repo was cloned with the "--single-branch"
option, the configured refspec looks like
"+refs/heads/*:refs/remotes/origin/*".
After fetching from this repo again, it'll receive
all refs instead of just the ref from the single
branch. Fixing this by configure exactly the ref
of the branch the user specified in the "git clone"
command.
Signed-off-by: Ralf Thielow
---
> As refspec maps names that appear on the source side to names that
> appear on the destination side, and for fetch, the "soruce side"
> is the remote, using "our_head_points_at" on the source side makes
> it look very fishy (even though it may be a name derived from
> remote_head_points_at and has the correct and appropriate value).
>
> "prettify" also is very questionable. It is meant to strip commonly
> known prefix to make it easier to read by humans, and we can change
> its result based solely on aesthetics in the future. It is not
> suitable for coming up with a value for configuration in the longer
> term.
>
Thanks. I've fixed.
> Can we make the part you moved de-dented a bit, perhaps by making it
> into a small helper function or something? It is extremely hard to
> read with overly looong lines.
>
Would be nice but the list of arguments will become too long.
I did a bit of reformating and think it now looks a bit nicer.
builtin/clone.c | 43 +--
1 Datei geändert, 29 Zeilen hinzugefügt(+), 14 Zeilen entfernt(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 5e8f3ba..06e3d3a 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -755,20 +755,6 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
}
strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
-
- if (option_mirror || !option_bare) {
- /* Configure the remote */
- strbuf_addf(&key, "remote.%s.fetch", option_origin);
- git_config_set_multivar(key.buf, value.buf, "^$", 0);
- strbuf_reset(&key);
-
- if (option_mirror) {
- strbuf_addf(&key, "remote.%s.mirror", option_origin);
- git_config_set(key.buf, "true");
- strbuf_reset(&key);
- }
- }
-
strbuf_addf(&key, "remote.%s.url", option_origin);
git_config_set(key.buf, repo);
strbuf_reset(&key);
@@ -853,6 +839,35 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
"refs/heads/master");
}
+ if (option_mirror || !option_bare) {
+ strbuf_reset(&value);
+ if (option_single_branch) {
+ if (option_branch)
+ strbuf_addf(&value, "+%s%s:%s%s",
+ src_ref_prefix, option_branch,
+ branch_top.buf, option_branch);
+ else if (remote_head_points_at)
+ strbuf_addf(&value, "+%s:%s%s",
+ remote_head_points_at->name,
branch_top.buf,
+
skip_prefix(remote_head_points_at->name, "refs/heads/"));
+ } else {
+ strbuf_addf(&value, "+%s*:%s*", src_ref_prefix,
branch_top.buf);
+ }
+ /* Configure the remote */
+ if (value.len) {
+ strbuf_reset(&key);
+ strbuf_addf(&key, "remote.%s.fetch", option_origin);
+ git_config_set_multivar(key.buf, value.buf, "^$", 0);
+ strbuf_reset(&key);
+
+ if (option_mirror) {
+ strbuf_addf(&key, "remote.%s.mirror",
option_origin);
+ git_config_set(key.buf, "true");
+ strbuf_reset(&key);
+ }
+ }
+ }
+
if (is_local)
clone_local(path, git_dir);
else if (refs && complete_refs_before_fetch)
--
1.7.12.396.g3cff853.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: Using Format/export-subst Howto.
On Fri, Sep 14, 2012, at 05:39 PM, Johannes Sixt wrote: > Am 9/14/2012 17:27, schrieb Mestnik, Michael J - Eagan, MN - Contractor: > > > >> -Original Message- From: Johannes Sixt > >> If EOL conversion or a clean filter was applied during 'git add > >> file', is the version in the worktree suddenly wrong? Of course, > >> not. > >> > >> I would place $Id$ treatment in the same ball park and declare it as > >> a mistake of the editor that it did not remove the now "wrong" SHA1 > >> from $Id:$. > > > > I think the difference here is that git does not *currently change the > > OS's LEF. In this case each commit alters the Id and git is the one > > altering the Id. > > Maybe you misunderstood $Id$? The value you get there is the blob's SHA1, > not the commit's. That is, it does not change on every commit, but only > when the file changes. > > You are right that the value itself is something that is dictated by > git's > database model, but the change logically happens when the editor modifies > the file. Exactly, but the problem is that neither $Id$ nor $Id: deadbeef$ in the work-tree copy of the file are updated with $Id: abacbeef$ after the file's content has changed and has been committed, i.e. after the blob's sha1 has changed. What's worse, even a "git checkout file" does not correct this (because git sees that there's no change to the file compared to the index), you need to "rm file && git checkout file"). If the user has to update $Id$ to match the current sha1 (by remembering to do a more forceful checkout than checkout -f) then one half of that feature is useless. > (My contribution to this thread should be regarded as food for thought. > Personally, I don't mind whether or not and when $Id$ is updated.) > > -- Hannes I think at least we should do a commit.renormalize akin to merge.renormalize if we can't do more for hysterical raisins. But maybe the behavior even has changed during some stat/lstat related optimizations. I'll check next week if nobody beats me to it. Cheers, 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
Re: [PATCH] Add diff.context option to specify default context
Jeff Muizelaar writes: > This adds a diff.context config option to allow specifying > the number of lines of context. This is similar to Mercurial's > 'unified' option. Random thoughts. * Please refer to Documentation/SubmittingPatches. Saving your message in a mbox and applying it would produce this crap: commit ba4c972eacb91058f1317dbcd4ff77b471fa938e Author: Jeff Muizelaar Date: Fri Sep 14 14:16:03 2012 -0400 Add diff.context option to specify default context This adds a diff.context config option to allow specifying the number of lines of context. This is similar to Mercurial's 'unified' option. commit 1bd81c75de6824c39852bc8516acd0733737ed83 Author: Jeff Muizelaar Date: Fri Sep 14 13:55:02 2012 -0400 [PATCH] Add diff.context option to specify default context This adds a diff.context config option to allow specifying the number of lines of context. This is similar to Mercurial's 'unified' option. which is not acceptable. * Sign-off your patch. * Citing similaritly to options in other systems does not add much value for people who read the proposed log message. In this case, I think the first sentence is written clearly enough that it is sufficient without such clarification. If anything, it should instead say: diff: diff.context configuration gives default to -U Introduce a configuration variable diff.context that tells Porcelain commands to use a non-default number of context lines instead of 3 (the default). With this variable, users do not have to keep repeating "git log -U8" from the command line; instead, it becomes sufficient to say "git config diff.context 8" just once. or something like that to make it clear that it is related to our -U option. * That relationship with the -U option may worth mentioning in the documentation, not just in the log message. * The configuration is read only in diff_ui_config and not in the lower-level diff_config. What the patch does is the right thing. It however needs to be documented in the patch to diff-config.txt that it affects only the Porcelain commands, and does not break plumbing commands. * Tests? Minimally, the cases you may want to check are: - What happens with various values set to this variable, and does the code properly diagnose errors? [diff] context ;# boolean? context = no context = 0 context = -1 context = 8 - What happens when the variable is set and the command line gives a different value with -U? git config diff.context 8 git log -U4 -1 - Does it really keep plumbing intact? git config diff.context 8 git diff-files -p 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: [PATCH/RFC] remote-helper: allow fetch to discover sha1 later
On Thu, Sep 13, 2012 at 11:10:26PM -0700, Junio C Hamano wrote: > I do not think it is a good idea to allow such a helper to claim that > it supports "fetch" capability, for at least two reasons: > > * Being able to "list" is essential for "fetch" based helpers. >think, far from "arbitrary". >... Oh, I don't mean to change the semantics of the list command at all. What I thought seemed arbitrary was limiting the *fetch* command to refs with pre-known sha1s. Any list-time optimization in place or possible for such refs wouldn't be affected. (In light of this, specifying a new sha1 for a ref which already had one in the list should probably be an error rather than a warning. I'll update this in the next version and make it clear that a "ref" message must only be issued for refs reported without a sha1.) > * Existing versions of "git" that can drive remote helpers that >claim to have "fetch" capability are not prepared to accept an >unknown "refs" protocol message from the helper, so a helper >written for your new semantics of "fetch" capability will not >work with them. >... I see. I didn't realize that new helper + old Git client is a supported combination. Still, hear me out. 1. A new helper must only send a "ref" message when git asks for a ref without a known sha1. 2. Asking for a ref without a known sha1 is unsupported, according to git-remote-helpers.txt: "Only objects which were reported in the ref list with a sha1 may be fetched [with fetch]." 3. Furthermore, asking for a ref without a known sha1 *already* breaks in existing versions of git with current handlers: $ git fetch testfetch::../git1 foo fatal: bad object error: testfetch::../git1 did not send all necessary objects Compare - existing version of git, with a new handler: $ git fetch testref::../git1 foo warning: testref unexpectedly said: 'ref 0f31 refs/heads/foo' fatal: bad object error: testref::../git1 did not send all necessary objects So the proposed change doesn't break anything that isn't already broken. :) That said, if you're still not sold, a new capability is fine. Though I think it can be done without it, I'm certainly not opposed to adding one. -- 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: Suggestions for "What's cooking"
From: "Junio C Hamano" Sent: Friday, September 14, 2012 5:47 AM Junio C Hamano writes: I've played with both and have prepared patches to Reintegrate and cook (both in the 'todo' branch). Will play with the changes a bit more and then decide. So here is how tonight's "What's cooking" may look like with extra indentation and blank lines. The tools that read this file to help my workflow have been minimally adjusted. I am hoping that the updates to them I made were enough to make the format tweak not to negatively affect me, and so far things are going smoothly, but I may find some corner cases later. Knock wood... -- >8 -- +1. It looks good even when printed with a proportional width font. -- 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] clone: fix refspec on "--single-branch" option
Ralf Thielow writes: > + else if (remote_head_points_at) > + strbuf_addf(&value, "+%s:%s%s", > our_head_points_at->name, > + > branch_top.buf, prettify_refname(remote_head_points_at->name)); As refspec maps names that appear on the source side to names that appear on the destination side, and for fetch, the "soruce side" is the remote, using "our_head_points_at" on the source side makes it look very fishy (even though it may be a name derived from remote_head_points_at and has the correct and appropriate value). "prettify" also is very questionable. It is meant to strip commonly known prefix to make it easier to read by humans, and we can change its result based solely on aesthetics in the future. It is not suitable for coming up with a value for configuration in the longer term. Can we make the part you moved de-dented a bit, perhaps by making it into a small helper function or something? It is extremely hard to read with overly looong lines. -- 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: [msysGit] Re: [PATCH/RFC] test-lib: add support for colors without tput
Am 14.09.2012 20:11, schrieb Erik Faye-Lund: > On Fri, Sep 14, 2012 at 7:28 PM, Johannes Sixt wrote: >> printf '\033[0;3%sm' "$2" ;; > > Is there a reason for %s rather than %d? It seem it only takes > integers,.. No reason. I just mechanically converted your original expression. But there is no reason for my conversion, either, if it can be more or less guaranteed that no arbitrary strings are passed in $2. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: fix refspec on "--single-branch" option
Junio C Hamano writes:
> Alternatively, if you can move the logic to set up this
> configuration further down so that it happens after we talked to the
> other side and figured out remote_head_points_at, you could instead
> set it up to keep a single remote tracking branch.
>
> Even if you did so, guess_remote_head() may not find any branch when
> the other repository's HEAD is detached, so you would need to decide
> what to do in such a case, and "fetch and integrate their HEAD
> without using any remote tracking branch" may be a reasonable thing
> to do in such a case.
Along the lines of this, perhaps.
builtin/clone.c | 16
1 file changed, 16 insertions(+)
diff --git i/builtin/clone.c w/builtin/clone.c
index 5e8f3ba..c9e099d 100644
--- i/builtin/clone.c
+++ w/builtin/clone.c
@@ -853,6 +853,22 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
"refs/heads/master");
}
+ if (option_single_branch) {
+ /* Fix up the refspec for fetch */
+ strbuf_reset(&value);
+ if (!remote_head_points_at)
+ strbuf_addf(&value, "HEAD");
+ else
+ strbuf_addf(&value, "%s:%s%s",
+ remote_head_points_at->name,
+ branch_top.buf,
+ skip_prefix(remote_head_points_at->name,
"refs/heads/"));
+
+ strbuf_reset(&key);
+ strbuf_addf(&key, "remote.%s.fetch", option_origin);
+ git_config_set_multivar(key.buf, value.buf, NULL, 1);
+ }
+
if (is_local)
clone_local(path, git_dir);
else if (refs && complete_refs_before_fetch)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add diff.context option to specify default context
This adds a diff.context config option to allow specifying the number of lines of context. This is similar to Mercurial's 'unified' option. add-context-option Description: Binary data
Re: [msysGit] Re: [PATCH/RFC] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:28 PM, Johannes Sixt wrote:
> Am 14.09.2012 18:58, schrieb Erik Faye-Lund:
>> tput () {
>> case "$1" in
>> bold)
>> - echo -ne "\033[1m" ;;
>> + printf "\033[1m" ;;
>> setaf)
>> - echo -ne "\033[0;3$2m" ;;
>> + printf "\033[0;3$2m" ;;
>
> This should be
> printf '\033[0;3%sm' "$2" ;;
Is there a reason for %s rather than %d? It seem it only takes
integers, and with %d at least we'd get an error message if someone
started doing something else...
--
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] clone: fix refspec on "--single-branch" option
After a repo was cloned with the "--single-branch"
option, the configured refspec looks like
"+refs/heads/*:refs/remotes/origin/*".
After fetching from this repo again, it'll receive
all refs instead of just the ref from the single
branch. Fixing this by configure exactly the ref
of the branch the user specified in the "git clone"
command.
Signed-off-by: Ralf Thielow
---
> Alternatively, if you can move the logic to set up this
> configuration further down so that it happens after we talked to the
> other side and figured out remote_head_points_at, you could instead
> set it up to keep a single remote tracking branch.
>
> Even if you did so, guess_remote_head() may not find any branch when
> the other repository's HEAD is detached, so you would need to decide
> what to do in such a case, and "fetch and integrate their HEAD
> without using any remote tracking branch" may be a reasonable thing
> to do in such a case.
This second version now covers also the "--single-branch"
option when it was called without "--branch". It also covers
the "detached HEAD" case.
I've tested all the use-cases that have been described above and it works
as expected with this patch. But there's just one thing. It fetches
also all the tags even if they're not on this branch. I'm still in the
"learning process", perhaps someone else can fix this problem or point
me to the reason.
I think it comes from "transport_fetch_refs(transport, mapped_refs);"
on line 813 which is called with a full "+refs/heads/*:refs/remotes/origin/*"
refspec. Thanks
builtin/clone.c | 41 +++--
1 Datei geändert, 27 Zeilen hinzugefügt(+), 14 Zeilen entfernt(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 5e8f3ba..3ddf5ab 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -755,20 +755,6 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
}
strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
-
- if (option_mirror || !option_bare) {
- /* Configure the remote */
- strbuf_addf(&key, "remote.%s.fetch", option_origin);
- git_config_set_multivar(key.buf, value.buf, "^$", 0);
- strbuf_reset(&key);
-
- if (option_mirror) {
- strbuf_addf(&key, "remote.%s.mirror", option_origin);
- git_config_set(key.buf, "true");
- strbuf_reset(&key);
- }
- }
-
strbuf_addf(&key, "remote.%s.url", option_origin);
git_config_set(key.buf, repo);
strbuf_reset(&key);
@@ -853,6 +839,33 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
"refs/heads/master");
}
+ if (option_mirror || !option_bare) {
+ strbuf_reset(&value);
+ if (option_single_branch) {
+ if (option_branch)
+ strbuf_addf(&value, "+%s%s:%s%s",
src_ref_prefix, option_branch,
+ branch_top.buf, option_branch);
+ else if (remote_head_points_at)
+ strbuf_addf(&value, "+%s:%s%s",
our_head_points_at->name,
+
branch_top.buf, prettify_refname(remote_head_points_at->name));
+ } else {
+ strbuf_addf(&value, "+%s*:%s*", src_ref_prefix,
branch_top.buf);
+ }
+ /* Configure the remote */
+ if (value.len) {
+ strbuf_reset(&key);
+ strbuf_addf(&key, "remote.%s.fetch", option_origin);
+ git_config_set_multivar(key.buf, value.buf, "^$", 0);
+ strbuf_reset(&key);
+
+ if (option_mirror) {
+ strbuf_addf(&key, "remote.%s.mirror",
option_origin);
+ git_config_set(key.buf, "true");
+ strbuf_reset(&key);
+ }
+ }
+ }
+
if (is_local)
clone_local(path, git_dir);
else if (refs && complete_refs_before_fetch)
--
1.7.12.395.g6b149ce.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/RFC] test-lib: add support for colors without tput
Erik Faye-Lund writes: >> Neither is which, no? > > Oooh, right. Thanks for noticing. So I guess I should try to run it > instead. From the POSIX spec,... If you assume POSIX.1, there is "type". $ type frotz ; echo $? frotz is /usr/games/frotz 0 $ type frobnitz ; echo $? bash: type: frobnitz: not found 1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 11/11] t7810-grep: test --all-match with multiple --grep and --author options
Michael J Gruber writes:
> --all-match is ignored with multiple author options on purpose but
> requires all --grep to be matched on some line.
It is more like "the behaviour of --all-match to tie more than one --grep
used to be broken when --author or --committer is used".
>
> Signed-off-by: Michael J Gruber
> ---
> t/t7810-grep.sh | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
> index f6edb4d..b5c488e 100755
> --- a/t/t7810-grep.sh
> +++ b/t/t7810-grep.sh
> @@ -531,6 +531,16 @@ test_expect_success 'log --grep --grep --author takes
> union of greps and interse
> test_cmp expect actual
> '
>
> +test_expect_success 'log ---all-match -grep --author --author still takes
> union of authors and intersects with grep' '
> + # grep matches only initial and third
> + # author matches all but second
> + git log --all-match --author="Thor" --author="Night" --grep=i
> --format=%s >actual &&
> + {
> + echo third && echo initial
> + } >expect &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'log --grep --author --author takes union of authors and
> intersects with grep' '
> # grep matches only initial and third
> # author matches all but second
> @@ -541,6 +551,16 @@ test_expect_success 'log --grep --author --author takes
> union of authors and int
> test_cmp expect actual
> '
>
> +test_expect_success 'log --all-match --grep --grep --author takes
> intersection' '
> + # grep matches only third
> + # author matches only initial and third
> + git log --all-match --author="A U Thor" --grep=i --grep=r --format=%s
> >actual &&
> + {
> + echo third
> + } >expect &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'grep with CE_VALID file' '
> git update-index --assume-unchanged t/t &&
> rm t/t &&
--
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: [PATCHv3 09/11] t7810-grep: test multiple --author with --all-match
Michael J Gruber writes:
> --all-match is ignored for author matching on purpose.
>
> Signed-off-by: Michael J Gruber
> ---
It is more like "--all-match is about --grep and does not interact
with --author or --committer at all". At least with the recent fix.
> t/t7810-grep.sh | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
> index b841909..be81d96 100755
> --- a/t/t7810-grep.sh
> +++ b/t/t7810-grep.sh
> @@ -513,6 +513,14 @@ test_expect_success 'log with multiple --author uses
> union' '
> test_cmp expect actual
> '
>
> +test_expect_success 'log --all-match with multiple --author still uses
> union' '
> + git log --all-match --author="Thor" --author="Aster" --format=%s
> >actual &&
> + {
> + echo third && echo second && echo initial
> + } >expect &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'log with --grep and multiple --author uses all-match' '
> git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
> {
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:44 PM, Jeff King wrote: > On Fri, Sep 14, 2012 at 06:41:45PM +0200, Erik Faye-Lund wrote: > >> diff --git a/t/test-lib.sh b/t/test-lib.sh >> index 78c4286..7d1b34b 100644 >> --- a/t/test-lib.sh >> +++ b/t/test-lib.sh >> @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF >> # This test checks if command xyzzy does the right thing... >> # ' >> # . ./test-lib.sh >> + >> +if ! which tput > /dev/null ; then > > Testing the return value of "which" is not portable (I know, it's > insane; SunOS is the common offender). Use "type" instead. Junio already noticed it, and I suggested a fix that involved running it. However, I like your fix much better, 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: [PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Elia Pinto writes:
> Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
> include a malloc() implementation which is tunable via environment
> variables. When MALLOC_CHECK_ is set, a special (less efficient)
> implementation is used which is designed to be tolerant against
> simple errors, such as double calls of free() with the same argument,
> or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_
> is set to 3, a diagnostic message is printed on stderr
> and the program is aborted.
> ...
> Signed-off-by: Elia Pinto
> ---
> This the third reroll of the original patch.
Well written. I have one suggestion and a question, though.
> t/test-lib.sh |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 78c4286..f34b861 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -93,6 +93,15 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
> export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
> export EDITOR
>
> +# Add libc MALLOC and MALLOC_PERTURB test
> +# only if we are not executing the test with valgrind
> +expr "$GIT_TEST_OPTS" : ".*\(--valgrind\)" >/dev/null || {
I would write this like
if ! expr " $GIT_TEST_OPTS " : ".* --valgrind " >/dev/null
then
...
fi
> + MALLOC_CHECK_=3
> + export MALLOC_CHECK_
> + MALLOC_PERTURB_="$( expr \( $$ % 255 \) + 1)"
How was this expression chosen? The only effect I can think of to
use a randomly picked value here is to make it impossible to make
the test repeatable and reproducible, so you must have had some
benefit that outweighs the downside, but I cannot think of any.
Wouldn't MALLOC_PERTURB_=165 (i.e. 0xA5, half of the bits in the
byte is set, including the MSB, and is an odd number) be equally a
good choice without repeatability downside, for example?
Also, doesn't the above give 256 sometimes, which would not fit in a
byte?
> + export MALLOC_PERTURB_
> +}
> +
> # Protect ourselves from common misconfiguration to export
> # CDPATH into the environment
> unset CDPATH
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 06:41:45PM +0200, Erik Faye-Lund wrote: > diff --git a/t/test-lib.sh b/t/test-lib.sh > index 78c4286..7d1b34b 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF > # This test checks if command xyzzy does the right thing... > # ' > # . ./test-lib.sh > + > +if ! which tput > /dev/null ; then Testing the return value of "which" is not portable (I know, it's insane; SunOS is the common offender). Use "type" instead. -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/RFC] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:30 PM, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
>> On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote:
>>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>>> index 78c4286..7d1b34b 100644
>>> --- a/t/test-lib.sh
>>> +++ b/t/test-lib.sh
>>> @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
>>> # This test checks if command xyzzy does the right thing...
>>> # '
>>> # . ./test-lib.sh
>>> +
>>> +if ! which tput > /dev/null ; then
>>> + tput () {
>>> + case "$1" in
>>> + bold)
>>> + echo -ne "\033[1m" ;;
>>> + setaf)
>>> + echo -ne "\033[0;3$2m" ;;
>>> + sgr0)
>>> + echo -ne "\033(\033[m" ;;
>>
>> I should of course have checked this earlier, but I find now that
>> "echo -ne" isn't portable.
>
> Neither is which, no?
Oooh, right. Thanks for noticing. So I guess I should try to run it
instead. From the POSIX spec, I can't find a way of running it that
guarantees a return-code of 0 without clobbering the console somehow.
Perhaps the best thing is pass no operands, and check for $? == 127 instead?
Something like this?
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a939e19..1433cb3 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -130,7 +130,8 @@ export _x05 _x40 _z40 LF
# '
# . ./test-lib.sh
-if ! which tput > /dev/null ; then
+tput > /dev/null
+if test $? -eq 127 ; then
tput () {
case "$1" in
bold)
--
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: [msysGit] Re: [PATCH/RFC] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:28 PM, Johannes Sixt wrote:
> Am 14.09.2012 18:58, schrieb Erik Faye-Lund:
>> tput () {
>> case "$1" in
>> bold)
>> - echo -ne "\033[1m" ;;
>> + printf "\033[1m" ;;
>> setaf)
>> - echo -ne "\033[0;3$2m" ;;
>> + printf "\033[0;3$2m" ;;
>
> This should be
> printf '\033[0;3%sm' "$2" ;;
>
That's probably a good idea, yeah.
>> sgr0)
>> - echo -ne "\033(\033[m" ;;
>> + printf "\033(\033[m" ;;
>> esac
>> }
>> fi
>
> Did you test this only in rxvt or in CMD as well? (I hadn't time to
> test, yet, so I'm asking :-)
I don't have rxvt installed, but it works for me in CMD also.
--
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] test-lib: add support for colors without tput
Erik Faye-Lund writes:
> On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote:
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index 78c4286..7d1b34b 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
>> # This test checks if command xyzzy does the right thing...
>> # '
>> # . ./test-lib.sh
>> +
>> +if ! which tput > /dev/null ; then
>> + tput () {
>> + case "$1" in
>> + bold)
>> + echo -ne "\033[1m" ;;
>> + setaf)
>> + echo -ne "\033[0;3$2m" ;;
>> + sgr0)
>> + echo -ne "\033(\033[m" ;;
>
> I should of course have checked this earlier, but I find now that
> "echo -ne" isn't portable.
Neither is which, no?
--
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: [msysGit] Re: [PATCH/RFC] test-lib: add support for colors without tput
Am 14.09.2012 18:58, schrieb Erik Faye-Lund:
> tput () {
> case "$1" in
> bold)
> - echo -ne "\033[1m" ;;
> + printf "\033[1m" ;;
> setaf)
> - echo -ne "\033[0;3$2m" ;;
> + printf "\033[0;3$2m" ;;
This should be
printf '\033[0;3%sm' "$2" ;;
> sgr0)
> - echo -ne "\033(\033[m" ;;
> + printf "\033(\033[m" ;;
> esac
> }
> fi
Did you test this only in rxvt or in CMD as well? (I hadn't time to
test, yet, so I'm asking :-)
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 00/11] rev-list/log: document logic with several limiting options
Thanks for an update. Queued with minimum modification. -- 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: [PATCHv3 06/11] fixup! log: document use of multiple commit limiting options
Michael J Gruber writes: > Here are a few typo fixes. > > There is a mix of single and back ticks already before this patch, > i.e. ` vs. ' -- I thought we had guidelines for this but don't find them > at the moment. > > Signed-off-by: Michael J Gruber > --- > Documentation/rev-list-options.txt | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Thanks, will squash in. In general: - we want to use `exactly this` when writing an item that the user has to exactly spell as in the text, e.g. subcommand names. - from the older days, we use in synopsis section and in "git subcmd -h" output, and in the body text, we tend to write like '' to italicise in the documentation. I personally find the somewhat ugly in the documentation, but we cannot just drop them as the "man -Tascii" would suffer if we did so. > > diff --git a/Documentation/rev-list-options.txt > b/Documentation/rev-list-options.txt > index 57d6c90..c828408 100644 > --- a/Documentation/rev-list-options.txt > +++ b/Documentation/rev-list-options.txt > @@ -6,12 +6,12 @@ special notations explained in the description, additional > commit > limiting may be applied. > > Using more options generally further limits the output (e.g. > -"--since=" limits to commits newer than , and using it > -with "--grep=" further limits to commits whose log message > -has a line that match ), unless otherwise noted. > +`--since=` limits to commits newer than ``, and using it > +with `--grep=` further limits to commits whose log message > +has a line that matches ``), unless otherwise noted. > > Note that these are applied before commit > -ordering and formatting options, such as '--reverse'. > +ordering and formatting options, such as `--reverse`. > > -- > > @@ -47,7 +47,7 @@ endif::git-rev-list[] > Limit the commits output to ones with author/committer > header lines that match the specified pattern (regular > expression). With more than one `--author=`, > - commits whose author match any of the given patterns are > + commits whose author matches any of the given patterns are > chosen (similarly for multiple `--committer=`). > > --grep=:: > @@ -55,7 +55,7 @@ endif::git-rev-list[] > Limit the commits output to ones with log message that > matches the specified pattern (regular expression). With > more than one `--grep=`, commits whose message > - match any of the given patterns are chosen (but see > + matches any of the given patterns are chosen (but see > `--all-match`). > > --all-match:: -- 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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:12 PM, Elia Pinto wrote: > 2012/9/14 Elia Pinto : >> 2012/9/14 Erik Faye-Lund : >>> On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund wrote: On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote: > diff --git a/t/test-lib.sh b/t/test-lib.sh > index 78c4286..7d1b34b 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF > # This test checks if command xyzzy does the right thing... > # ' > # . ./test-lib.sh > + >> Nice. But this setting should be check that we have a terminal first isn't ? >> Some test like this before >> >> test "X$$TERM" != Xdumb \ >> && test -t 1 2>/dev/null \ >> && > and in reality this echo use is not portable. Yeah; I posted a couple of follow-up mails earlier where I had noticed it and changed to printf instead. It seems the testsuite is already using it, so it's probably portable. Thanks a lot for the extra set of eyes :) -- 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] test-lib: add support for colors without tput
2012/9/14 Elia Pinto :
> 2012/9/14 Erik Faye-Lund :
>> On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund wrote:
>>> On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
# . ./test-lib.sh
+
> Nice. But this setting should be check that we have a terminal first isn't ?
> Some test like this before
>
> test "X$$TERM" != Xdumb \
> && test -t 1 2>/dev/null \
> &&
and in reality this echo use is not portable.
http://ftp.gnu.org/old-gnu/Manuals/autoconf-2.53/html_node/Limitations-of-Builtins.html
In popt 1_17 autogen.sh does
red=; grn=; lgn=; blu=; std=;
test "X$$TERM" != Xdumb \
&& test -t 1 2>/dev/null \
&& { \
red='^[[0;31m'; \
grn='^[[0;32m'; \
lgn='^[[1;32m'; \
blu='^[[1;34m'; \
std='^[[m'; \
}
and
Die(){
color="$red"
echo "${color}${_PROGNAME}: Error: $@${std}" >&2
exit 1
}
Die "message here"
>
> or the inverse logic. This is what automake and popt autogen.sh does.
>
> Best Regards
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:08 PM, Elia Pinto wrote: > 2012/9/14 Erik Faye-Lund : >> On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund wrote: >>> On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index 78c4286..7d1b34b 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF # This test checks if command xyzzy does the right thing... # ' # . ./test-lib.sh + > Nice. But this setting should be check that we have a terminal first isn't ? > Some test like this before > > test "X$$TERM" != Xdumb \ > && test -t 1 2>/dev/null \ > && > > or the inverse logic. This is what automake and popt autogen.sh does. There's already such a check a few lines further down, and tput isn't used in such cases. -- 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: [PATCHv3 03/11] grep: show --debug output only once
Michael J Gruber writes: > When threaded grep is in effect, the patterns are duplicated and > recompiled for each thread. Avoid "--debug" output during the > recompilation so that the output is given once instead of "1+nthreads" > times. > > Signed-off-by: Michael J Gruber > --- > builtin/grep.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/builtin/grep.c b/builtin/grep.c > index 8aea00c..a7e8df0 100644 > --- a/builtin/grep.c > +++ b/builtin/grep.c > @@ -209,6 +209,7 @@ static void start_threads(struct grep_opt *opt) > int err; > struct grep_opt *o = grep_opt_dup(opt); > o->output = strbuf_out; > + o->debug = 0; > compile_grep_patterns(o); > err = pthread_create(&threads[i], NULL, run, o); Makes sense; 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: [PATCHv3 01/11] grep: teach --debug option to dump the parse tree
Michael J Gruber writes:
> From: Junio C Hamano
>
> Our "grep" allows complex boolean expressions to be formed to match
> each individual line with operators like --and, '(', ')' and --not.
> Introduce the "--debug" option to show the parse tree to help people
> who want to debug and enhance it.
>
> Also "log" learns "--debug-grep" option to do the same. The command
This was actually a leftover incorrect message.
When we introduce the equivalent of
$ git grep -e foo --and --not \( -e bar -e baz \)
to the log family in some distant future, we may end up having to
disambiguate the "--not" (which means something completely different
for the log family) meant for the grep part by doing
$ git log --grep=foo --grep-and --grep-not \
--grep-\( --grep=bar --grep=baz --grep-\)
or something like that, and the code says --grep-debug because that
would fit better than --debug-grep.
Other than that, the patch looks good ;-)
--
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] test-lib: add support for colors without tput
2012/9/14 Erik Faye-Lund : > On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund wrote: >> On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote: >>> diff --git a/t/test-lib.sh b/t/test-lib.sh >>> index 78c4286..7d1b34b 100644 >>> --- a/t/test-lib.sh >>> +++ b/t/test-lib.sh >>> @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF >>> # This test checks if command xyzzy does the right thing... >>> # ' >>> # . ./test-lib.sh >>> + Nice. But this setting should be check that we have a terminal first isn't ? Some test like this before test "X$$TERM" != Xdumb \ && test -t 1 2>/dev/null \ && or the inverse logic. This is what automake and popt autogen.sh does. Best Regards -- 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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund wrote:
> On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote:
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index 78c4286..7d1b34b 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
>> # This test checks if command xyzzy does the right thing...
>> # '
>> # . ./test-lib.sh
>> +
>> +if ! which tput > /dev/null ; then
>> + tput () {
>> + case "$1" in
>> + bold)
>> + echo -ne "\033[1m" ;;
>> + setaf)
>> + echo -ne "\033[0;3$2m" ;;
>> + sgr0)
>> + echo -ne "\033(\033[m" ;;
>
> I should of course have checked this earlier, but I find now that
> "echo -ne" isn't portable. So perhaps this on top?
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 7d1b34b..91a1d7b 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -134,11 +134,11 @@ if ! which tput > /dev/null ; then
> tput () {
> case "$1" in
> bold)
> - echo -ne "\033[1m" ;;
> + printf "%b" "\033[1m" ;;
> setaf)
> - echo -ne "\033[0;3$2m" ;;
> + printf "%b" "\033[0;3$2m" ;;
> sgr0)
> - echo -ne "\033(\033[m" ;;
> + printf "%b" "\033(\033[m" ;;
> esac
> }
> fi
And again, I'm stupid for not reading documentation properly; octal
escaped strings in the format string should work (and does on my
systems), so this is sufficient:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7d1b34b..2a6149e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -134,11 +134,11 @@ if ! which tput > /dev/null ; then
tput () {
case "$1" in
bold)
- echo -ne "\033[1m" ;;
+ printf "\033[1m" ;;
setaf)
- echo -ne "\033[0;3$2m" ;;
+ printf "\033[0;3$2m" ;;
sgr0)
- echo -ne "\033(\033[m" ;;
+ printf "\033(\033[m" ;;
esac
}
fi
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund wrote:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 78c4286..7d1b34b 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
> # This test checks if command xyzzy does the right thing...
> # '
> # . ./test-lib.sh
> +
> +if ! which tput > /dev/null ; then
> + tput () {
> + case "$1" in
> + bold)
> + echo -ne "\033[1m" ;;
> + setaf)
> + echo -ne "\033[0;3$2m" ;;
> + sgr0)
> + echo -ne "\033(\033[m" ;;
I should of course have checked this earlier, but I find now that
"echo -ne" isn't portable. So perhaps this on top?
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7d1b34b..91a1d7b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -134,11 +134,11 @@ if ! which tput > /dev/null ; then
tput () {
case "$1" in
bold)
- echo -ne "\033[1m" ;;
+ printf "%b" "\033[1m" ;;
setaf)
- echo -ne "\033[0;3$2m" ;;
+ printf "%b" "\033[0;3$2m" ;;
sgr0)
- echo -ne "\033(\033[m" ;;
+ printf "%b" "\033(\033[m" ;;
esac
}
fi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
include a malloc() implementation which is tunable via environment
variables. When MALLOC_CHECK_ is set, a special (less efficient)
implementation is used which is designed to be tolerant against
simple errors, such as double calls of free() with the same argument,
or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_
is set to 3, a diagnostic message is printed on stderr
and the program is aborted.
Setting the MALLOC_PERTURB_ environment variable causes the malloc
functions in libc to return memory which has been wiped and clear
memory when it is returned.
Of course this does not affect calloc which always does clear the memory.
The reason for this exercise is, of course, to find code which uses
memory returned by malloc without initializing it and code which uses
code after it is freed. valgrind can do this but it's costly to run.
The MALLOC_PERTURB_ exchanges the ability to detect problems in 100%
of the cases with speed.
The byte value used to initialize values returned by malloc is the byte
value of the environment value. The value used to clear memory is the
bitwise inverse. Setting MALLOC_PERTURB_ to zero disables the feature.
This technique can find hard to detect bugs.
It is therefore suggested to always use this flag (at least temporarily)
when testing out code or a new distribution.
But the test suite can use also valgrind(memcheck) via 'make valgrind'
or 'make GIT_TEST_OPTS="--valgrind"'.
Memcheck wraps client calls to malloc(), and puts a "red zone" on
each end of each block in order to detect access overruns.
Memcheck already detects double free() (up to the limit of the buffer
which remembers pending free()). Thus memcheck subsumes all the
documented coverage of MALLOC_CHECK_.
If MALLOC_CHECK_ is set non-zero when running memcheck, then the
overruns that might be detected by MALLOC_CHECK_ would be overruns
on the wrapped blocks which include the red zones. Thus MALLOC_CHECK_
would be checking memcheck, and not the client. This is not useful,
and actually is wasteful. The only possible [documented] advantage
of using MALLOC_CHECK_ and memcheck together, would be if MALLOC_CHECK_
detected duplicate free() in more cases than memcheck because memcheck's
buffer is too small.
Therefore we don't use MALLOC_CHECK_ and valgrind(memcheck) at the
same time.
Signed-off-by: Elia Pinto
---
This the third reroll of the original patch.
I redid the patch correcting the export command in a more portable
way thanks to the Junio observation and not setting MALLOC_CHECK_
at the same time we are using valgrind. Added in the commit the reason,
not so simple to find. Hope the better :=)
t/test-lib.sh |9 +
1 file changed, 9 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..f34b861 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -93,6 +93,15 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR
+# Add libc MALLOC and MALLOC_PERTURB test
+# only if we are not executing the test with valgrind
+expr "$GIT_TEST_OPTS" : ".*\(--valgrind\)" >/dev/null || {
+ MALLOC_CHECK_=3
+ export MALLOC_CHECK_
+ MALLOC_PERTURB_="$( expr \( $$ % 255 \) + 1)"
+ export MALLOC_PERTURB_
+}
+
# Protect ourselves from common misconfiguration to export
# CDPATH into the environment
unset CDPATH
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert diffstat back to English
Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> This reverts the i18n part of 7f81463 (Use correct grammar in diffstat >> summary line - 2012-02-01) but still keeps the grammar correctness for >> English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on >> diffstat - 2012-08-27). The result is diffstat always in English >> for all commands. >> >> This helps stop users from accidentally sending localized >> format-patch'd patches. >> >> Signed-off-by: Nguyễn Thái Ngọc Duy Why am I getting this from t3300? --- expected2012-09-14 16:43:09.0 + +++ current 2012-09-14 16:43:09.0 + @@ -1,2 +1,2 @@ "tabs\t,\" (dq) and spaces" - 1 file changed, 0 insertions(+), 0 deletions(-) + 1 files changed, 0 insertion(+), 0 deletion(-) Ah, your rewrite of Q_() is wrong. Will squash the attached in before queueing this for maint. Thanks. diff.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git c/diff.c w/diff.c index 3ddf0e6..1d9783c 100644 --- c/diff.c +++ w/diff.c @@ -1401,7 +1401,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions) } strbuf_addf(&sb, - files ? " %d files changed" : " %d file changed", + (files == 1) ? " %d file changed" : " %d files changed", files); /* @@ -1418,7 +1418,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions) * do not translate it. */ strbuf_addf(&sb, - insertions ? ", %d insertions(+)" : ", %d insertion(+)", + (insertions == 1) ? ", %d insertion(+)" : ", %d insertions(+)", insertions); } @@ -1428,7 +1428,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions) * do not translate it. */ strbuf_addf(&sb, - deletions ? ", %d deletions(-)" : ", %d deletion(-)", + (deletions == 1) ? ", %d deletion(-)" : ", %d deletions(-)", deletions); } strbuf_addch(&sb, '\n'); -- 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/RFC] test-lib: add support for colors without tput
For platforms that does not have tput we can still perform coloring
by manually emitting the ANSI control codes. If tput is missing from
$PATH, install a replacement function.
The exact strings has been dumped from a machine that has tput, by
piping the output of tput through 'od -c -An'.
Signed-off-by: Erik Faye-Lund
---
I got slightly annoyed that we didn't get colored output from the
tests on Windows, so I decided to fix it.
Hopefully other platforms can benefit from this as well.
I'm not super happy with the condition to enable it. I considered
an environment variable as well, but decided against it because
"make -C t" from the root does not seem to pick up environment
variables configured in the main Makefile.
Thoughts?
t/test-lib.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
# . ./test-lib.sh
+
+if ! which tput > /dev/null ; then
+ tput () {
+ case "$1" in
+ bold)
+ echo -ne "\033[1m" ;;
+ setaf)
+ echo -ne "\033[0;3$2m" ;;
+ sgr0)
+ echo -ne "\033(\033[m" ;;
+ esac
+ }
+fi
+
[ "x$ORIGINAL_TERM" != "xdumb" ] && (
TERM=$ORIGINAL_TERM &&
export TERM &&
--
1.7.11.msysgit.0.5.g0225efe.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: Using Format/export-subst Howto.
> -Original Message- > From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Friday, September 14, 2012 10:40 AM > To: Mestnik, Michael J - Eagan, MN - Contractor > Cc: Michael J Gruber; git@vger.kernel.org > Subject: Re: Using Format/export-subst Howto. > > Am 9/14/2012 17:27, schrieb Mestnik, Michael J - Eagan, MN - > Contractor: > > > >> -Original Message- From: Johannes Sixt > >> If EOL conversion or a clean filter was applied during 'git add > >> file', is the version in the worktree suddenly wrong? Of course, > >> not. > >> > >> I would place $Id$ treatment in the same ball park and > declare it as > >> a mistake of the editor that it did not remove the now "wrong" SHA1 > >> from $Id:$. > > > > I think the difference here is that git does not *currently > change the > > OS's LEF. In this case each commit alters the Id and git is the one > > altering the Id. > > Maybe you misunderstood $Id$? The value you get there is the > blob's SHA1, > not the commit's. That is, it does not change on every > commit, but only > when the file changes. > > You are right that the value itself is something that is > dictated by git's > database model, but the change logically happens when the > editor modifies > the file. > > (My contribution to this thread should be regarded as food > for thought. > Personally, I don't mind whether or not and when $Id$ is updated.) > Thank you for correcting me, I've always noticed this number doesn't seam to correlate to anything of use for me. However it's been helpful when reading these reports to see what version generated it and that's why I wanted to further expand the information provided... The date and time of the commit are specifically useful to me. > -- Hannes > Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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] clone: fix refspec on "--single-branch" option
Nguyen Thai Ngoc Duy writes: > On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano wrote: > >> Alternatively, if you can move the logic to set up this >> configuration further down so that it happens after we talked to the >> other side and figured out remote_head_points_at, you could instead >> set it up to keep a single remote tracking branch. > > That sounds reasonable. I have a question though, what should a user > do when he/she want to fetch all branches again? Messing up with > refspec in config file is not something I would like to do. You first have to think ;-). I would say there are two kinds of users. - To the simplistic ones who fear the power of configuration, we can simply tell "You don't. Use 'single' when you want to keep working with the single branch. If you want full, reclone, and migrate your work from the single one by fetching from it to the full clone before discarding the single one". - To the ones who wants to take the full advantage of flexibility of configuration, we can tell "remotes.$name.fetch configuration is your friend. Do whatever you want to do with it, but here are two hints". The hints would cover the case to revert to the default refspec, and the case to add another specific branch. These days, with "git config" and "git remote" wrappers, I do not particularly see a need to fear the power of configuration, 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: [PATCHv2 3/6] t7810-grep: test multiple --author with --all-match
Michael J Gruber writes: > Junio C Hamano venit, vidit, dixit 14.09.2012 01:26: > ... >> when "--all-match" was given from the command line, so that the >> "committer", "author" and elements on the top-level backbone in >> "pattern" form the top-level backbone of the resulting expression to >> be inspected by the "all-match" logic. >> >> Does this pass the expect-failure test in your [PATCH 5/6]? > > Just a quick heads up: > > I merged 38ed8ef (log --grep/--author: honor --all-match honored for > multiple --grep patterns, 2012-09-13) from pu into my test branch, > and this fixes what I had marked as known failure there. Thanks! Thanks for testing. > > I still have to figure out the logic, but begin to understand that > "(OR...) and "(AND...)" are linewise, and all-match is a bufferwise AND Yes, all-match is about requiring all the top-level nodes to have fired while inspecting the whole file. So between these: $ git grep -e foo --and -e bar $ git grep --all-match -e foo -e bar the former shows lines that has both foo and bar, while the latter shows lines that has either foo or bar but only from files that has both in them (on possibly separate lines). > Now, what is "*or*" ... That is for to show the token we received from the command line parser; the more interesting part is the parsed expression tree, that is mostly formed as a tree with each node labeled with what kind of operation it represents. -- 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: Using Format/export-subst Howto.
> -Original Message- > From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Friday, September 14, 2012 10:07 AM > To: Michael J Gruber > Cc: Mestnik, Michael J - Eagan, MN - Contractor; git@vger.kernel.org > Subject: Re: Using Format/export-subst Howto. > > Am 9/14/2012 15:03, schrieb Michael J Gruber: > > "git replaces $Id$... upon checkout. Any byte sequence that begins > > with $Id: and ends with $ in the worktree file is replaced with $Id$ > > upon check-in." > > > > Now, the there are two problems after you add $Id$ and check-in > > (commit): > > > > - commit does not check out, i.e. your work-tree copy is > not updated > > with expanded $Id$ - Not even "git checkout thatFile" updates your > > work-tree copy. > > > > The first one could be considered OK, but at least the second one > > seems to be a bug. Together they create the following problem: Say, > > you've corrected that problem (rm that file and checkout) and then > > update your file, add and commit. It will keeping having > the old (now > > wrong) Id expansion. > > If EOL conversion or a clean filter was applied during 'git > add file', is > the version in the worktree suddenly wrong? Of course, not. > > I would place $Id$ treatment in the same ball park and declare it as a > mistake of the editor that it did not remove the now "wrong" > SHA1 from $Id:$. I think the difference here is that git does not *currently change the OS's LEF. In this case each commit alters the Id and git is the one altering the Id. If git did change the expected/system LEF then it would seam reasonable that it would also be responsible for forward porting files to the new regime. * If git could fix some misguided operating systems into following the correct LEF, that would be great! What I mean is that I agree that git is not the tool to tackle every technical challenge, but I think it should carry though with any decisions it makes and that it should not ignore the effects(or changes) made as a result of **these decisions. ** Any and all, within reason. Cheers! > > > We should do something about this. > > Not necessary, IMHO. > > -- Hannes > Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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: Using Format/export-subst Howto.
Am 9/14/2012 17:27, schrieb Mestnik, Michael J - Eagan, MN - Contractor: > >> -Original Message- From: Johannes Sixt >> If EOL conversion or a clean filter was applied during 'git add >> file', is the version in the worktree suddenly wrong? Of course, >> not. >> >> I would place $Id$ treatment in the same ball park and declare it as >> a mistake of the editor that it did not remove the now "wrong" SHA1 >> from $Id:$. > > I think the difference here is that git does not *currently change the > OS's LEF. In this case each commit alters the Id and git is the one > altering the Id. Maybe you misunderstood $Id$? The value you get there is the blob's SHA1, not the commit's. That is, it does not change on every commit, but only when the file changes. You are right that the value itself is something that is dictated by git's database model, but the change logically happens when the editor modifies the file. (My contribution to this thread should be regarded as food for thought. Personally, I don't mind whether or not and when $Id$ is updated.) -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using Format/export-subst Howto.
Am 9/14/2012 15:03, schrieb Michael J Gruber: > "git replaces $Id$... upon checkout. Any byte sequence that begins > with $Id: and ends with $ in the worktree file is replaced with $Id$ > upon check-in." > > Now, the there are two problems after you add $Id$ and check-in > (commit): > > - commit does not check out, i.e. your work-tree copy is not updated > with expanded $Id$ - Not even "git checkout thatFile" updates your > work-tree copy. > > The first one could be considered OK, but at least the second one > seems to be a bug. Together they create the following problem: Say, > you've corrected that problem (rm that file and checkout) and then > update your file, add and commit. It will keeping having the old (now > wrong) Id expansion. If EOL conversion or a clean filter was applied during 'git add file', is the version in the worktree suddenly wrong? Of course, not. I would place $Id$ treatment in the same ball park and declare it as a mistake of the editor that it did not remove the now "wrong" SHA1 from $Id:$. > We should do something about this. Not necessary, IMHO. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: fix refspec on "--single-branch" option
On Fri, Sep 14, 2012 at 3:10 PM, Nguyen Thai Ngoc Duy wrote:
> On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> Who guarantees at this point in the codepath that option_branch is
>>> set when option_single_branch is non-zero? Until we talk with the
>>> remote, "clone --single-branch" without an explicit "--branch" will
>>> not learn which branch at the remote we are going to fetch (it will
>>> be their HEAD).
>>>
>>> I wonder if this should be more like this:
>>>
>>> if (option_single_branch) {
>>> if (option_branch)
>>> Your patch "+refs/heads/foo:refs/remotes/origin/foo";
>>> else
>>> "HEAD";
>>> } else {
>>> Original "+refs/heads/*:refs/remotes/origin/*";
>>> }
>>>
>>> That is, "clone --single-branch" will continue fetching from and
>>> integrating with their HEAD without storing any remote tracking
>>> branch.
>>
>> Alternatively, if you can move the logic to set up this
>> configuration further down so that it happens after we talked to the
>> other side and figured out remote_head_points_at, you could instead
>> set it up to keep a single remote tracking branch.
>
> That sounds reasonable. I have a question though, what should a user
> do when he/she want to fetch all branches again? Messing up with
> refspec in config file is not something I would like to do.
>
$ git remote set-branches "*"
> Perhaps a heuristic in git-fetch to detect "single branch" situation
> and ignore refspec? We could hint people that refspecs are not
> followed when remote has more than one branch. They could either fetch
> the another branch explicitly, which turns off the heuristic, or turn
> off the advice.
>
Such an advice when using "--single-branch" is a good idea, i think.
Something like "The remote is configured to fetch only branch .
If you want to fetch all branches, use "git remote set-branches "*""
or something like that.
>> Even if you did so, guess_remote_head() may not find any branch when
>> the other repository's HEAD is detached, so you would need to decide
>> what to do in such a case, and "fetch and integrate their HEAD
>> without using any remote tracking branch" may be a reasonable thing
>> to do in such a case.
> --
> Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: inconsistent behavior on mac with case changes
On Fri, Sep 14, 2012 at 9:48 AM, Andreas Ericsson wrote: > On 09/14/2012 02:37 PM, Larry Martell wrote: >> On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell >> wrote: >>> I created a dir on my Mac called Rollup, and pushed it out. Then went >>> to a CentOS box, pulled it, and realized I wanted to call it RollUp >>> (capital U). I renamed it, and pushed out the change. Went back to the >>> Mac and did a pull - it said it created the RollUp dir, but it did not >>> - it was still called Rollup. I reamed it, but status did not pick up >>> the change. Then I checked out a branch that had Rollup, but it was >>> gone there - no Rollup or RollUp. I did a merge and then RollUp was >>> created. >>> >>> I know the Mac is somewhat inconsistent with how it deals with case, e.g.: >>> >>> $ ls >>> RollUp >>> $ ls -d Rollup >>> Rollup >>> $ ls -d RollUp >>> RollUp >>> $ find . -name Rollup -print >>> $ find . -name RollUp -print >>> ./RollUp >>> >>> So I guess I can understand git also being inconsistent there. But >>> what really got me was the dir being gone on the branch. >>> >>> Is all this expected behavior? >> > > More or less. Git sees Rollup and RollUp as two different directories, > so assuming everything inside it is committed git is free to remove > the directory that exists on one branch but not the other when switching > branches in order to keep the work tree in sync with the index. > > Consider this (most output cut away): > > git init > touch base; git add base git commit -m "first commit" > mkdir foo && touch foo/lala && git add foo/lala && git commit -m "meh" > git checkout -b newbranch HEAD^ > ls -ld foo > ls: cannot access foo.: No such file or directory > mkdir bar && touch bar/bear && git add bar/bear && git commit -m "rawr" > git checkout master > ls -ld bar > ls: cannot access bar.: no such file or directory > > If git would leave your committed directory in the worktree when you > move to a branch that doesn't have it, it would put you in a very > weird position where you may have to clear away rubble from someone > else, or start depending on code that's not in your branch. So yes, > you're seeing the expected behaviour, and OSX is retarded wrt case > sensitive filenames. I'd suggest you either reformat your drive to > stop using HFS+ or do your development work inside a loopback fs > mounted with proper case sensitivity, as there's really no sane way > around the problem OSX causes. Thanks for the detailed reply! -- 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: inconsistent behavior on mac with case changes
On 09/14/2012 02:37 PM, Larry Martell wrote: > On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell > wrote: >> I created a dir on my Mac called Rollup, and pushed it out. Then went >> to a CentOS box, pulled it, and realized I wanted to call it RollUp >> (capital U). I renamed it, and pushed out the change. Went back to the >> Mac and did a pull - it said it created the RollUp dir, but it did not >> - it was still called Rollup. I reamed it, but status did not pick up >> the change. Then I checked out a branch that had Rollup, but it was >> gone there - no Rollup or RollUp. I did a merge and then RollUp was >> created. >> >> I know the Mac is somewhat inconsistent with how it deals with case, e.g.: >> >> $ ls >> RollUp >> $ ls -d Rollup >> Rollup >> $ ls -d RollUp >> RollUp >> $ find . -name Rollup -print >> $ find . -name RollUp -print >> ./RollUp >> >> So I guess I can understand git also being inconsistent there. But >> what really got me was the dir being gone on the branch. >> >> Is all this expected behavior? > More or less. Git sees Rollup and RollUp as two different directories, so assuming everything inside it is committed git is free to remove the directory that exists on one branch but not the other when switching branches in order to keep the work tree in sync with the index. Consider this (most output cut away): git init touch base; git add base git commit -m "first commit" mkdir foo && touch foo/lala && git add foo/lala && git commit -m "meh" git checkout -b newbranch HEAD^ ls -ld foo ls: cannot access foo.: No such file or directory mkdir bar && touch bar/bear && git add bar/bear && git commit -m "rawr" git checkout master ls -ld bar ls: cannot access bar.: no such file or directory If git would leave your committed directory in the worktree when you move to a branch that doesn't have it, it would put you in a very weird position where you may have to clear away rubble from someone else, or start depending on code that's not in your branch. So yes, you're seeing the expected behaviour, and OSX is retarded wrt case sensitive filenames. I'd suggest you either reformat your drive to stop using HFS+ or do your development work inside a loopback fs mounted with proper case sensitivity, as there's really no sane way around the problem OSX causes. > Is this not the correct list for a question like this? If not, is > there another list that's more appropriate? It is, but people don't always spend their days looking for questions to answer. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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] clone: fix refspec on "--single-branch" option
On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Who guarantees at this point in the codepath that option_branch is
>> set when option_single_branch is non-zero? Until we talk with the
>> remote, "clone --single-branch" without an explicit "--branch" will
>> not learn which branch at the remote we are going to fetch (it will
>> be their HEAD).
>>
>> I wonder if this should be more like this:
>>
>> if (option_single_branch) {
>> if (option_branch)
>> Your patch "+refs/heads/foo:refs/remotes/origin/foo";
>> else
>> "HEAD";
>> } else {
>> Original "+refs/heads/*:refs/remotes/origin/*";
>> }
>>
>> That is, "clone --single-branch" will continue fetching from and
>> integrating with their HEAD without storing any remote tracking
>> branch.
>
> Alternatively, if you can move the logic to set up this
> configuration further down so that it happens after we talked to the
> other side and figured out remote_head_points_at, you could instead
> set it up to keep a single remote tracking branch.
That sounds reasonable. I have a question though, what should a user
do when he/she want to fetch all branches again? Messing up with
refspec in config file is not something I would like to do.
Perhaps a heuristic in git-fetch to detect "single branch" situation
and ignore refspec? We could hint people that refspecs are not
followed when remote has more than one branch. They could either fetch
the another branch explicitly, which turns off the heuristic, or turn
off the advice.
> Even if you did so, guess_remote_head() may not find any branch when
> the other repository's HEAD is detached, so you would need to decide
> what to do in such a case, and "fetch and integrate their HEAD
> without using any remote tracking branch" may be a reasonable thing
> to do in such a case.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Makefile: respect $LINGUAS variable on selecting .mo files to install
Nguyễn Thái Ngọc Duy venit, vidit, dixit 14.09.2012 14:40: > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy > wrote: > > We should honor LINGUAS variable on installation. Only languages > > listed in that variable are installed. Many if not most of projects do > > that already. > > And here is a try. > > Makefile | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Makefile b/Makefile > index 56301dc..eeba645 100644 > --- a/Makefile > +++ b/Makefile > @@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C) > > pot: po/git.pot > > +ifdef LINGUAS > +POFILES := $(shell sh -c "ls $(patsubst %,po/%.po,$(LINGUAS)) 2>/dev/null") > +else > POFILES := $(wildcard po/*.po) > +endif > MOFILES := $(patsubst > po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES)) > > ifndef NO_GETTEXT > While that may be worthwhile if LINGUAS is some sort of standard I don't think it relates to the discussion at hand. The problem is not the set to choose from but the choice and the specificity of the choice (which parts of the code does it affect). 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
Re: Using Format/export-subst Howto.
Mestnik, Michael J - Eagan, MN - Contractor venit, vidit, dixit 14.09.2012 14:20: > I must have missed something reading through the documentation for this. git > version 1.7.11.3 > > $ git check-attr -a -- autorepair.d/AR02_new_rttest.sh > autorepair.d/AR02_new_rttest.sh: ident: set > autorepair.d/AR02_new_rttest.sh: export-subst: set > > echo "0..$_expected_tests" > diag 'Script Version: $Id: 1ca40f8395ea361cc07d2ec1a2961c3df749dc3c $' > diag 'By: $Format:%cn$ $Format:%ce$' > diag 'At: $Format:%cD$' > '$Format:' is processed when creating an archive. It's mentioned with export-subst only under the heading "create archive". So, that is as described, I think. > I also believe that the documentation could try and better explain under what > conditions "$Id" will be processed, it doesn't seam to happen on commit and > even after a checkout this is not updated. It does seam to update during a > pull and that's basically all I need. "git replaces $Id$... upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in." Now, the there are two problems after you add $Id$ and check-in (commit): - commit does not check out, i.e. your work-tree copy is not updated with expanded $Id$ - Not even "git checkout thatFile" updates your work-tree copy. The first one could be considered OK, but at least the second one seems to be a bug. Together they create the following problem: Say, you've corrected that problem (rm that file and checkout) and then update your file, add and commit. It will keeping having the old (now wrong) Id expansion. We should do something about this. 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
Re: Please pull git-l10n updates for git v1.7.12-146-g16d26
(Dropping translators as they probably are not interested in this) I saw a gnu project does this (I don't remember what project). If we update .po* files with --no-location, we can avoid a lot of diff noises due to line number changes. A typical translator does not care about these lines anyway. Those who do can easily search the string in source files without them. On Thu, Sep 13, 2012 at 5:41 AM, Jiang Xin wrote: > po/TEAMS|3 +- > po/de.po| 712 > po/git.pot | 684 +++ > po/sv.po| 715 > po/vi.po| 1767 > +++ > po/zh_CN.po | 712 > 6 files changed, 2394 insertions(+), 2199 deletions(-) -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Makefile: respect $LINGUAS variable on selecting .mo files to install
Signed-off-by: Nguyễn Thái Ngọc Duy --- On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy wrote: > We should honor LINGUAS variable on installation. Only languages > listed in that variable are installed. Many if not most of projects do > that already. And here is a try. Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 56301dc..eeba645 100644 --- a/Makefile +++ b/Makefile @@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C) pot: po/git.pot +ifdef LINGUAS +POFILES := $(shell sh -c "ls $(patsubst %,po/%.po,$(LINGUAS)) 2>/dev/null") +else POFILES := $(wildcard po/*.po) +endif MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES)) ifndef NO_GETTEXT -- 1.7.12.403.gce5cf6f.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: inconsistent behavior on mac with case changes
On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell wrote: > I created a dir on my Mac called Rollup, and pushed it out. Then went > to a CentOS box, pulled it, and realized I wanted to call it RollUp > (capital U). I renamed it, and pushed out the change. Went back to the > Mac and did a pull - it said it created the RollUp dir, but it did not > - it was still called Rollup. I reamed it, but status did not pick up > the change. Then I checked out a branch that had Rollup, but it was > gone there - no Rollup or RollUp. I did a merge and then RollUp was > created. > > I know the Mac is somewhat inconsistent with how it deals with case, e.g.: > > $ ls > RollUp > $ ls -d Rollup > Rollup > $ ls -d RollUp > RollUp > $ find . -name Rollup -print > $ find . -name RollUp -print > ./RollUp > > So I guess I can understand git also being inconsistent there. But > what really got me was the dir being gone on the branch. > > Is all this expected behavior? Is this not the correct list for a question like this? If not, is there another list that's more appropriate? -- 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
Using Format/export-subst Howto.
I must have missed something reading through the documentation for this. git version 1.7.11.3 $ git check-attr -a -- autorepair.d/AR02_new_rttest.sh autorepair.d/AR02_new_rttest.sh: ident: set autorepair.d/AR02_new_rttest.sh: export-subst: set echo "0..$_expected_tests" diag 'Script Version: $Id: 1ca40f8395ea361cc07d2ec1a2961c3df749dc3c $' diag 'By: $Format:%cn$ $Format:%ce$' diag 'At: $Format:%cD$' I also believe that the documentation could try and better explain under what conditions "$Id" will be processed, it doesn't seam to happen on commit and even after a checkout this is not updated. It does seam to update during a pull and that's basically all I need. Thanks! Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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] Revert diffstat back to English
On Fri, Sep 14, 2012 at 7:11 AM, Jeff King wrote: > On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote: > >> > I agree that the line is not bright. I do not know if it is worthwhile >> > or not. I think it will solve some practical problems, but it may also >> > introduce others. But basically having a per-repo LANG setting (which >> > is what the projectlang you are talking about would do) also does not >> > seem like a solution that people will use, because they will not get any >> > localization benefit at all. >> > >> > So again, I'd rather err on the side of pushing those things that are >> > near the line into the "do not translate" side, letting people use LANG >> > to localize the rest, and accepting that occasionally people are going >> > to accidentally show you output in a language you don't understand. But >> > hopefully that keeps it to "occasionally" and not "every time you send >> > out a patch". >> >> I am confused asto what you really want. In a Klingon-only project, >> I think it is perfectly fine to localize the diffstat summary line >> to Klingon. It is not machine readble, and it is not personal, but >> it is to be shared with project members, who all speak Klingon. >> >> Pushing more things to "do not translate" side of the line means >> robbing the benefit of i18n from people, no? > > Yes. But you cannot please both sides without creating a third category, > as you noted. If you do not translate diffstat, then Klingon-only projects are > unhappy. If you do translate, then projects run in LANG=C will either > get public Klingon, or the project members will turn off all translation > and lose all benefit of i18n. I agree with Jeff on this. And "everything in $projectlang" is just like "everything in C", the problem remains. Suppose Chinese becomes a very popular language (if it has not been so), projects with dominant Chinese people would prefer Chinese. But large enough projects will involve non-Chinese people who prefer their native non-Chinese language as UI. I'm not pushing "do not translate" side. I just postpone it until a proper approach is found (preferably by Klingon teams who are upset about this "do not translate" patch). Supporting two non-C languages at the same time could be done (not very elegantly) by forking a process with the second language, which serves as gettext source for first process via pipes. The problem is drawing a line between team strings and local strings without butchering git source code. We're going through sort of the same process already, separating machine-readable strings and translatable strings. Maybe we can learn something before deciding whether to add the team string class. > So for the time being, I would rather choose LANG=C as a lingua franca > and err on the side of interoperability with other people and not > translating. And then if and when somebody feels like putting the effort > into doing i18n.projectlang by splitting out a third category, they are > welcome to. I just do not see much point in doing i18n.projectlang any > other way. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/2] Mixing English and a local language
On Fri, Sep 14, 2012 at 5:41 PM, Michael J Gruber wrote: > For those proficient in 2 languages it's desirable to switch per project > because it's likely they participate in projects with different $LANG > preferences. Again, that means localizing everything(*). Additionally, > setting core.i18n in global config is probably the better choice > (compared to NO_GETTEXT=y) for those who are frustrated by git's > translation in their usual $LANG. > > [git svn should pass that LANG to svn also etc.] We should honor LINGUAS variable on installation. Only languages listed in that variable are installed. Many if not most of projects do that already. That's probably better than yet another switch. > The question is whether we have people who prefer to work with git in > their $LANG even though project interaction requires a different > language. They would probably run log/gitk/commit... in their $LANG but > need format-patch and the like in project-lang. > > I do think we have people in this category here on the list, so they > should speak up ;) Could they alias their format-patch to use "-c > core.i18n=C" or such? Or have .i18n on top? per-command config > again ;) Probably not needed, but probably won't hurt repeating: I do :) And things should just work, at least most of the time. When I set LANG, I prefer to have everything in $LANG unless required otherwise (sending to English speaking teams is one of them). But the exceptions should be limited. On Fri, Sep 14, 2012 at 12:52 AM, Junio C Hamano wrote: > You seem to be saying that diagnostic does not have to be in project > language, but I do not think it is the right thing to do. The first > response to "Frotz does not work" is often "What do you exactly > mean? How did you run Frotz? What error message are you getting > from it?", and you do not want to get back the diagnostics ints > Klingon. Whether you like it or not, all localized software has this problem. Perhaps the only difference with commercial software is that they have support line that also understands Klingon. I don't see any problems with asking the reporter to translate error messages back to English, assume that they report in English so they do know English. Given a specific context, Klingon illiterates can even manually revert Klingon text back to English because we have the all the translations. But it's probably faster to just ask the reporter. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's the point of saying "HEAD is now at ..."?
Junio C Hamano venit, vidit, dixit 14.09.2012 07:14:
> I sometimes wonder what value the message is giving us.
>
> For example, while reviewing a patch in my Emacs session, I may say
>
> | git am -s3c
>
> which runs the command on the contents of the e-mail I am reading,
> to apply the patch. After that, I would go to a separate terminal
> and do things like "git show -U20", etc. Once I am done, I reset
> the temporary commit away, and get this:
>
> $ git reset --hard HEAD^
> HEAD is now at ce5cf6f Merge git://github.com/git-l10n/git-po
>
> or often it is
>
> $ git reset --hard ko/master
> HEAD is now at ce5cf6f Merge git://github.com/git-l10n/git-po
>
> In either case, I know where I am resetting to, so "HEAD is now at"
> is a less than useful noise. If it contained "HEAD was at ...", it
> may let me realize that I was still going to use the contents in
> some other way and quickly go back to it with another reset, with
> cut and paste or with HEAD@{1}. In either case, showing the tip of
> what I just discarded seems to be a lot more useful information than
> what we are currently giving the users.
>
Unless you use a git aware prompt, it's always good to know where your
HEAD is ;) Just think of:
git reset --hard HEAD^2
HEAD is now at ...
Oh, I meant HEAD~2 aka HEAD^^ ...
In that case, information about HEAD@{1} might be useful but is not
necessary, unless you are leaving behind a detached HEAD.
Cheers,
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
Re: [PATCH RFC 0/2] Mixing English and a local language
Jeff King venit, vidit, dixit 13.09.2012 20:00: > On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote: > >>> But it should not be per-command, but per-message, and >>> should include all output that is not diagnostic and is not >>> machine-parseable (e.g., what I mentioned above, request-pull >>> output, etc). If it is the project's language, then the team >>> members will need to know it anyway, so it should not be too big a >>> burden to have a potentially different language there than in the >>> diagnostic messages. >> >> No matter what the project languages is, machine parseable part will >> not be localized but fixed to "C" anyway, so I do not think it comes >> into the picture. > > But there are parts that are neither machine-parseable nor diagnostics. > The diffstat is one, but I mentioned others. Are those going to be > forever fixed to LANG=C? > > That does not bother me, but for a project whose team works entirely in > Japanese (both individually, and when sharing code), they will still be > stuck with these English-language snippets, and no way to localize them. > Even though they may not speak a word of it. > > I have no idea if such a team is a strawman or not; that is why I > separated points 1 and 2. We can wait on point 2 until such a team shows > up and complains (of course, they would have to come here and complain > in English, so...). > >> My take on this is, if there is the project language, it should >> apply to _everything_. Please do not introduce any per-command, >> per-message, per-anything mess. Just set LANG/LC_ALL up and be done >> with it. > > But isn't that arguing for localizing diffstat? It is not > machine-parseable, so an all-Japanese team would want to localize it > along with their diagnostics. > > -Peff > The basic assumption is that we have people who are proficient in at least 2 languages. In fact, the initial i18n efforts were targeted at people who are much more comfortable in their $LANG than with LANG=C. For this category, being able to localize everything(*) is important. They will mostly work with $LANG projects. I don't think they're strawmen. For those proficient in 2 languages it's desirable to switch per project because it's likely they participate in projects with different $LANG preferences. Again, that means localizing everything(*). Additionally, setting core.i18n in global config is probably the better choice (compared to NO_GETTEXT=y) for those who are frustrated by git's translation in their usual $LANG. [git svn should pass that LANG to svn also etc.] The question is whether we have people who prefer to work with git in their $LANG even though project interaction requires a different language. They would probably run log/gitk/commit... in their $LANG but need format-patch and the like in project-lang. I do think we have people in this category here on the list, so they should speak up ;) Could they alias their format-patch to use "-c core.i18n=C" or such? Or have .i18n on top? per-command config again ;) 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
Re: Failing svn imports from apache.org
Enrico Weigelt venit, vidit, dixit 13.09.2012 15:32: > Hi folks, > > I'm currently trying to import apache.org svn server, without success. > See: > > git@moonshine:~/projects/common/libs$ git svn clone --stdlayout > http://svn.apache.org/repos/asf/commons/proper/discovery/ > Initialized empty Git repository in > /home/git/projects/common/libs/discovery/.git/ > W: Ignoring error from SVN, path probably does not exist: (160013): > Filesystem has no item: '/repos/asf/!svn/bc/100/commons/proper/discovery' > path not found > W: Do not be alarmed at the above message git-svn is just searching > aggressively for old history. > This may take a while on large repositories > mkdir .git: No such file or directory at /usr/lib/git-core/git-svn line 3669 > > Does anyone have an idea, what might be wrong here / how to fix it ? Here: git svn --version git-svn version 1.7.12.592.g41e7905 (svn 1.6.18) What's yours? I'm getting Initialized empty Git repository in /tmp/discovery/.git/ Using higher level of URL: http://svn.apache.org/repos/asf/commons/proper/discovery => http://svn.apache.org/repos/asf W: Ignoring error from SVN, path probably does not exist: (160013): Dateisystem hat keinen Eintrag: File not found: revision 100, path '/commons/proper/discovery' W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. This may take a while on large repositories and then it checks the revisions. I didn't want to wait for r1301705... Does your git svn abort earlier or after checking all revs? -- 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
[PATCHv3 07/11] t7810-grep: bring log --grep tests in common form
The log --grep tests generate the expected out in different ways.
Make them all use command blocks so that subshells are avoided and the
expected output is easier to grasp visually.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 24e9b19..180e998 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -435,31 +435,41 @@ test_expect_success 'log grep setup' '
test_expect_success 'log grep (1)' '
git log --author=author --pretty=tformat:%s >actual &&
- ( echo third ; echo initial ) >expect &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (2)' '
git log --author=" * " -F --pretty=tformat:%s >actual &&
- ( echo second ) >expect &&
+ {
+ echo second
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (3)' '
git log --author="^A U" --pretty=tformat:%s >actual &&
- ( echo third ; echo initial ) >expect &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (4)' '
git log --author="frotz\.com>$" --pretty=tformat:%s >actual &&
- ( echo second ) >expect &&
+ {
+ echo second
+ } >expect &&
test_cmp expect actual
'
test_expect_success 'log grep (5)' '
git log --author=Thor -F --pretty=tformat:%s >actual &&
- ( echo third ; echo initial ) >expect &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
@@ -473,7 +483,9 @@ test_expect_success 'log --grep --author implicitly uses
all-match' '
# grep matches initial and second but not third
# author matches only initial and third
git log --author="A U Thor" --grep=s --grep=l --format=%s >actual &&
- echo initial >expect &&
+ {
+ echo initial
+ } >expect &&
test_cmp expect actual
'
--
1.7.12.592.g41e7905
--
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
[PATCHv3 09/11] t7810-grep: test multiple --author with --all-match
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index b841909..be81d96 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -513,6 +513,14 @@ test_expect_success 'log with multiple --author uses
union' '
test_cmp expect actual
'
+test_expect_success 'log --all-match with multiple --author still uses union' '
+ git log --all-match --author="Thor" --author="Aster" --format=%s
>actual &&
+ {
+ echo third && echo second && echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'log with --grep and multiple --author uses all-match' '
git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
{
--
1.7.12.592.g41e7905
--
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
[PATCHv3 11/11] t7810-grep: test --all-match with multiple --grep and --author options
--all-match is ignored with multiple author options on purpose but
requires all --grep to be matched on some line.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index f6edb4d..b5c488e 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -531,6 +531,16 @@ test_expect_success 'log --grep --grep --author takes
union of greps and interse
test_cmp expect actual
'
+test_expect_success 'log ---all-match -grep --author --author still takes
union of authors and intersects with grep' '
+ # grep matches only initial and third
+ # author matches all but second
+ git log --all-match --author="Thor" --author="Night" --grep=i
--format=%s >actual &&
+ {
+ echo third && echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'log --grep --author --author takes union of authors and
intersects with grep' '
# grep matches only initial and third
# author matches all but second
@@ -541,6 +551,16 @@ test_expect_success 'log --grep --author --author takes
union of authors and int
test_cmp expect actual
'
+test_expect_success 'log --all-match --grep --grep --author takes
intersection' '
+ # grep matches only third
+ # author matches only initial and third
+ git log --all-match --author="A U Thor" --grep=i --grep=r --format=%s
>actual &&
+ {
+ echo third
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'grep with CE_VALID file' '
git update-index --assume-unchanged t/t &&
rm t/t &&
--
1.7.12.592.g41e7905
--
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
[PATCHv3 10/11] t7810-grep: test interaction of multiple --grep and --author options
There are tests for this interaction already. Restructure slightly and
avoid any claims about --all-match.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index be81d96..f6edb4d 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -495,16 +495,6 @@ test_expect_success 'log --all-match with multiple --grep
uses intersection' '
test_cmp expect actual
'
-test_expect_success 'log --grep --author implicitly uses all-match' '
- # grep matches initial and second but not third
- # author matches only initial and third
- git log --author="A U Thor" --grep=s --grep=l --format=%s >actual &&
- {
- echo initial
- } >expect &&
- test_cmp expect actual
-'
-
test_expect_success 'log with multiple --author uses union' '
git log --author="Thor" --author="Aster" --format=%s >actual &&
{
@@ -521,17 +511,33 @@ test_expect_success 'log --all-match with multiple
--author still uses union' '
test_cmp expect actual
'
-test_expect_success 'log with --grep and multiple --author uses all-match' '
- git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
+test_expect_success 'log --grep --author uses intersection' '
+ # grep matches only third and fourth
+ # author matches only initial and third
+ git log --author="A U Thor" --grep=r --format=%s >actual &&
{
- echo third && echo initial
+ echo third
} >expect &&
test_cmp expect actual
'
-test_expect_success 'log with --grep and multiple --author uses all-match' '
- git log --author="Thor" --author="Night" --grep=q --format=%s >actual &&
- >expect &&
+test_expect_success 'log --grep --grep --author takes union of greps and
intersects with author' '
+ # grep matches initial and second but not third
+ # author matches only initial and third
+ git log --author="A U Thor" --grep=s --grep=l --format=%s >actual &&
+ {
+ echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --grep --author --author takes union of authors and
intersects with grep' '
+ # grep matches only initial and third
+ # author matches all but second
+ git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
+ {
+ echo third && echo initial
+ } >expect &&
test_cmp expect actual
'
--
1.7.12.592.g41e7905
--
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
[PATCHv3 08/11] t7810-grep: test multiple --grep with and without --all-match
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 180e998..b841909 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -479,6 +479,22 @@ test_expect_success 'log grep (6)' '
test_cmp expect actual
'
+test_expect_success 'log with multiple --grep uses union' '
+ git log --grep=i --grep=r --format=%s >actual &&
+ {
+ echo fourth && echo third && echo initial
+ } >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --all-match with multiple --grep uses intersection' '
+ git log --all-match --grep=i --grep=r --format=%s >actual &&
+ {
+ echo third
+ } >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'log --grep --author implicitly uses all-match' '
# grep matches initial and second but not third
# author matches only initial and third
--
1.7.12.592.g41e7905
--
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
[PATCHv3 03/11] grep: show --debug output only once
When threaded grep is in effect, the patterns are duplicated and recompiled for each thread. Avoid "--debug" output during the recompilation so that the output is given once instead of "1+nthreads" times. Signed-off-by: Michael J Gruber --- builtin/grep.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/grep.c b/builtin/grep.c index 8aea00c..a7e8df0 100644 --- a/builtin/grep.c +++ b/builtin/grep.c @@ -209,6 +209,7 @@ static void start_threads(struct grep_opt *opt) int err; struct grep_opt *o = grep_opt_dup(opt); o->output = strbuf_out; + o->debug = 0; compile_grep_patterns(o); err = pthread_create(&threads[i], NULL, run, o); -- 1.7.12.592.g41e7905 -- 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
[PATCHv3 06/11] fixup! log: document use of multiple commit limiting options
Here are a few typo fixes. There is a mix of single and back ticks already before this patch, i.e. ` vs. ' -- I thought we had guidelines for this but don't find them at the moment. Signed-off-by: Michael J Gruber --- Documentation/rev-list-options.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 57d6c90..c828408 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -6,12 +6,12 @@ special notations explained in the description, additional commit limiting may be applied. Using more options generally further limits the output (e.g. -"--since=" limits to commits newer than , and using it -with "--grep=" further limits to commits whose log message -has a line that match ), unless otherwise noted. +`--since=` limits to commits newer than ``, and using it +with `--grep=` further limits to commits whose log message +has a line that matches ``), unless otherwise noted. Note that these are applied before commit -ordering and formatting options, such as '--reverse'. +ordering and formatting options, such as `--reverse`. -- @@ -47,7 +47,7 @@ endif::git-rev-list[] Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression). With more than one `--author=`, - commits whose author match any of the given patterns are + commits whose author matches any of the given patterns are chosen (similarly for multiple `--committer=`). --grep=:: @@ -55,7 +55,7 @@ endif::git-rev-list[] Limit the commits output to ones with log message that matches the specified pattern (regular expression). With more than one `--grep=`, commits whose message - match any of the given patterns are chosen (but see + matches any of the given patterns are chosen (but see `--all-match`). --all-match:: -- 1.7.12.592.g41e7905 -- 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
[PATCHv3 05/11] log: document use of multiple commit limiting options
From: Junio C Hamano Generally speaking, using more options will further narrow the selection, but there are a few exceptions. Document them. Signed-off-by: Junio C Hamano Signed-off-by: Michael J Gruber --- Documentation/rev-list-options.txt | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 1ae3c89..57d6c90 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -3,7 +3,14 @@ Commit Limiting Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit -limiting may be applied. Note that they are applied before commit +limiting may be applied. + +Using more options generally further limits the output (e.g. +"--since=" limits to commits newer than , and using it +with "--grep=" further limits to commits whose log message +has a line that match ), unless otherwise noted. + +Note that these are applied before commit ordering and formatting options, such as '--reverse'. -- @@ -38,16 +45,22 @@ endif::git-rev-list[] --committer=:: Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular expression). + header lines that match the specified pattern (regular + expression). With more than one `--author=`, + commits whose author match any of the given patterns are + chosen (similarly for multiple `--committer=`). --grep=:: Limit the commits output to ones with log message that - matches the specified pattern (regular expression). + matches the specified pattern (regular expression). With + more than one `--grep=`, commits whose message + match any of the given patterns are chosen (but see + `--all-match`). --all-match:: Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + instead of ones that match at least one. -i:: --regexp-ignore-case:: -- 1.7.12.592.g41e7905 -- 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
[PATCHv3 04/11] log --grep/--author: honor --all-match honored for multiple --grep patterns
From: Junio C Hamano
Earlier, when we have both header expression (which has to be an OR
node by construction) and a pattern expression (which could be
anything), we created a top-level OR node that looks like this to
bind them together:
OR
/ \
/\
patternOR
/ \ / \
.committerOR
/ \
author TRUE
In other words, the three elements on the top-level backbone that
were inspected by the "all-match" logic are "pattern", "committer"
and "author". When there are more than one elements in the
"pattern", the top-level node of it is that OR, so that node is
inspected by "all-match", hence the result ends up ignoring the
"--all-match" given from the command line. A match on either side
of the pattern was considered a match, hence
git log --grep=A --grep=B --author=C --all-match
showed the same "authored by C and has either A or B" with or
without --all-match.
This patch turns the grep expression into this form:
OR
/ \
/ \
/ OR
committer/\
author\
pattern
when "--all-match" was given from the command line. This way, the
set of nodes on the top-level backbone in the resulting expression
consists of "committer", "author", and whatever nodes were on the
top-level backbone of the "pattern" expression. The "all-match"
logic inspects the same nodes in "pattern" as the case without the
author and/or the committer restriction.
Signed-off-by: Junio C Hamano
Signed-off-by: Michael J Gruber
---
grep.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/grep.c b/grep.c
index be15c47..925aa92 100644
--- a/grep.c
+++ b/grep.c
@@ -476,6 +476,22 @@ static struct grep_expr *prep_header_patterns(struct
grep_opt *opt)
return header_expr;
}
+static struct grep_expr *grep_splice_or(struct grep_expr *x, struct grep_expr
*y)
+{
+ struct grep_expr *z = x;
+
+ while (x) {
+ assert(x->node == GREP_NODE_OR);
+ if (x->u.binary.right &&
+ x->u.binary.right->node == GREP_NODE_TRUE) {
+ x->u.binary.right = y;
+ break;
+ }
+ x = x->u.binary.right;
+ }
+ return z;
+}
+
static void compile_grep_patterns_real(struct grep_opt *opt)
{
struct grep_pat *p;
@@ -510,6 +526,9 @@ static void compile_grep_patterns_real(struct grep_opt *opt)
if (!opt->pattern_expression)
opt->pattern_expression = header_expr;
+ else if (opt->all_match)
+ opt->pattern_expression = grep_splice_or(header_expr,
+
opt->pattern_expression);
else
opt->pattern_expression = grep_or_expr(opt->pattern_expression,
header_expr);
--
1.7.12.592.g41e7905
--
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
[PATCHv3 02/11] log: name --debug-grep option like in the commit message
Signed-off-by: Michael J Gruber
---
revision.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index 90376e8..fad8040 100644
--- a/revision.c
+++ b/revision.c
@@ -1578,7 +1578,7 @@ static int handle_revision_opt(struct rev_info *revs, int
argc, const char **arg
} else if ((argcount = parse_long_opt("grep", argv, &optarg))) {
add_message_grep(revs, optarg);
return argcount;
- } else if (!strcmp(arg, "--grep-debug")) {
+ } else if (!strcmp(arg, "--debug-grep")) {
revs->grep_filter.debug = 1;
} else if (!strcmp(arg, "--extended-regexp") || !strcmp(arg, "-E")) {
revs->grep_filter.regflags |= REG_EXTENDED;
--
1.7.12.592.g41e7905
--
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
[PATCHv3 01/11] grep: teach --debug option to dump the parse tree
From: Junio C Hamano
Our "grep" allows complex boolean expressions to be formed to match
each individual line with operators like --and, '(', ')' and --not.
Introduce the "--debug" option to show the parse tree to help people
who want to debug and enhance it.
Also "log" learns "--debug-grep" option to do the same. The command
line parser to the log family is a lot more limited than the general
"git grep" parser, but it has special handling for header matching
(e.g. "--author"), and a parse tree is valuable when working on it.
Note that "--all-match" is *not* any individual node in the parse
tree. It is an instruction to the evaluator to check all the nodes
in the top-level backbone have matched and reject a document as
non-matching otherwise.
Signed-off-by: Junio C Hamano
Signed-off-by: Michael J Gruber
---
builtin/grep.c | 3 ++
grep.c | 92 --
grep.h | 1 +
revision.c | 2 ++
4 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index fe1726f..8aea00c 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -772,6 +772,9 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
"indicate hit with exit status without output"),
OPT_BOOLEAN(0, "all-match", &opt.all_match,
"show only matches from files that match all patterns"),
+ { OPTION_SET_INT, 0, "debug", &opt.debug, NULL,
+ "show parse tree for grep expression",
+ PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 1 },
OPT_GROUP(""),
{ OPTION_STRING, 'O', "open-files-in-pager", &show_in_pager,
"pager", "show matching files in the pager",
diff --git a/grep.c b/grep.c
index 04e3ec6..be15c47 100644
--- a/grep.c
+++ b/grep.c
@@ -332,6 +332,87 @@ static struct grep_expr *compile_pattern_expr(struct
grep_pat **list)
return compile_pattern_or(list);
}
+static void indent(int in)
+{
+ while (in-- > 0)
+ fputc(' ', stderr);
+}
+
+static void dump_grep_pat(struct grep_pat *p)
+{
+ switch (p->token) {
+ case GREP_AND: fprintf(stderr, "*and*"); break;
+ case GREP_OPEN_PAREN: fprintf(stderr, "*(*"); break;
+ case GREP_CLOSE_PAREN: fprintf(stderr, "*)*"); break;
+ case GREP_NOT: fprintf(stderr, "*not*"); break;
+ case GREP_OR: fprintf(stderr, "*or*"); break;
+
+ case GREP_PATTERN: fprintf(stderr, "pattern"); break;
+ case GREP_PATTERN_HEAD: fprintf(stderr, "pattern_head"); break;
+ case GREP_PATTERN_BODY: fprintf(stderr, "pattern_body"); break;
+ }
+
+ switch (p->token) {
+ default: break;
+ case GREP_PATTERN_HEAD:
+ fprintf(stderr, "", p->field); break;
+ case GREP_PATTERN_BODY:
+ fprintf(stderr, ""); break;
+ }
+ switch (p->token) {
+ default: break;
+ case GREP_PATTERN_HEAD:
+ case GREP_PATTERN_BODY:
+ case GREP_PATTERN:
+ fprintf(stderr, "%.*s", (int)p->patternlen, p->pattern);
+ break;
+ }
+ fputc('\n', stderr);
+}
+
+static void dump_grep_expression_1(struct grep_expr *x, int in)
+{
+ indent(in);
+ switch (x->node) {
+ case GREP_NODE_TRUE:
+ fprintf(stderr, "true\n");
+ break;
+ case GREP_NODE_ATOM:
+ dump_grep_pat(x->u.atom);
+ break;
+ case GREP_NODE_NOT:
+ fprintf(stderr, "(not\n");
+ dump_grep_expression_1(x->u.unary, in+1);
+ indent(in);
+ fprintf(stderr, ")\n");
+ break;
+ case GREP_NODE_AND:
+ fprintf(stderr, "(and\n");
+ dump_grep_expression_1(x->u.binary.left, in+1);
+ dump_grep_expression_1(x->u.binary.right, in+1);
+ indent(in);
+ fprintf(stderr, ")\n");
+ break;
+ case GREP_NODE_OR:
+ fprintf(stderr, "(or\n");
+ dump_grep_expression_1(x->u.binary.left, in+1);
+ dump_grep_expression_1(x->u.binary.right, in+1);
+ indent(in);
+ fprintf(stderr, ")\n");
+ break;
+ }
+}
+
+void dump_grep_expression(struct grep_opt *opt)
+{
+ struct grep_expr *x = opt->pattern_expression;
+
+ if (opt->all_match)
+ fprintf(stderr, "[all-match]\n");
+ dump_grep_expression_1(x, 0);
+ fflush(NULL);
+}
+
static struct grep_expr *grep_true_expr(void)
{
struct grep_expr *z = xcalloc(1, sizeof(*z));
@@ -395,7 +476,7 @@ static struct grep_expr *prep_header_patterns(struct
grep_opt *opt)
return header_expr;
}
-void compile_grep_patterns(struct grep_opt *opt)
+static void compile_grep_patterns_real(struct grep_opt *opt)
{
struct grep_pat *p;
struct grep_expr *header_e
[PATCHv3 00/11] rev-list/log: document logic with several limiting options
In v3 I've rebased my tests on top of Junio's commits which change --all-match handling and provide a better documentation. Accordingly, 6/6 from v2 is dropped and 5/5 adjusted (expect_failure -> expect_success). I'm sending out Junio's commits as in pu along with 3 intermixed fixups which you may squash in freely. (I've only marked the more obvious one as fixup!.) The last 5 are my rebased tests as described above. [This approach seemed to be more convenient; hopefully for everyone ;)] Junio C Hamano (3): grep: teach --debug option to dump the parse tree log --grep/--author: honor --all-match honored for multiple --grep patterns log: document use of multiple commit limiting options Michael J Gruber (8): log: name --debug-grep option like in the commit message grep: show --debug output only once fixup! log: document use of multiple commit limiting options t7810-grep: bring log --grep tests in common form t7810-grep: test multiple --grep with and without --all-match t7810-grep: test multiple --author with --all-match t7810-grep: test interaction of multiple --grep and --author options t7810-grep: test --all-match with multiple --grep and --author options Documentation/rev-list-options.txt | 23 ++-- builtin/grep.c | 4 ++ grep.c | 111 - grep.h | 1 + revision.c | 2 + t/t7810-grep.sh| 90 +- 6 files changed, 210 insertions(+), 21 deletions(-) -- 1.7.12.592.g41e7905 -- 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] rev-list/log: document logic with several limiting options
Oh, my gosh, it's not as early as this indicates, rather coffein depletion already: > Message-ID: <5052e1c2.1050...@pobox.com> > Date: Fri, 14 Sep 2012 09:50:26 +0200 > From: Junio C Hamano > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 > Thunderbird/15.0 [no, that Thunderbird user isn't Junio] > MIME-Version: 1.0 > To: Michael J Gruber > CC: git@vger.kernel.org > Subject: Re: [PATCH] rev-list/log: document logic with several limiting > options > Michael J Gruber venit, vidit, dixit 14.09.2012 09:46: > [snipped, just adding] > > ...and maybe the meaning of "(or ...)" and "*or*" isn't what I think it > is either? [and that confused persion isn't Junio either] I didn't mean to imposter Junio. Something went wrong with "virtual identity" choosing the From: address. Terribly sorry. Michael (really...) -- 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 3/6] t7810-grep: test multiple --author with --all-match
Junio C Hamano venit, vidit, dixit 14.09.2012 01:26:
> Junio C Hamano writes:
>
>> One possible improvement we can make is to parse the command line in
>> the last example with "--all-match" to
>>
>> [all-match]
>> (or
>> pattern_bodycommit
>> (or
>> pattern_bodytag
>> (or
>>pattern_headLinus
>>(or
>> pattern_headJunio
>> true
>>)
>> )
>> )
>> )
>>
>> so that the backbone becomes
>>
>> - Mentions commit,
>> - Mentions tag,
>> - Committed by Linus,
>> - Authored by Junio
>>
>> to require that both commit and tag are mentioned in the message.
>
> And this is an attempt to do exactly that. Earlier, when we have
> both header expression (which by the way has to be an OR node by
> construction) and pattern expression (which could be anything), we
> created a top-level OR node (again, look at this as if you are
> reading LISP),
>
>OR
> /\
>/ \
>patternOR
> / \ / \
> .committerOR
> / \
> author TRUE
>
> in other words, the three elements on the top-level backbone are
> "pattern", "committer" and "author"; when there are more than one
> elements in the "pattern", the top-level node of it is OR, so that
> node is inspected by "all-match", hence the result ends up ignoring
> the "--all-match" given from the command line.
>
> This patch turns it into
>
>OR
> / \
> / \
> / OR
> committer/\
> author\
>pattern
>
> when "--all-match" was given from the command line, so that the
> "committer", "author" and elements on the top-level backbone in
> "pattern" form the top-level backbone of the resulting expression to
> be inspected by the "all-match" logic.
>
> Does this pass the expect-failure test in your [PATCH 5/6]?
Just a quick heads up:
I merged 38ed8ef (log --grep/--author: honor --all-match honored for
multiple --grep patterns, 2012-09-13) from pu into my test branch,
and this fixes what I had marked as known failure there. Thanks!
[I still have to figure out the logic, but begin to understand that
"(OR...) and "(AND...)" are linewise, and all-match is a bufferwise AND
or something. Now, what is "*or*" ...]
> grep.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git c/grep.c w/grep.c
> index be15c47..925aa92 100644
> --- c/grep.c
> +++ w/grep.c
> @@ -476,6 +476,22 @@ static struct grep_expr *prep_header_patterns(struct
> grep_opt *opt)
> return header_expr;
> }
>
> +static struct grep_expr *grep_splice_or(struct grep_expr *x, struct
> grep_expr *y)
> +{
> + struct grep_expr *z = x;
> +
> + while (x) {
> + assert(x->node == GREP_NODE_OR);
> + if (x->u.binary.right &&
> + x->u.binary.right->node == GREP_NODE_TRUE) {
> + x->u.binary.right = y;
> + break;
> + }
> + x = x->u.binary.right;
> + }
> + return z;
> +}
> +
> static void compile_grep_patterns_real(struct grep_opt *opt)
> {
> struct grep_pat *p;
> @@ -510,6 +526,9 @@ static void compile_grep_patterns_real(struct grep_opt
> *opt)
>
> if (!opt->pattern_expression)
> opt->pattern_expression = header_expr;
> + else if (opt->all_match)
> + opt->pattern_expression = grep_splice_or(header_expr,
> +
> opt->pattern_expression);
> else
> opt->pattern_expression = grep_or_expr(opt->pattern_expression,
> header_expr);
>
--
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] rev-list/log: document logic with several limiting options
Michael J Gruber venit, vidit, dixit 14.09.2012 09:46: [snipped, just adding] ...and maybe the meaning of "(or ...)" and "*or*" isn't what I think it is either? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rev-list/log: document logic with several limiting options
Junio C Hamano venit, vidit, dixit 13.09.2012 23:21:
> Michael J Gruber writes:
>
>> Thanks for "this" ;)
>
> Here is a replacement to "this", that adds the "--debug" option to
> "git grep" and an equivalent "--debug-grep" to "git log" family.
>
> -- >8 --
> Subject: [PATCH] grep: teach --debug option to dump the parse tree
>
> Our "grep" allows complex boolean expressions to be formed to match
> each individual line with operators like --and, '(', ')' and --not.
> Introduce the "--debug" option to show the parse tree to help people
> who want to debug and enhance it.
>
> Also "log" learns "--debug-grep" option to do the same. The command
> line parser to the log family is a lot more limited than the general
> "git grep" parser, but it has special handling for header matching
> (e.g. "--author"), and a parse tree is valuable when working on it.
>
> Note that "--all-match" is *not* any individual node in the parse
> tree. It is an instruction to the evaluator to check all the nodes
> in the top-level backbone have matched and reject a document as
> non-matching otherwise.
I haven't read all your responses yet, but the/my main confusion comes
from all-match. My understanding is:
--all-match == turn all top-level ORs into ANDs
(unless it's all --author at the top-level; and I'm referring to user
supplied ORs, not those added by the implementation)
Seing (OR foo true) being evaluated to false when foo is false and
all-match is in effect is terribly confusing, me thinks (debug output).
In fact, I think the behavior described above (if it's correct) is a
product of the evolution of grep.c and the current implementation
(turning former unions into intersections in some cases, inserting that
TRUE node), but not necessarily the intended or preferrable outcome in
all corner cases.
We AND different types of limit options in any case (this used to be
affected by --all-match[?]), and we OR --author options in any case. So
having --all-match turn "--grep=foo --grep=bar" from OR into AND would
make the most sense at least to me (and I mean: independent of the
presence of an --author option).
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
Re: Suggestions for "What's cooking"
On 09/14/2012 06:47 AM, Junio C Hamano wrote: > So here is how tonight's "What's cooking" may look like with extra > indentation and blank lines. [...] I find this much more readable than the old format. Thanks! Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
