* 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
* Re: Suggestion: rebase [--onto <newbase>] [<upstream>][..[<branch>]]
From: Junio C Hamano @ 2012-01-17 20:17 UTC (permalink / raw)
To: Hallvard Breien Furuseth; +Cc: git
In-Reply-To: <hbf.20120117gdfh@bombur.uio.no>
Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> writes:
> 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.
I do not offhand see a huge issue if you come up with a patch that allows
users to additionally say:
$ git rebase upstream..topic
$ git rebase --onto there upstream..topic
what they express with
$ git rebase upstream topic
$ git rebase --onto there upstream topic
today.
However, "git rebase ..topic" to mean "everything down to root from topic"
is not OK; lack of one side in dotted range defaults to HEAD everywhere
else and such a change will introduce a huge discrepancy.
^ permalink raw reply
* [PATCH v2] test-lib: add the test_pause convenience function
From: Jens Lehmann @ 2012-01-17 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git Mailing List, Pete Wyckoff
In-Reply-To: <7vboq2rvhl.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. It invokes "$SHELL_PATH" to provide a sane shell
for the user.
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 17.01.2012 20:15, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 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?
Sure, I changed that in this version and explained it in the commit
message.
> 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.
That's what I always do, so I'm fine with what this patch provides. And
now the fact that you can temporarily pause a test and explore the trash
directory is documented too ;-)
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..709a300 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
+ "$SHELL_PATH" <&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.1.g8dae2
^ permalink raw reply related
* Re: Interactive rebase with submodules
From: Jens Lehmann @ 2012-01-17 21:29 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <4F15C22C.3020902@metanate.com>
Am 17.01.2012 19:47, schrieb John Keeping:
> 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 --
Thanks for pinning that down.
> Is there a reason for the `--ignore-submodules` in this command? Removing that option results in the expected behaviour.
Yes, removing it will help your use case but break others. The reason
for that is that because submodules are not updated during a rebase
it doesn't make sense to compare their HEAD to what is recorded in
the superproject, as that might have been changed by an earlier
commit. And as the submodules HEAD hasn't been updated back then,
it is stale and will always show up as modified (even if it wasn't).
> 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.
The irony is that you would have to update submodules (or at least
their HEAD and use "--ignore-submodules=dirty") while running rebase
to make that work in all cases ;-)
But just updating the HEAD would be dangerous as you would have to be
very careful to restore the submodules HEAD after the rebase, or the
submodule's work tree will be out of sync.
I suspect in the long run a rebase should, e.g. when invoked with
--recurse-submodules, update the submodules too and won't use the
--ignore-submodule option for diff anymore ... then everything
should Just Work. But until that happens, I don't see a solution
for your problem.
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Pete Wyckoff @ 2012-01-17 22:18 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <CAOpHH-XUj7tF4O_kXfxq2e9Y4VmybNLCqGku_-9H1X+c7v=xwQ@mail.gmail.com>
vitor.hda@gmail.com wrote on Tue, 17 Jan 2012 00:10 +0000:
> On Mon, Jan 16, 2012 at 11:41 PM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> > On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@padd.com> wrote:
> >> 1. Move the tempBranch commit outside of the "for blob" loop.
> >> It can have no parent, and the diff-tree will still tell you
> >> if you found the same contents. Instead of a ref for
> >> each blob inspected for each change, you'll just have one ref
> >> per change. Only one checkpoint() after the tempBranch
> >> commit should be needed.
> >
> > You're right. Completely oversaw that. Will improve the code
> > accordingly.
>
> Apparently I did not oversee it. Assume you have added a new file to
> HEAD of parent branch, but you branched from a previous commit. When the
> new branch is committed over HEAD the new file will, incorrectly, be
> part of it and diff-tree will not work as expected.
I don't get it. This algorithm works on the fact that a "branch"
in p4 creates a new change that looks exactly like a previous
change.
The git-p4 sync step, when it detects a branch, starts by saving
the change in a commit with parent = null, so it is its own new
branch, an orphan, with no parents.
Now the task is to find some commit that has an identical tree to
this temporary one. You walk back all known p4 commits to try to
find one that is the same. It doesn't matter if any of those p4
commits have other commits on top of them.
At each step in the backward walk, the comparison is against the
unchanged orphan commit.
An ascii-art picture might help me. Or even a test case.
> I should avoid taking 6 months to submit a patch to avoid forgetting why
> I did what I did :)
Yeah, and now you have to explain it all over to me again too. :)
-- Pete
^ permalink raw reply
* Re: [PATCH 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Pete Wyckoff @ 2012-01-17 22:39 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
In-Reply-To: <1326755689-3344-2-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Mon, 16 Jan 2012 23:14 +0000:
> Don't use shell expansion when detecting branches, as it will
> fail if the branch name contains a shell metachar. Similarly
> for labels.
>
> Add additional test for branches with shell metachars.
Nice. There will be a fixup on a command in Vitor's series,
depending on which goes first. He'll have a couple of
un-listified read_pipe{,_lines} that we should treat similarly.
> @@ -1758,7 +1758,7 @@ class P4Sync(Command, P4UserMap):
> def getLabels(self):
> self.labels = {}
>
> - l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
> + l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
> if len(l) > 0 and not self.silent:
> print "Finding files belonging to labels in %s" % `self.depotPaths`
I suspect the command "p4" "labels" "//depot/foo/... //depot/bar/..."
might confuse p4, but haven't tested. Maybe tuck each one in its
own argument?
["labels"] + ["%s..." % p for p in self.depotPaths]
What happened to your failing test? It's fun to keep the broken
ones around to inspire others to fix them.
-- Pete
^ permalink raw reply
* Using signed tag in pull requests
From: Junio C Hamano @ 2012-01-17 22:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
This document will appear in Documentation/howto of Git release v1.7.9; I
am sending it out for an early review.
Thanks.
-- >8 --
Using signed tag in pull requests
=================================
A typical distributed workflow using Git is for a contributor to fork a
project, build on it, publish the result to her public repository, and ask
the "upstream" person (often the owner of the project where she forked
from) to pull from her public repository. Requesting such a "pull" is made
easy by the `git request-pull` command.
Earlier, a typical pull request may have started like this:
------------
The following changes since commit 406da78032179...:
Froboz 3.2 (2011-09-30 14:20:57 -0700)
are available in the git repository at:
example.com:/git/froboz.git for-xyzzy
------------
followed by a shortlog of the changes and a diffstat.
The request was for a branch name (e.g. `for-xyzzy`) in the public
repository of the contributor, and even though it stated where the
contributor forked her work from, the message did not say anything about
the commit to expect at the tip of the for-xyzzy branch. If the site that
hosts the public repository of the contributor cannot be fully trusted, it
was unnecessarily hard to make sure what was pulled by the integrator was
genuinely what the contributor had produced for the project. Also there
was no easy way for third-party auditors to later verify the resulting
history.
Starting from Git release v1.7.9, a contributor can add a signed tag to
the commit at the tip of the history and ask the integrator to pull that
signed tag. When the integrator runs `git pull`, the signed tag is
automatically verified to assure that the history is not tampered with.
In addition, the resulting merge commit records the content of the signed
tag, so that other people can verify that the branch merged by the
contributor was signed by the contributor, without fetching the signed tag
used to validate the pull request separately and keeping it in the refs
namespace.
This document describes the workflow between the contributor and the
integrator, using Git v1.7.9 or later.
A contributor or a lieutenant
-----------------------------
After preparing her work to be pulled, the contributor uses `git tag -s`
to create a signed tag [*1*]:
------------
$ git checkout work
$ ... "git pull" from sublieutenants, "git commit" your own work ...
$ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
------------
and pushes the tag out to her publishing repository [*2*]. There is no
need to push the `work` branch or anything else:
------------
$ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
------------
Then the contributor prepares a message to request a "pull":
------------
$ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt
------------
The arguments are:
. the version of the integrator's commit the contributor based her work on;
. the URL of the repository, to which the contributor has pushed what she
wants to get pulled; and
. the name of the tag the contributor wants to get pulled (earlier, she could
write only a branch name here).
The resulting msg.txt file begins like so:
------------
The following changes since commit 406da78032179...:
Froboz 3.2 (2011-09-30 14:20:57 -0700)
are available in the git repository at:
example.com:/git/froboz.git frotz-for-xyzzy
for you to fetch changes up to 703f05ad5835c...:
Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
-----------------------------------------------
Completed frotz feature
-----------------------------------------------
------------
followed by a shortlog of the changes and a diffstat. Comparing this with
the earlier illustration of the output from the traditional `git request-pull`
command, the reader should notice that:
. The tip commit to expect is shown to the integrator; and
. The signed tag message is shown prominently between the dashed lines
before the shortlog.
The latter is why the contributor would want to justify why pulling her
work is worthwhile when creating the signed tag. The contributor then
opens her favorite MUA, reads msg.txt, edits and sends it to her upstream
integrator.
Integrator
----------
After receiving such a pull request message, the integrator fetches and
integrates the tag named in the request, with:
------------
$ git pull example.com:/git/froboz.git/ frotz-for-xyzzy
------------
This operation will always open an editor to allow the integrator to fine
tune the commit log message when merging a signed tag. Also, pulling a
signed tag will always create a merge commit even when the integrator does
not have any new commits since the contributor's work forked (i.e. 'fast
forward'), so that the integrator can properly explain what the merge is
about and why it was made.
In the editor, the integrator will see something like this:
------------
Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
Completed frotz feature
# gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
# gpg: Good signature from "Con Tributor <nitfol@example.com>"
------------
provided if the signature in the signed tag verifies correctly. Notice
that the message recorded in the signed tag "Completed frotz feature"
appears here, and again that is why it is important for the contributor
to explain her work well when creating the signed tag.
As usual, the lines commented with `#` are stripped out. The resulting
commit records the signed tag used for this validation in a hidden field
so that it can later be used by others to audit the history. There is no
need for the integrator to keep a separate copy of the tag in his
repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
example), and there is no need to publish the tag to his public
repository, either.
After the integrator responds to the pull request and her work becomes
part of the permanent history, the contributor can remove the tag from the
publishing repository, if she chooses, in order to keep the tag namespace
of her public repository clean, with:
------------
$ git push example.com:/git/froboz.git :frotz-for-xyzzy
------------
Auditors
--------
The `--show-signature` option can be given to `git log` or `git show` and
shows the verification status of the embedded signed tag in merge commits
created when the integrator responded to a pull request of a signed tag.
A typical output from `git show --show-signature` may look like this:
------------
$ git show --show-signature
commit 02306ef6a3498a39118aef9df7975bdb50091585
merged tag 'frotz-for-xyzzy'
gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB
gpg: Good signature from "Con Tributor <nitfol@example.com>"
Merge: 406da78 703f05a
Author: Inte Grator <xyzzy@example.com>
Date: Tue Jan 17 13:49:41 2012 -0800
Merge tag 'frotz-for-xyzzy'
Completed frotz feature
* tag 'frotz-for-xyzzy' (100 commits)
Add tests and documentation for frotz
...
------------
There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
that is used for frequent "pull" exchange in the long term just for such
auditing purposes, as the signature is recorded as part of the merge
commit.
Footnotes
---------
*1* This example uses the `-m` option to create a signed tag with just a
single liner message, but this is for illustration purposes only. It is
advisable to compose a well-written explanation of what the topic does to
justify why it is worthwhile for the integrator to pull it, as this
message will eventually become part of the final history after the
integrator responds to the pull request.
*2* The example uses plus at the beginning of `+frotz-for-xyzzy` to allow
forcing the update of a tag, as the same contributor may want to reuse a
signed tag with the same name after the previous pull request has already
been responded to.
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Felipe Contreras @ 2012-01-17 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vzkdmqebh.fsf@alter.siamese.dyndns.org>
On Tue, Jan 17, 2012 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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?
I am saying I am seeing the issue (or at least the same symptom) even
before a31e626 with recent zsh versions. I will try a patched version
of the script and a31e626, but I'm guessing the result would be the
same.
--
Felipe Contreras
^ 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