* Re: [PATCH 0/4] Remove a user of extra_refs in clone
From: Junio C Hamano @ 2012-01-17 6:51 UTC (permalink / raw)
To: mhagger; +Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
Yay ;-)
Thanks.
^ permalink raw reply
* Re: [PATCHv3 10/13] credentials: add "cache" helper
From: Junio C Hamano @ 2012-01-17 6:51 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jonathan Nieder
In-Reply-To: <20120117060232.GA27343@sigill.intra.peff.net>
Thanks, really appreciated.
^ permalink raw reply
* Re: Cannot push a commit
From: Matthias Fechner @ 2012-01-17 7:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120116212036.GA21132@sigill.intra.peff.net>
Am 16.01.2012 22:20, schrieb Jeff King:
> 1. Something in the connection cut out but only in a half-duplex way.
> I guess I could see ssh doing that if its input pipe closed, but
> that would mean the local pack-objects failed, and I believe git
> already detects and reports that case.
>
> 2. The packfile sent indicated that it should have more bytes than it
> does (i.e., either git indicated there were more objects than there
> actually are, or zlib failed to give a stream-end marker in the
> middle of an object). This is one of:
>
> a. A bug in git or zlib.
>
> b. Something in the connection corrupting the data (e.g., a
> transport that is not 8-bit clean).
>
> But in either 2a or 2b, I would expect us to have seen this before, and
> I don't recall seeing anything like it.
>
> You could try generating a bundle with this pack, like:
>
> git bundle create foo.bundle master ^origin/master
>
> and then shipping the resulting foo.bundle to the other side, and
> pulling from it like:
>
> git pull /path/to/foo.bundle master
thanks a lot for your answer.
I created a new repository which is not a bare repo to use your commands
posted above (i tested it with the normal push command from the client
and same error).
I created the bundle on the client, copied it with winscp to the server
and it was applied fine to the repository:
$ git pull ../foo.bundle master
Receiving objects: 100% (3/3), 91.63 KiB, done.
From ../foo.bundle
* branch master -> FETCH_HEAD
Updating 53b9b5e..301e730
Fast-forward
APP_UD.sch |19643
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 19643 insertions(+), 0 deletions(-)
create mode 100644 APP_UD.sch
So the problem should be located anywhere else.
I tested now the same on a mac osx as client and there everything works
as expected, I added the file, commited it and pushed it without errors
to the server.
So the problem has something to do with windows as client. I will do
some additional test this evening.
Where can we continue to search?
Bye
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-17 7:41 UTC (permalink / raw)
To: Jeff King; +Cc: Holger Hellmuth, git, Carlos Martín Nieto
In-Reply-To: <20120116212709.GA21770@sigill.intra.peff.net>
On 16.01.2012 22:27 CE(S)T, Jeff King wrote:
> On Mon, Jan 16, 2012 at 10:20:42PM +0100, Yves Goergen wrote:
>
>> On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
>>> What is the output of "git config core.ignorecase" in your repository?
>> None, i.e. an empty line.
>
> That's odd. When the repository is first created, git will do a test to
> see whether the filesystem supports case-sensitivity, and will set
> core.ignorecase if it does not. Might this repository have been created
> on a different filesystem, and then moved onto the case-insensitive
> filesystem?
>
> Or might it have been created by something other than core git? I don't
> know whether one can create a repo in TortoiseGit, or if so how it does
> so.
It may have been created through the Visual Studio source provider for
Git, which is configured to use TortoiseGit which in turn uses msysGit.
But I have not written any of those programmes so I cannot guarantee for
what they do.
> In any case, try doing:
>
> git config core.ignorecase true
>
> and see if that clears up your problems.
'git config core.ignorecase' now outputs "true" but I can still commit
the same file (modified) twice. So this doesn't help.
Meanwhile I have browsed my other code projects and found that the
designer-generated file name is sometimes with a "D" and sometimes with
a "d", so it's usually inconsistent. I haven't figured out where that
comes from but it means that this is a common issue that Git needs to
handle well to be usable on Windows. But we're not there yet.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: [PATCH] merge: Make merge strategy message follow the diffstat
From: Miles Bader @ 2012-01-17 8:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nguyen Thai Ngoc Duy, Junio C Hamano, Paul Gortmaker, Mark Brown,
Liam Girdwood, linux-kernel, Git Mailing List
In-Reply-To: <CA+55aFxw_-0h1FDmPRVif3LM03Qh3-6haA7=KYbae8pSFbpW2w@mail.gmail.com>
So ... "--shortish-diffthingy"
-miles
--
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.
^ permalink raw reply
* [PATCH] test-lib: add the test_pause convenience function
From: Jens Lehmann @ 2012-01-17 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git Mailing List, Pete Wyckoff
In-Reply-To: <7vk44ruupe.fsf@alter.siamese.dyndns.org>
Since 781f76b15 (test-lib: redirect stdin of tests) you can't simply put a
"bash &&" into a test for debugging purposes anymore. Instead you'll have
to use "bash <&6 >&3 2>&4".
As that invocation is not that easy to remember add the test_pause
convenience function. This function also checks if the -v flag is given
and will error out if that is not the case instead of letting the test
hang until ^D is pressed.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 16.01.2012 23:51, schrieb Junio C Hamano:
> Jeff King <peff@peff.net> writes:
>
>> Nice. Many times I have added such a "bash" or "gdb" invocation then
>> forgotten "-v", only to scratch my head at why the test seemed to be
>> hanging.
>>
>> Two minor nits on the patch itself:
>> ...
>> 1. It may be worth putting a warning in the comment that this is never
>> to be used in a real test, but only temporarily inserted.
>>
>> 2. I do this not just with bash, but with "gdb". I wonder if it is worth
>> making this "test_foo bash", for some value of "foo" (the ones that
>> occur to me are "debug" and "run", but of course they are taken).
>>
>> Actually, I wonder if the existing test_debug could handle this
>> already (though you do have to remember to add "--debug" to your
>> command line, then).
>
> I wondered the same thing from a different angle. My first reaction was
> "Why is this called 'bash' not 'sh'?" which naturally led to the same
> direction as yours "why not an arbitrary command 'test_debug xxx'?"
>
> test_pause perhaps?
I really don't care deeply about the name, so test_pause is absolutely
ok for me. I added some documentation in t/README too and made it an
error when --verbose is not used.
Is it ok to invoke bash here or should sh be used?
t/README | 13 +++++++++++++
t/test-lib.sh | 13 +++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index c85abaf..c09c582 100644
--- a/t/README
+++ b/t/README
@@ -548,6 +548,19 @@ library for your script to use.
...
'
+ - test_pause
+
+ This command is useful for writing and debugging tests and must be
+ removed before submitting. It halts the execution of the test and
+ spawns a shell in the trash directory. Exit the shell to continue
+ the test. Example:
+
+ test_expect_success 'test' '
+ git do-something >actual &&
+ test_pause &&
+ test_cmp expected actual
+ '
+
Prerequisites
-------------
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a65dfc7..85084c4 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -329,6 +329,19 @@ test_tick () {
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
}
+# Stop execution and start a shell. This is useful for debugging tests and
+# only makes sense together with "-v".
+#
+# Be sure to remove all invocations of this command before submitting.
+
+test_pause () {
+ if test "$verbose" = t; then
+ bash <&6 >&3 2>&4
+ else
+ error >&5 "test_pause requires --verbose"
+ fi
+}
+
# Call test_commit with the arguments "<message> [<file> [<contents>]]"
#
# This will commit a file with the given contents and the given commit
--
1.7.9.rc1.2.g0b847.dirty
^ permalink raw reply related
* Re: Bug? Git checkout fails with a wrong error message
From: Thomas Rast @ 2012-01-17 8:45 UTC (permalink / raw)
To: Yves Goergen
Cc: Holger Hellmuth, Jeff King, Carlos Martín Nieto, git,
Erik Faye-Lund
In-Reply-To: <4F152767.9010104@unclassified.de>
Yves Goergen <nospam.list@unclassified.de> writes:
> On 16.01.2012 20:17 CE(S)T, Thomas Rast wrote:
>> If you work together with developers who have a case-sensitive FS (such
>> as Linux, or with the right options OS X), it's entirely possible that
>> this file exists in both spellings within the repository.
>
> Just FTR, I am working on the project alone, only on Windows with Visual
> Studio 2010 and I have two copies of the repository which I am
> occasionally synchronising via a USB memory stick when I work on the
> other machine. I have not pulled anything since the first issue came up
> on last Friday. No case-sensitive filesystem in the game.
Ok.
$ git ls-tree -r HEAD
100644 blob 5369994b8f905514661ee58b396dec31f8575a4d PosterWantsItCensored.Designer.cs
100644 blob 5369994b8f905514661ee58b396dec31f8575a4d PosterWantsItCensored.designer.cs
^ ^ ^
| | content hash
| type
file mode
That tells us that you have identical file contents in two files whose
names differ only in case.
This is important: Different name for git. Same name for OS. Same
contents.
That should also settle your remark at the end:
> I find it interesting to see that both files with the equal file name
> (like what the only relevant file system considers equal) have the same
> hash value. Does that qualify for your description of the "pretty bad bug"?
No, not a bug, just the same contents.
[And before you sue me for disclosing the SHA1 above: inferring the
contents of the file from the SHA1 is equivalent to breaking SHA1. If
anyone could, he'd already be busy writing a paper about it (or perhaps
working for the NSA).]
>> * You have the byte-for-byte identical file name listed twice in the
>> index. That would be a pretty bad bug.
>
> The index should usually be empty here, I guess. I really do not use
> it. No index interaction at all.
Please read up on the index before making such statements. You do use
the index, because it is a very important part of how git operates
whenever the operation also involves the worktree. And except in border
cases (new empty repo etc.) it should never be empty.
Your paste of
$ git status -s
[no output]
tells us that the index has *no differences* to your worktree, nor to
HEAD.
So in summary, the picture in your repository is:
* Somehow you got a different-only-in-case file pair into your
repository. It's already in HEAD. See below.
* The index and worktree are healthy and unchanged (w.r.t. HEAD) from
Git's POV. (This is possible despite the different-only-in-case files
because they have the same contents.)
For now I'm siding with Erik's theory
Erik Faye-Lund wrote:
} Very speculative comment: This might be a bug in TortoiseGit. Looking
} at the sources, it seems they are using libgit2 to mess around with
} the index; perhaps it's case-sensitivity code isn't as well tested as
} Git for Windows'?
It would also be interesting to know for how long this problem has
existed. You can search for the offending commit with something like
git log --name-status --diff-filter=A -- "PosterWantsItCensored.*"
which should normally give you just one or two commits, namely the
one(s) that introduced the two files.
As for the fix, there are two-and-two-thirds cases. First I'd like to
point out, however, that I have no idea how core.ignoreCase interacts
with rm --cached. I'm assuming you have to set it to 'false' for the
recipes below to work. Erik or Peff may correct me. You should set it
to 'true' again for real work.
Case 1: The commit that introduced the second spelling is HEAD
In this case you're sort of lucky because it's easy to fix. You can
do
git rm --cached PosterWantsItCensored.designer.cs
to get rid of the spelling you do not want. Then run
git status -s
again to verify that it did the right thing; it should say
D PosterWantsItCensored.designer.cs
where it's important that a) the other spelling does *not* show up in
the list anywhere and b) the D is in the leftmost column. Once you
have verified this, run
git commit --amend
to fix HEAD.
Case 2a: The commit that introduced it is older, but you don't care if
you cannot sanely checkout old commits
This is the case that I personally would never choose, since I care
about history, but for completeness: proceed as for case 1, except at
the end run
git commit # no --amend
and write a nice message saying that you fixed the
different-only-in-case issue.
Case 2b: The commit that introduced it is older, but history since its
parent has been linear (use gitk or some such to establish
this)
First run
git log --full-history --oneline -- "PosterWantsItCensored.*"
to see which commits touched the file. Let C be the SHA1 (or a unique
prefix) of the earliest commit that contains
PosterWantsItCensored.designer.cs (i.e., the wrong spelling) as
established earlier. Then run
git rebase -i C^
(That's right, the SHA1 of C and then a hat.)
In the editor that pops up, change 'pick' to 'edit' on every line that
shows a SHA1 you found in the preceding git-log command. Save and
exit.
Whenever rebase stops to let you edit (you can tell by the advice
messages it gives you), run
git ls-tree HEAD -- PosterWantsItCensored.designer.cs PosterWantsItCensored.Designer.cs
and check whether the SHA1s are different. Judging by what you said
they should always be the same (otherwise please come back for more
advice). You can then again do something very similar to Case 1 to
the commit you're editing, like
git rm --cached PosterWantsItCensored.designer.cs
git commit --amend
and finally
git rebase --continue
to edit the next commit. Repeat until the rebase is complete.
Case 2c: History wasn't linear since C; or you're just lazy and have a
good backup
The all-safeties-off, please-fix-it-for-me version goes
git filter-branch --tag-name-filter cat --index-filter '
git rm --ignore-unmatch --cached PosterWantsItCensored.designer.cs
' -- --all
I'm dead serious about the safeties off. You have been warned.
I have not tested most of this because it would simply take even more
time than writing an essay-length email. If something fails or got you
confused, paste everything you did and the full output again so we can
establish what happened.
All sub-items of case 2 rewrite history. You will have to force the
push to your "hub" repository that you use to exchange history, and you
may have to reset or rebase in the other repository. Read e.g. the
'recovering from upstream rebase' section in man git-rebase.
> (What a mess it would be if I committed something different than my
> working directory, however that works.)
You should really read up on this, e.g.
http://tomayko.com/writings/the-thing-about-git
AFAIK everyone who groks the feature uses it daily.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* git-grep while excluding files in a blacklist
From: Dov Grobgeld @ 2012-01-17 9:14 UTC (permalink / raw)
To: git
Does git-grep allow searching for a pattern in all files *except*
files matching a pattern. E.g. in our project we have multiple DLL's
in git, but when searching I would like to exclude these for speed. Is
that possible with git-grep?
Thanks,
Dov
^ permalink raw reply
* Re: git-grep while excluding files in a blacklist
From: Nguyen Thai Ngoc Duy @ 2012-01-17 9:19 UTC (permalink / raw)
To: Dov Grobgeld; +Cc: git
In-Reply-To: <CA++fsGHGrNQzR-schP0yTXnD4jkYJjHHVk6QoJvfxPX9mguJPQ@mail.gmail.com>
On Tue, Jan 17, 2012 at 4:14 PM, Dov Grobgeld <dov.grobgeld@gmail.com> wrote:
> Does git-grep allow searching for a pattern in all files *except*
> files matching a pattern. E.g. in our project we have multiple DLL's
> in git, but when searching I would like to exclude these for speed. Is
> that possible with git-grep?
Not from command line, no. You can put "*.dll" to .gitignore file then
"git grep --exclude-standard".
--
Duy
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Matthieu Moy @ 2012-01-17 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjjfuuwk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> but is that the right thing to do if suffix came from "$4"?
>>>
>>> As far as I can see, "$4" is used to append "." in very limited cases, and
>>> nobody explicitly passes SP as "$4" when calling this, so it may be easier
>>> to read if you moved this before that "if we have 3 or more args, use the
>>> fourth one as the suffix" block, i.e. something like this?
>>
>> Why not, but in case someone explicitely passes " " as $4 in the future,
>> it's likely to be better to strip it for the same reason we strip it here.
>
> I doubt that would be sufficent or appropriate. If some caller _WANTS_ to
> add a SP, shouldn't we be devising a way to tell zsh to add it without
> quoting,
Yes, this is the point. But up to now, nobody found such a way so we're
just trying to work around it in the less painfull way for the user.
If someone _wants_ to add a SP, then he still can't do it portably with
your patch, because the space will be quoted for bash users, and not for
ZSH users, so one of them will be unhappy.
> So does that mean we would be forcing zsh users to add SP themselves?
Yes, but we already do so. From my commit message:
The absence of trailing space for ZSH is a long-standing issue, that
this patch is not fixing.
;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] branch: borrow --sort and --count from for-each-ref
From: Nguyễn Thái Ngọc Duy @ 2012-01-17 13:11 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Some time ago, I posted a patch that added date sort to git-branch
and Peff pointed me to for-each-ref. I did not look at it closely.
Now it does not seem hard to lend some code from for-each-ref to
git-branch. I can list 10 most recently touched branches with
git branch --sort=-committerdate -v --count=10
kind of cool. I don't think adding --format is necessary because
git-branch already has its own formatting.
Documentation/git-branch.txt | 13 +++++++++
Makefile | 1 +
builtin/branch.c | 61 +++++++++++++++++++++++++++++++++--------
builtin/for-each-ref.c | 33 +++-------------------
builtin/for-each-ref.h | 32 ++++++++++++++++++++++
5 files changed, 100 insertions(+), 40 deletions(-)
create mode 100644 builtin/for-each-ref.h
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 0427e80..b6f2826 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -10,6 +10,7 @@ SYNOPSIS
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
[--list] [-v [--abbrev=<length> | --no-abbrev]]
+ [--count=<count>] [(--sort=<key>)...]
[(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
@@ -192,6 +193,18 @@ start-point is either a local or remote-tracking branch.
The new name for an existing branch. The same restrictions as for
<branchname> apply.
+<count>::
+ By default the command shows all refs that match
+ `<pattern>`. This option makes it stop after showing
+ that many refs.
+
+<key>::
+ A field name to sort on. Prefix `-` to sort in descending
+ order of the value. When unspecified, `refname` is used. You
+ may use the --sort=<key> option multiple times, in which case
+ the last key becomes the primary key. See
+ linkgit:for-each-ref[1] for field name details.
+
Examples
--------
diff --git a/Makefile b/Makefile
index a782409..daf3e46 100644
--- a/Makefile
+++ b/Makefile
@@ -2108,6 +2108,7 @@ builtin/log.o builtin/shortlog.o: shortlog.h
builtin/prune.o builtin/reflog.o reachable.o: reachable.h
builtin/commit.o builtin/revert.o wt-status.o: wt-status.h
builtin/tar-tree.o archive-tar.o: tar.h
+builtin/branch.o builtin/for-each-ref.o: builtin/for-each-ref.h
connect.o transport.o url.o http-backend.o: url.h
http-fetch.o http-walker.o remote-curl.o transport.o walker.o: walker.h
http.o http-walker.o http-push.o http-fetch.o remote-curl.o: http.h url.h
diff --git a/builtin/branch.c b/builtin/branch.c
index 7095718..67bdbc7 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -15,6 +15,7 @@
#include "branch.h"
#include "diff.h"
#include "revision.h"
+#include "for-each-ref.h"
static const char * const builtin_branch_usage[] = {
"git branch [options] [-r | -a] [--merged | --no-merged]",
@@ -30,6 +31,9 @@ static const char * const builtin_branch_usage[] = {
static const char *head;
static unsigned char head_sha1[20];
+static struct ref_sort *sort = NULL, **sort_tail = &sort;
+static int maxcount;
+
static int branch_use_color = -1;
static char branch_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RESET,
@@ -312,7 +316,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
- if (!match_patterns(cb->pattern, refname))
+ if (cb->pattern && !match_patterns(cb->pattern, refname))
return 0;
commit = NULL;
@@ -510,10 +514,38 @@ static void show_detached(struct ref_list *ref_list)
}
}
-static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit, const char **pattern)
+static int fetch_branches(struct ref_list *ref_list,
+ const char **pattern)
{
- int i;
struct append_ref_cb cb;
+ cb.ref_list = ref_list;
+ cb.pattern = pattern;
+ cb.ret = 0;
+ if (sort) {
+ struct grab_ref_cbdata cbdata;
+ int i;
+ memset(&cbdata, 0, sizeof(cbdata));
+ cbdata.grab_pattern = pattern;
+ for_each_rawref(grab_single_ref, &cbdata);
+ sort_refs(sort, cbdata.grab_array, cbdata.grab_cnt);
+ for (i = 0; i < cbdata.grab_cnt; i++) {
+ struct refinfo *ri = cbdata.grab_array[i];
+ append_ref(ri->refname, ri->objectname, ri->flag, &cb);
+ }
+ }
+ else {
+ for_each_rawref(append_ref, &cb);
+ qsort(ref_list->list, ref_list->index,
+ sizeof(struct ref_item), ref_cmp);
+ }
+ return cb.ret;
+}
+
+static int print_ref_list(int kinds, int detached, int verbose, int abbrev,
+ struct commit_list *with_commit,
+ const char **pattern)
+{
+ int i, ret;
struct ref_list ref_list;
memset(&ref_list, 0, sizeof(ref_list));
@@ -523,10 +555,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
ref_list.with_commit = with_commit;
if (merge_filter != NO_FILTER)
init_revisions(&ref_list.revs, NULL);
- cb.ref_list = &ref_list;
- cb.pattern = pattern;
- cb.ret = 0;
- for_each_rawref(append_ref, &cb);
+ ret = fetch_branches(&ref_list, pattern);
if (merge_filter != NO_FILTER) {
struct commit *filter;
filter = lookup_commit_reference_gently(merge_filter_ref, 0);
@@ -539,13 +568,13 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
ref_list.maxwidth = calc_maxwidth(&ref_list);
}
- qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
-
detached = (detached && (kinds & REF_LOCAL_BRANCH));
if (detached && match_patterns(pattern, "HEAD"))
show_detached(&ref_list);
- for (i = 0; i < ref_list.index; i++) {
+ if (!maxcount)
+ maxcount = ref_list.index;
+ for (i = 0; i < maxcount; i++) {
int current = !detached &&
(ref_list.list[i].kind == REF_LOCAL_BRANCH) &&
!strcmp(ref_list.list[i].name, head);
@@ -558,10 +587,10 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
free_ref_list(&ref_list);
- if (cb.ret)
+ if (ret)
error(_("some refs could not be read"));
- return cb.ret;
+ return ret;
}
static void rename_branch(const char *oldname, const char *newname, int force)
@@ -702,6 +731,9 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
parse_opt_with_commit, (intptr_t) "HEAD",
},
OPT__ABBREV(&abbrev),
+ OPT_CALLBACK(0 , "sort", sort_tail, "key",
+ "field name to sort on", &opt_parse_sort),
+ OPT_INTEGER( 0 , "count", &maxcount, "show only <n> matched refs"),
OPT_GROUP("Specific git-branch actions:"),
OPT_SET_INT('a', "all", &kinds, "list both remote-tracking and local branches",
@@ -752,6 +784,11 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, builtin_branch_usage,
0);
+ if (maxcount < 0) {
+ error("invalid --count argument: `%d'", maxcount);
+ usage_with_options(builtin_branch_usage, options);
+ }
+
if (!delete && !rename && !edit_description && argc == 0)
list = 1;
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index b01d76a..7b25c54 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -9,6 +9,7 @@
#include "quote.h"
#include "parse-options.h"
#include "remote.h"
+#include "for-each-ref.h"
/* Quoting styles */
#define QUOTE_NONE 0
@@ -19,25 +20,6 @@
typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
-struct atom_value {
- const char *s;
- unsigned long ul; /* used for sorting when not FIELD_STR */
-};
-
-struct ref_sort {
- struct ref_sort *next;
- int atom; /* index into used_atom array */
- unsigned reverse : 1;
-};
-
-struct refinfo {
- char *refname;
- unsigned char objectname[20];
- int flag;
- const char *symref;
- struct atom_value *value;
-};
-
static struct {
const char *name;
cmp_type cmp_type;
@@ -765,17 +747,12 @@ static void get_value(struct refinfo *ref, int atom, struct atom_value **v)
*v = &ref->value[atom];
}
-struct grab_ref_cbdata {
- struct refinfo **grab_array;
- const char **grab_pattern;
- int grab_cnt;
-};
-
/*
* A call-back given to for_each_ref(). Filter refs and keep them for
* later object processing.
*/
-static int grab_single_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+int grab_single_ref(const char *refname, const unsigned char *sha1,
+ int flag, void *cb_data)
{
struct grab_ref_cbdata *cb = cb_data;
struct refinfo *ref;
@@ -858,7 +835,7 @@ static int compare_refs(const void *a_, const void *b_)
return 0;
}
-static void sort_refs(struct ref_sort *sort, struct refinfo **refs, int num_refs)
+void sort_refs(struct ref_sort *sort, struct refinfo **refs, int num_refs)
{
ref_sort = sort;
qsort(refs, num_refs, sizeof(struct refinfo *), compare_refs);
@@ -953,7 +930,7 @@ static struct ref_sort *default_sort(void)
return sort;
}
-static int opt_parse_sort(const struct option *opt, const char *arg, int unset)
+int opt_parse_sort(const struct option *opt, const char *arg, int unset)
{
struct ref_sort **sort_tail = opt->value;
struct ref_sort *s;
diff --git a/builtin/for-each-ref.h b/builtin/for-each-ref.h
new file mode 100644
index 0000000..8542d66
--- /dev/null
+++ b/builtin/for-each-ref.h
@@ -0,0 +1,32 @@
+struct atom_value {
+ const char *s;
+ unsigned long ul; /* used for sorting when not FIELD_STR */
+};
+
+struct ref_sort {
+ struct ref_sort *next;
+ int atom; /* index into used_atom array */
+ unsigned reverse : 1;
+};
+
+struct refinfo {
+ char *refname;
+ unsigned char objectname[20];
+ int flag;
+ const char *symref;
+ struct atom_value *value;
+};
+
+struct grab_ref_cbdata {
+ struct refinfo **grab_array;
+ const char **grab_pattern;
+ int grab_cnt;
+};
+
+extern int grab_single_ref(const char *refname,
+ const unsigned char *sha1,
+ int flag, void *cb_data);
+extern int opt_parse_sort(const struct option *opt,
+ const char *arg, int unset);
+extern void sort_refs(struct ref_sort *sort,
+ struct refinfo **refs, int num_refs);
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-17 13:42 UTC (permalink / raw)
To: Git Mailing List; +Cc: Ævar Arnfjörð Bjarmason, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
It is very unexpected.
---
I usually disable i18n on my working systems as they are generally very
out-of-date and not supported by any sane developer. In particular the
gettext provided with this (very old) Cygwin distribution is fubar and
never produces any output.
Makefile | 1 +
git-sh-i18n.sh | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index a782409..d82ea6a 100644
--- a/Makefile
+++ b/Makefile
@@ -1887,6 +1887,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's|@@LOCALEDIR@@|$(localedir_SQ)|g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_GETTEXT@@/$(NO_GETTEXT)/g' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+
endef
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index b4575fb..7f7e32b 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -18,7 +18,7 @@ export TEXTDOMAINDIR
if test -z "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh
>/dev/null 2>&1
+ if test -z "@@NO_GETTEXT@@" && test -z
"$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null
2>&1
then
# This is GNU libintl's gettext.sh, we don't need to do anything
# else than setting up the environment and loading gettext.sh
@@ -29,7 +29,7 @@ then
# can't.
. gettext.sh
- elif test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test
"$(gettext -h 2>&1)" = "-h"
+ elif test -z "@@NO_GETTEXT@@" && test -z
"$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" =
"-h"
then
# We don't have gettext.sh, but there's a gettext binary in our
# path. This is probably Solaris or something like it which has a
--
1.7.8.2.388.ge40c2
[-- Attachment #2: 0001-disable-i18n-for-shell-scripts-if-NO_GETTEXT-def.diff --]
[-- Type: text/x-patch, Size: 2022 bytes --]
From 36e73fe14cbecd04512a6e8a21b9eb14d278d1dc Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 17 Jan 2012 14:25:24 +0100
Subject: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
It is very unexpected.
I generally disable i18n on my working systems as they are generally very
out-of-date and not supported by any sane developer. In particular the
gettext provided with this (very old) Cygwin distribution is fubar and
never produces any output.
---
Makefile | 1 +
git-sh-i18n.sh | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index a782409..d82ea6a 100644
--- a/Makefile
+++ b/Makefile
@@ -1887,6 +1887,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's|@@LOCALEDIR@@|$(localedir_SQ)|g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_GETTEXT@@/$(NO_GETTEXT)/g' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+
endef
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index b4575fb..7f7e32b 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -18,7 +18,7 @@ export TEXTDOMAINDIR
if test -z "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
+ if test -z "@@NO_GETTEXT@@" && test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
then
# This is GNU libintl's gettext.sh, we don't need to do anything
# else than setting up the environment and loading gettext.sh
@@ -29,7 +29,7 @@ then
# can't.
. gettext.sh
- elif test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" = "-h"
+ elif test -z "@@NO_GETTEXT@@" && test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" = "-h"
then
# We don't have gettext.sh, but there's a gettext binary in our
# path. This is probably Solaris or something like it which has a
--
1.7.8.2.388.ge40c2
^ permalink raw reply related
* Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
From: Michael Haggerty @ 2012-01-17 15:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <7vzkewt5qu.fsf@alter.siamese.dyndns.org>
On 12/14/2011 12:24 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> ... But there are so many calls to the
>> for_each_ref*() family of functions that I wasn't able to determine
>> exactly which should allow for extra refs and which shouldn't.
>
> Only the ones that follow add_extra_ref() in the control flow.
>
> builtin/clone.c adds them in setup_reference() to deal with --reference.
> The objects known to be complete in these repositories we borrow from
> need to be marked complete on our end (i.e. clone does not have to fetch)
> and transport_fetch_refs() that eventually goes to fetch_refs_via_pack()
> that calls fetch_pack() uses this information. All three for_each_ref()
> calls in builtin/fetch-pack.c are about "what are the objects that we know
> are complete?" and needs to pay attention to extra refs.
>
> Having said that, I have a slight suspicion that you might be able to
> eliminate this one in clone. setup_reference() adds the reference
> repository to the $GIT_DIR/objects/info/alternates, and the fetch logic
> already knows to account for the refs in alternate repositories via
> insert_alternate_refs() callchain.
If I comment out the call from add_one_reference() to add_extra_ref()
then I get a single failure, in t5700:
not ok - 8 fetched no objects
# ! grep "^want" "$U"
So your suspicion does not seem to be borne out (at least not in the
naivest form).
Still studying...
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Suggestion: rebase [--onto <newbase>] [<upstream>][..[<branch>]]
From: Hallvard Breien Furuseth @ 2012-01-17 16:44 UTC (permalink / raw)
To: git
I think
git rebase [--onto <newbase>] [<upstream>][..[<branch>]]
would be a more readable syntax for what rebase is doing. Easier
to see which argument means what without staring at the manpage.
"..[<branch>]" without <upstream> implies --root.
--
Hallvard
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-17 17:56 UTC (permalink / raw)
To: Thomas Rast
Cc: Holger Hellmuth, Jeff King, Carlos Martín Nieto, git,
Erik Faye-Lund
In-Reply-To: <87ipkaogyj.fsf@thomas.inf.ethz.ch>
On 17.01.2012 09:45 CE(S)T, Thomas Rast wrote:
> It would also be interesting to know for how long this problem has
> existed. You can search for the offending commit with something like
>
> git log --name-status --diff-filter=A -- "PosterWantsItCensored.*"
>
> which should normally give you just one or two commits, namely the
> one(s) that introduced the two files.
I have found two commits adding that file. The second one has the file
with the then-already-present name modified and the new spelling added.
I could have noticed that at commit time, but that's the very commit
where I also renamed the original files and recreated them in the Forms
designer. 1) This may have led me to overlook that additional add and 2)
this may be the source of the spelling difference because the file was
newly created.
> As for the fix, there are two-and-two-thirds cases. (...)
That all sounds quite complicated. The "offending" commit is quite a
while back so replacing the last commit is not a solution.
This is just my personal repository that should help me out with finding
changes when I find something broken that wasn't before. Deleting and
recreating the "hub" (bare) and the other working repository would be
okay for me in this case. I have decided that it is also okay to fix the
error by new commits. To avoid all further issues with this, I have
renamed the file, committed the deletion, renamed it back and then
committed the add. The revsion in between won't compile, but it's got a
message with it and the compiler error would be obvious.
> You should really read up on this, e.g.
>
> http://tomayko.com/writings/the-thing-about-git
>
> AFAIK everyone who groks the feature uses it daily.
It's on my to-read list. Looks like an interesting article from reading
the beginning of it.
I have done a test, too: I have set the core.ignorecase setting to false
(or deleted its entry) and then renamed one of the files in my working
directory only in case. TortoiseGit has offered me adding the new
spelling for a commit. After setting the core.ignorecase setting to
true, it has not offered any change to commit anymore. So it looks like
this is just the setting that every repository for Windows use should -
no - must have, and it was missing here.
Just like that stupid autocrlf that causes more issues than it solves. I
regularly see files with all lines changed and the diff says that both
files only differ in line endings. But I have no sure observation on
whether that value was set or unset in those cases. I'll have to look
after that, too.
These two config settings are not cloned with the repository, are they?
Also, TortoiseGit already sets ignorecase = true. So maybe the Visual
Studio provider does the init on its own and is missing that. Or I have
at some time cloned the repository and the setting wasn't copied over.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Junio C Hamano @ 2012-01-17 18:46 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqr4yy1pv6.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> I doubt that would be sufficent or appropriate. If some caller _WANTS_ to
>> add a SP, shouldn't we be devising a way to tell zsh to add it without
>> quoting,
>
> Yes, this is the point. But up to now, nobody found such a way so we're
> just trying to work around it in the less painfull way for the user.
Ok, I take it that the original patch is meant as a small step in making
it a usable state, by not adding useless "quoted SP". In the ideal world
it may be better to add SP but we do not know how without zsh interfering
with our attempt to do so and adding an unwanted quoting, so we are taking
the second best approach that we at least know works.
Which is fine by me, and as you said, the completion script always asked
zsh users to add SP themselves, so it is not even a regression.
The real reason I am continuing this thread is to keep it alive so that a
zsh guru would jump in from somewhere and show us "here is how to tell Zsh
not to quote $suffix"; that does not seem to be happening yet, so let's
use your patch as-is.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Junio C Hamano @ 2012-01-17 19:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Ævar Arnfjörð Bjarmason
In-Reply-To: <CALxABCZME-g++HxMsD4Nrn1J6s27vN7M_KQSVT3PeLWBqP7qJg@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> From: Alex Riesen <raa.lkml@gmail.com>
> Date: Tue, 17 Jan 2012 14:25:24 +0100
> Subject: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
>
> Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
> It is very unexpected.
>
> I generally disable i18n on my working systems as they are generally very
> out-of-date and not supported by any sane developer. In particular the
> gettext provided with this (very old) Cygwin distribution is fubar and
> never produces any output.
> ---
Thanks for spotting. I agree that we should honor NO_GETTEXT here.
But the result of the patch looks almost unreadable. could we restructure
the script like this instead?
# Decide what to do...
GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
if test -n "@@NO_GETTEXT@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
then
: no probing necessary
elif test -n "$GIT_GETTEXT_POISON"
then
GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
elif type gettext.sh >/dev/null 2>&1
then
GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
elif test "$(gettext -h 2>&1)" = "-h"
then
GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
fi
export GIT_INTERNAL_GETTEXT_SH_SCHEME
# ... and then carry out the decision
case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
gnu)
... gnu definition here ...
;;
solaris)
... solaris cdefinition here ...
;;
poison)
... poison cdefinition here ...
;;
*)
... fallthru definition here ...
;;
esac
^ permalink raw reply
* Re: [PATCH] test-lib: add the test_pause convenience function
From: Junio C Hamano @ 2012-01-17 19:15 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jeff King, Git Mailing List, Pete Wyckoff
In-Reply-To: <4F152F7C.9020902@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> I really don't care deeply about the name, so test_pause is absolutely
> ok for me. I added some documentation in t/README too and made it an
> error when --verbose is not used.
I don't care about the name at all, either.
What I cared was more about the hardcoded "bash". Believe it or not, there
are boxes that lack it, and there are people who prefer other shells for
their interactive work. At the very least, invoke "$SHELL_PATH" instead of
bash there, perhaps?
If we wanted to allow an ad-hoc debugging of test scripts to sprinkle
"test_pause $cmd", we might need to do something like:
> +test_pause () {
> + if test "$verbose" = t; then
> + bash <&6 >&3 2>&4
${1-"$SHELL_PATH"} <&6 >&3 2>&4
> + else
> + error >&5 "test_pause requires --verbose"
> + fi
> +}
but I do not think that is worth it. The debugging developer should easily
be able to run gdb or whatever from the interactive shell you are giving
here.
^ permalink raw reply
* Interactive rebase with submodules
From: John Keeping @ 2012-01-17 18:47 UTC (permalink / raw)
To: git
I've encountered a scenario where git rebase --interactive drops a
commit which contains a modification to a submodule but no other changes.
This occurs when there is a conflict when applying the commit (for
example if the submodule's history has been rewritten and you are
rewriting the parent repository to match the new version of the submodule).
To clarify:
git rebase -i
# Edit a commit, switching submodule to an unrelated commit
git rebase --continue
# Conflict in submodule, checkout the correct submodule commit
git add path/to/submodule
# Only change in index is updated submodule
git rebase --continue
# No commit is created for the submodule change
This appears to be because the git-rebase--interactive script inspects
whether there is anything to commit when `rebase --continue` is invoked
by running:
git diff-index --cached --quiet --ignore-submodules HEAD --
Is there a reason for the `--ignore-submodules` in this command?
Removing that option results in the expected behaviour.
I can understand not updating submodules while running the rebase, but I
expected that having resolved a conflict and added my change to the
index it would be applied by `git rebase --continue`, as indeed it is if
there happen to be other (non-submodule) changes in the same commit.
--
John
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Felipe Contreras @ 2012-01-17 19:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1326567336-2173-1-git-send-email-Matthieu.Moy@imag.fr>
On Sat, Jan 14, 2012 at 8:55 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Commit a31e626 (completion: optimize refs completion) introduced a
> regression for ZSH users: ref names were completed with a quoted trailing
> space (i.e. "git checkout ma" completes to "git checkout master\ "). The
> space is convenient for bash users since we use "-o nospace", but a
> quoted space is worse than nothing. The absence of trailing space for ZSH
> is a long-standing issue, that this patch is not fixing. We just fix the
> regression by not appending a space when the shell is ZSH.
I have this issue with the script from v1.7.8.3, and I think it
started with a zsh update.
--
Felipe Contreras
^ permalink raw reply
* How to migrate a complex directory structure from SVN to GIT?
From: Asuka @ 2012-01-17 19:33 UTC (permalink / raw)
To: git
Hi there,
I would like to migrate my svn repository to git. The structure looks like
the following:
svn
|_Project1
|_subproject1
|_branches
|_branch1
|_branch2
|_trunk
|_tags
|_tagv1
|_Non-JavaProject
|_subproject
|_Project2
|_AnotherSubproject
|_SubSubproject
|_Subproject2
|_branches
|_tags
|_Subproject3
|_trunk
|_Subproject4
|_Subsubproject
|_branches
|_tags
|_trunk
I would like to migrate all branches and tags .. but unfortunately sometimes
I have just a trunk directory and no branches or tags directory. Sometimes
the branches are in a subdirectory, sometimes in a subsubdirectory. So how
can migrate my svn in an efficient way?
Thanks in advance
Best wishes
--
View this message in context: http://git.661346.n2.nabble.com/How-to-migrate-a-complex-directory-structure-from-SVN-to-GIT-tp7197567p7197567.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Felipe Contreras @ 2012-01-17 20:03 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <CAMP44s2nYMmfC36+pGaYfOZUQy3fLMYDuaSriPYjHBeApmsRVg@mail.gmail.com>
On Tue, Jan 17, 2012 at 9:18 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sat, Jan 14, 2012 at 8:55 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> Commit a31e626 (completion: optimize refs completion) introduced a
>> regression for ZSH users: ref names were completed with a quoted trailing
>> space (i.e. "git checkout ma" completes to "git checkout master\ "). The
>> space is convenient for bash users since we use "-o nospace", but a
>> quoted space is worse than nothing. The absence of trailing space for ZSH
>> is a long-standing issue, that this patch is not fixing. We just fix the
>> regression by not appending a space when the shell is ZSH.
>
> I have this issue with the script from v1.7.8.3, and I think it
> started with a zsh update.
Yeah, works fine with zsh 4.3.11, not 4.3.14 or 15.
--
Felipe Contreras
^ permalink raw reply
* Re: git-grep while excluding files in a blacklist
From: Junio C Hamano @ 2012-01-17 20:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Dov Grobgeld, git
In-Reply-To: <CACsJy8A8eWt_wcxWrdjgmkHZpS1bBet7DTT-bRf9zrxfszUtjw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Tue, Jan 17, 2012 at 4:14 PM, Dov Grobgeld <dov.grobgeld@gmail.com> wrote:
>> Does git-grep allow searching for a pattern in all files *except*
>> files matching a pattern. E.g. in our project we have multiple DLL's
>> in git, but when searching I would like to exclude these for speed. Is
>> that possible with git-grep?
>
> Not from command line, no. You can put "*.dll" to .gitignore file then
> "git grep --exclude-standard".
No rush, but is this something we would eventually want to handle with the
negative pathspec?
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Junio C Hamano @ 2012-01-17 20:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Matthieu Moy, git
In-Reply-To: <CAMP44s0T15idhwb6Eae5vdMxf25KK9MhY57mBf+BFN=OSC6Lhg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Tue, Jan 17, 2012 at 9:18 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Sat, Jan 14, 2012 at 8:55 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>>> Commit a31e626 (completion: optimize refs completion) introduced a
>>> regression for ZSH users: ref names were completed with a quoted trailing
>>> space (i.e. "git checkout ma" completes to "git checkout master\ "). The
>>> space is convenient for bash users since we use "-o nospace", but a
>>> quoted space is worse than nothing. The absence of trailing space for ZSH
>>> is a long-standing issue, that this patch is not fixing. We just fix the
>>> regression by not appending a space when the shell is ZSH.
>>
>> I have this issue with the script from v1.7.8.3, and I think it
>> started with a zsh update.
>
> Yeah, works fine with zsh 4.3.11, not 4.3.14 or 15.
As I was planning to queue Matthieu's patch as-is as a regression fix
before v1.7.9-rc2, I would appreciate if you can clarify this report a
bit. Do you mean with the patch more recent versions of zsh still does not
like the workaround and adds quoted space at the end?
^ permalink raw reply
* Re: [PATCH] branch: borrow --sort and --count from for-each-ref
From: Junio C Hamano @ 2012-01-17 20:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326805907-19416-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Some time ago, I posted a patch that added date sort to git-branch
> and Peff pointed me to for-each-ref. I did not look at it closely.
> Now it does not seem hard to lend some code from for-each-ref to
> git-branch. I can list 10 most recently touched branches with
>
> git branch --sort=-committerdate -v --count=10
>
> kind of cool. I don't think adding --format is necessary because
> git-branch already has its own formatting.
Why do we even need this for "git branch", when "git for-each-ref
refs/heads" already does this?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox