* [PATCH 5/7] everything_local(): mark alternate refs as complete
From: mhagger @ 2012-02-11 6:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1328941261-29746-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Objects in an alternate object database are already available to the
local repository and therefore don't need to be fetched. So mark them
as complete in everything_local().
This fixes a test in t5700.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/fetch-pack.c | 6 ++++++
t/t5700-clone-reference.sh | 2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index dbe9acb..0e8560f 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -581,6 +581,11 @@ static void filter_refs(struct ref **refs, int nr_match, char **match)
*refs = newlist;
}
+static void mark_alternate_complete(const struct ref *ref, void *unused)
+{
+ mark_complete(NULL, ref->old_sha1, 0, NULL);
+}
+
static int everything_local(struct ref **refs, int nr_match, char **match)
{
struct ref *ref;
@@ -609,6 +614,7 @@ static int everything_local(struct ref **refs, int nr_match, char **match)
if (!args.depth) {
for_each_ref(mark_complete, NULL);
+ for_each_alternate_ref(mark_alternate_complete, NULL);
if (cutoff)
mark_recent_complete_commits(cutoff);
}
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index 2dafee8..783f988 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -167,7 +167,7 @@ test_expect_success 'prepare branched repository' '
rm -f "$U.K"
-test_expect_failure 'fetch with incomplete alternates' '
+test_expect_success 'fetch with incomplete alternates' '
git init K &&
echo "$base_dir/A/.git/objects" >K/.git/objects/info/alternates &&
(
--
1.7.9
^ permalink raw reply related
* [PATCH 6/7] clone: do not add alternate references to extra_refs
From: mhagger @ 2012-02-11 6:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1328941261-29746-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Alternate references are directly (and now, correctly) handled by
fetch-pack, so there is no need to inform fetch-pack about them via
the extra_refs back channel.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/clone.c | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 279fdf0..b15fccb 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -232,9 +232,6 @@ static int add_one_reference(struct string_list_item *item, void *cb_data)
{
char *ref_git;
struct strbuf alternate = STRBUF_INIT;
- struct remote *remote;
- struct transport *transport;
- const struct ref *extra;
/* Beware: real_path() and mkpath() return static buffer */
ref_git = xstrdup(real_path(item->string));
@@ -249,14 +246,6 @@ static int add_one_reference(struct string_list_item *item, void *cb_data)
strbuf_addf(&alternate, "%s/objects", ref_git);
add_to_alternates_file(alternate.buf);
strbuf_release(&alternate);
-
- remote = remote_get(ref_git);
- transport = transport_get(remote, ref_git);
- for (extra = transport_get_remote_refs(transport); extra;
- extra = extra->next)
- add_extra_ref(extra->name, extra->old_sha1, 0);
-
- transport_disconnect(transport);
free(ref_git);
return 0;
}
@@ -500,7 +489,6 @@ static void update_remote_refs(const struct ref *refs,
const char *msg)
{
if (refs) {
- clear_extra_refs();
write_remote_refs(mapped_refs);
if (option_single_branch)
write_followtags(refs, msg);
--
1.7.9
^ permalink raw reply related
* [PATCH 0/7] Make alternates affect fetch behavior
From: mhagger @ 2012-02-11 6:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
It used to be that alternate references were not considered "complete"
when fetching via fetch-pack. This failure was not so obvious because
the big benefit of alternates is seen when cloning, and clone used a
different data path: it put the alternate references into extra refs
(which makes them look like references within the local repository).
This patch series teaches fetch-pack to treat objects that are
available via alternates as "complete".
Once that is fixed, clone doesn't need to use the special extra_refs
kludge, so change that.
And once that is changed, the extra_refs API is no longer needed at
all, so remove it.
Michael Haggerty (7):
t5700: document a failure of alternates to affect fetch
clone.c: move more code into the "if (refs)" conditional
fetch-pack.c: rename some parameters from "path" to "refname"
fetch-pack.c: inline insert_alternate_refs()
everything_local(): mark alternate refs as complete
clone: do not add alternate references to extra_refs
refs: remove the extra_refs API
builtin/clone.c | 51 +++++++++++++++++--------------------------
builtin/fetch-pack.c | 23 ++++++++++---------
refs.c | 23 +-------------------
refs.h | 8 -------
t/t5700-clone-reference.sh | 34 ++++++++++++++++++++++++++--
5 files changed, 64 insertions(+), 75 deletions(-)
--
1.7.9
^ permalink raw reply
* [PATCH 3/7] fetch-pack.c: rename some parameters from "path" to "refname"
From: mhagger @ 2012-02-11 6:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1328941261-29746-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
The parameters denote reference names, which are no longer 1:1 with
filesystem paths.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/fetch-pack.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 6207ecd..9bd2096 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -58,9 +58,9 @@ static void rev_list_push(struct commit *commit, int mark)
}
}
-static int rev_list_insert_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static int rev_list_insert_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
- struct object *o = deref_tag(parse_object(sha1), path, 0);
+ struct object *o = deref_tag(parse_object(sha1), refname, 0);
if (o && o->type == OBJ_COMMIT)
rev_list_push((struct commit *)o, SEEN);
@@ -68,9 +68,9 @@ static int rev_list_insert_ref(const char *path, const unsigned char *sha1, int
return 0;
}
-static int clear_marks(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static int clear_marks(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
- struct object *o = deref_tag(parse_object(sha1), path, 0);
+ struct object *o = deref_tag(parse_object(sha1), refname, 0);
if (o && o->type == OBJ_COMMIT)
clear_commit_marks((struct commit *)o,
@@ -493,7 +493,7 @@ done:
static struct commit_list *complete;
-static int mark_complete(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static int mark_complete(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
struct object *o = parse_object(sha1);
--
1.7.9
^ permalink raw reply related
* [PATCH 2/7] clone.c: move more code into the "if (refs)" conditional
From: mhagger @ 2012-02-11 6:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1328941261-29746-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
The bahavior of a bunch of code before the "if (refs)" statement also
depends on whether refs is set, so make the logic clearer by shifting
this code into the if statement.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/clone.c | 39 ++++++++++++++++++++-------------------
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index c62d4b5..279fdf0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -813,28 +813,28 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
}
refs = transport_get_remote_refs(transport);
- mapped_refs = refs ? wanted_peer_refs(refs, refspec) : NULL;
- /*
- * transport_get_remote_refs() may return refs with null sha-1
- * in mapped_refs (see struct transport->get_refs_list
- * comment). In that case we need fetch it early because
- * remote_head code below relies on it.
- *
- * for normal clones, transport_get_remote_refs() should
- * return reliable ref set, we can delay cloning until after
- * remote HEAD check.
- */
- for (ref = refs; ref; ref = ref->next)
- if (is_null_sha1(ref->old_sha1)) {
- complete_refs_before_fetch = 0;
- break;
- }
+ if (refs) {
+ mapped_refs = wanted_peer_refs(refs, refspec);
+ /*
+ * transport_get_remote_refs() may return refs with null sha-1
+ * in mapped_refs (see struct transport->get_refs_list
+ * comment). In that case we need fetch it early because
+ * remote_head code below relies on it.
+ *
+ * for normal clones, transport_get_remote_refs() should
+ * return reliable ref set, we can delay cloning until after
+ * remote HEAD check.
+ */
+ for (ref = refs; ref; ref = ref->next)
+ if (is_null_sha1(ref->old_sha1)) {
+ complete_refs_before_fetch = 0;
+ break;
+ }
- if (!is_local && !complete_refs_before_fetch && refs)
- transport_fetch_refs(transport, mapped_refs);
+ if (!is_local && !complete_refs_before_fetch)
+ transport_fetch_refs(transport, mapped_refs);
- if (refs) {
remote_head = find_ref_by_name(refs, "HEAD");
remote_head_points_at =
guess_remote_head(remote_head, mapped_refs, 0);
@@ -852,6 +852,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
}
else {
warning(_("You appear to have cloned an empty repository."));
+ mapped_refs = NULL;
our_head_points_at = NULL;
remote_head_points_at = NULL;
remote_head = NULL;
--
1.7.9
^ permalink raw reply related
* [PATCH 1/7] t5700: document a failure of alternates to affect fetch
From: mhagger @ 2012-02-11 6:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1328941261-29746-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
If an alternate supplies some, but not all, of the objects needed for
a fetch, fetch-pack nevertheless generates "want" lines for the
alternate objects that are present. Demonstrate this problem via a
failing test.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
t/t5700-clone-reference.sh | 34 +++++++++++++++++++++++++++++++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index c4c375a..2dafee8 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -52,13 +52,13 @@ test_cmp expected current'
cd "$base_dir"
-rm -f "$U"
+rm -f "$U.D"
test_expect_success 'cloning with reference (no -l -s)' \
-'GIT_DEBUG_SEND_PACK=3 git clone --reference B "file://$(pwd)/A" D 3>"$U"'
+'GIT_DEBUG_SEND_PACK=3 git clone --reference B "file://$(pwd)/A" D 3>"$U.D"'
test_expect_success 'fetched no objects' \
-'! grep "^want" "$U"'
+'! grep "^want" "$U.D"'
cd "$base_dir"
@@ -153,4 +153,32 @@ test_expect_success 'clone with reference from a tagged repository' '
git clone --reference=A A I
'
+test_expect_success 'prepare branched repository' '
+ git clone A J &&
+ (
+ cd J &&
+ git checkout -b other master^ &&
+ echo other > otherfile &&
+ git add otherfile &&
+ git commit -m other &&
+ git checkout master
+ )
+'
+
+rm -f "$U.K"
+
+test_expect_failure 'fetch with incomplete alternates' '
+ git init K &&
+ echo "$base_dir/A/.git/objects" >K/.git/objects/info/alternates &&
+ (
+ cd K &&
+ git remote add J "file://$base_dir/J" &&
+ GIT_DEBUG_SEND_PACK=3 git fetch J 3>"$U.K"
+ ) &&
+ master_object=$(cd A && git for-each-ref --format="%(objectname)" refs/heads/master) &&
+ ! grep "^want $master_object" "$U.K" &&
+ tag_object=$(cd A && git for-each-ref --format="%(objectname)" refs/tags/HEAD) &&
+ ! grep "^want $tag_object" "$U.K"
+'
+
test_done
--
1.7.9
^ permalink raw reply related
* Re: User authentication in GIT
From: Sitaram Chamarty @ 2012-02-11 5:17 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1328893056653-7273350.post@n2.nabble.com>
On Fri, Feb 10, 2012 at 10:27 PM, supadhyay <supadhyay@imany.com> wrote:
> Now my confusion is my existing source code repository directory path during
> migration /home/GITAdmin/migration/<repository.git> and now through gitolite
> I want to manage both users and repositories but through gitolite it add
> repository in different path /home/GITAdmin/repositories/<repository.git>.
>
>
> Can you please help how through gitolite I can add new repository on to the
> same my exisitng migrated repository directory?
gitolite keeps all its repos in whatever directory is pointed to by
$REPO_BASE in the rc file. This is $HOME/repositories by default but
you can change it to whatever you want. Instructions for changing it
are in the 4th bullet of
http://sitaramc.github.com/gitolite/rc.html#gitolite_rc_rarely_changed_variables_
If you are moving existing repos into gitolite, be sure to read
http://sitaramc.github.com/gitolite/moverepos.html -- if you do it
wrong you may end up without the crucial "update" hook and then all
access control will fail.
^ permalink raw reply
* Re: Git SSH Authentication
From: Sitaram Chamarty @ 2012-02-11 5:05 UTC (permalink / raw)
To: isawk; +Cc: git
In-Reply-To: <loom.20120211T045801-602@post.gmane.org>
On Sat, Feb 11, 2012 at 9:31 AM, isawk <kwasi.gyasiagyei@4things.co.za> wrote:
> I'm unable to authenticate with git through ssh public key/password-less
> authentication.
>
> # git push origin master
> # Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> # fatal: The remote end hung up unexpectedly
if it didn't ask you for a password when pubkey access failed, that's
non-default. Someone explicitly told sshd to do that.
Common causes of pubkey access fail:
- wrong pubkey being used: run your ssh with '-vv' and look for
"offered". make sure the pubkey that is being offered has been added
to the server side ~/.ssh/authorized_keys
- wrong pubkey being offered: if you are using ssh-agent, make sure
you have 'ssh-add'ed the key you want to offer. Confirm with 'ssh-add
-l'
- wrong permissions on server side: sshd is very picky about
permissions. Any directory component of $HOME/.ssh having g+w or o+w
will make it refuse. Or wrong ownership (for example if you created a
file using root).
- AllowUsers setting on server side /etc/ssh/ssd_config: this item
is not set by default, which allows everyone to log in. But if
someone set it in for some reason, then the git user must also be
added to it.
In general, looking in server side /var/log/auth.log or
/var/log/secure or some such file will give you more information.
^ permalink raw reply
* Re: [PATCH 2/3] help.c: make term_columns() cached and export it
From: Nguyen Thai Ngoc Duy @ 2012-02-11 4:36 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328891972-23695-3-git-send-email-zbyszek@in.waw.pl>
2012/2/10 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
> Since term_columns() will usually fail, when a pager is installed,
> the cache is primed before the pager is installed. If a pager is not
> installed, then the cache will be set on first use.
Conflict alert. term_columns() is also moved out of help.c in
nd/columns series on pu, commit cb0850f (Save terminal width before
setting up pager - 2012-02-04)
>
> Conforms to The Single UNIX Specification, Version 2
> (http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html#tag_002_003).
>
> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
> ---
> help.c | 37 +++++++++++++++++++++++++++++--------
> help.h | 2 ++
> pager.c | 5 +++++
> 3 files changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/help.c b/help.c
> index bc15066..5d1cb1d 100644
> --- a/help.c
> +++ b/help.c
> @@ -5,26 +5,47 @@
> #include "help.h"
> #include "common-cmds.h"
>
> -/* most GUI terminals set COLUMNS (although some don't export it) */
> -static int term_columns(void)
> +/*
> + * Cache for term_columns() value. Set on first use or when
> + * installing a pager and replacing stdout.
> + */
> +static int term_columns_cache;
> +
> +/*
> + * Return cached value (if set) or $COLUMNS (if set and positive) or
> + * ioctl(1, TIOCGWINSZ).ws_col (if positive) or 80.
> + *
> + * $COLUMNS even if set, is usually not exported, so
> + * the variable can be used to override autodection.
> + */
> +int term_columns(void)
> {
> - char *col_string = getenv("COLUMNS");
> + char *col_string;
> int n_cols;
>
> - if (col_string && (n_cols = atoi(col_string)) > 0)
> - return n_cols;
> + if (term_columns_cache)
> + return term_columns_cache;
> +
> + col_string = getenv("COLUMNS");
> + if (col_string && (n_cols = atoi(col_string)) > 0) {
> + term_columns_cache = n_cols;
> + return term_columns_cache;
> + }
>
> #ifdef TIOCGWINSZ
> {
> struct winsize ws;
> if (!ioctl(1, TIOCGWINSZ, &ws)) {
> - if (ws.ws_col)
> - return ws.ws_col;
> + if (ws.ws_col) {
> + term_columns_cache = ws.ws_col;
> + return term_columns_cache;
> + }
> }
> }
> #endif
>
> - return 80;
> + term_columns_cache = 80;
> + return term_columns_cache;
> }
>
> void add_cmdname(struct cmdnames *cmds, const char *name, int len)
> diff --git a/help.h b/help.h
> index b6b12d5..880a4b4 100644
> --- a/help.h
> +++ b/help.h
> @@ -29,4 +29,6 @@ extern void list_commands(const char *title,
> struct cmdnames *main_cmds,
> struct cmdnames *other_cmds);
>
> +extern int term_columns(void);
> +
> #endif /* HELP_H */
> diff --git a/pager.c b/pager.c
> index 975955b..e7032de 100644
> --- a/pager.c
> +++ b/pager.c
> @@ -1,6 +1,7 @@
> #include "cache.h"
> #include "run-command.h"
> #include "sigchain.h"
> +#include "help.h"
>
> #ifndef DEFAULT_PAGER
> #define DEFAULT_PAGER "less"
> @@ -76,6 +77,10 @@ void setup_pager(void)
> if (!pager)
> return;
>
> + /* prime the term_columns() cache before it is too
> + * late and stdout is replaced */
> + (void) term_columns();
> +
> setenv("GIT_PAGER_IN_USE", "true", 1);
>
> /* spawn the pager */
> --
> 1.7.9.263.g4be11.dirty
>
--
Duy
^ permalink raw reply
* Git SSH Authentication
From: isawk @ 2012-02-11 4:01 UTC (permalink / raw)
To: git
I'm unable to authenticate with git through ssh public key/password-less
authentication.
# git push origin master
# Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
# fatal: The remote end hung up unexpectedly
git version
git version 1.7.8.4
git user
has .ssh/authorized_keys containing public key, but still nothing. I'm confused
on how to go about fixing this issue.
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Junio C Hamano @ 2012-02-11 3:06 UTC (permalink / raw)
To: Tom Grennan; +Cc: pclouds, git, krh, jasampler
In-Reply-To: <1328926618-17167-1-git-send-email-tmgrennan@gmail.com>
Tom Grennan <tmgrennan@gmail.com> writes:
>>If we pursue this, it may be best to first add match_patterns() to ./refs.[ch]
>>then incrementally modify these builtin commands to use it.
>
> The following series implements !<pattern> with: git-tag, git-branch, and
> git-for-each-ref.
>
> This still requires Documentation and unit test updates but I think these are
> close to functionally complete.
>
>>>About the '!' for exclusion, maybe it's better to move from fnmatch()
>>>as matching machinery to pathspec. Then when git learns negative
>>>pathspec [1], we have this feature for free.
>>>
>>>[1] http://thread.gmane.org/gmane.comp.version-control.git/189645/focus=190072
>
> After looking at this some more, I don't understand the value of replacing
> libc:fnmatch(). Or are you just referring to '--exclude' instead of
> [!]<pattern> argument parsing?
I have not formed a firm opinion on Nguyen's idea to reuse pathspec
matching infrastructure for this purpose, so I wouldn't comment on that
part. It certainly looks attractive, as it allows users to learn one and
only one extended matching syntax, but at the same time, it has a risk to
mislead people to think that the namespace for refs is similar to that of
the filesystem paths, which I see as a mild downside.
In any case, I do not like the structure of this series. If it followed
our usual pattern, it would consist of patches in this order:
- Patch 1 would extract match_pattern() from builtin/tag.c and introduce
the new helper function refname_match_patterns() to refs.c. It updates
the call sites of match_pattern() in builtin/tag.c, match_patterns() in
builtin/branch.c, and the implementation of grab_single_ref() in
builtin/for-each-ref.c with a call to the new helper function.
This step can and probably should be done as three sub-steps. 1a would
move builtin/tag.c::match_pattern() to refs.::refname_match_patterns(),
1b would use the new helper in builtin/branch.c and 1c would do the
same for builtin/for-each-ref.c.
It is important that this patch does so without introducing any new
functionality to the new function over the old one. When done this way,
there is no risk of introducing new bugs at 1a because it is purely a
code movement and renaming; 1b could introduce a bug that changes
semantics for bulitin/branch.c if its match_patterns() does things
differently from match_pattern() lifted from builtin/tag.c, and if it
is found out to be buggy, we can discard 1b without discarding 1a. Same
for 1c, which I highly suspect will introduce regression without
looking at the code (for-each-ref is prefix-match only), that can
safely be discarded.
This is to make it easier to ensure that the update does not introduce
new bugs.
- Patch 2 would then add the new functionality to the new helper. It
would also adjust the documentation of the three end user facing
commands to describe the fallout coming from this change, and adds new
tests to make sure future changes will not break this new
functionality.
That is, first refactor and clean-up without adding anything new, and then
build new stuff on solidified ground.
Do we allow a refname whose pathname component begins with '!', by the
way? If we do, how does a user look for a tag whose name is "!xyzzy"?
"Naming your tag !xyzzy used to be allowed but it is now forbidden after
this patch" is not an acceptable answer---it is called a regression. If
the negation operator were "^" or something that we explicitly forbid from
a refname, we wouldn't have such a problem.
^ permalink raw reply
* [PATCHv2 1/4] refs: add common refname_match_patterns()
From: Tom Grennan @ 2012-02-11 2:16 UTC (permalink / raw)
To: pclouds; +Cc: git, gitster, krh, jasampler
In-Reply-To: <20120210185516.GA4903@tgrennan-laptop>
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
---
refs.c | 14 ++++++++++++++
refs.h | 8 ++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index b8843bb..b42eb4a 100644
--- a/refs.c
+++ b/refs.c
@@ -1057,6 +1057,20 @@ int refname_match(const char *abbrev_name, const char *full_name, const char **r
return 0;
}
+int refname_match_patterns(const char **patterns, const char *refname)
+{
+ int given_match_pattern = 0, had_match = 0;
+
+ for (; *patterns; patterns++)
+ if (**patterns != '!') {
+ given_match_pattern = 1;
+ if (!fnmatch(*patterns, refname, 0))
+ had_match = 1;
+ } else if (!fnmatch(*patterns+1, refname, 0))
+ return 0;
+ return given_match_pattern ? had_match : 1;
+}
+
static struct ref_lock *verify_lock(struct ref_lock *lock,
const unsigned char *old_sha1, int mustexist)
{
diff --git a/refs.h b/refs.h
index 00ba1e2..13015ba 100644
--- a/refs.h
+++ b/refs.h
@@ -152,4 +152,12 @@ int update_ref(const char *action, const char *refname,
const unsigned char *sha1, const unsigned char *oldval,
int flags, enum action_on_err onerr);
+/**
+ * Returns:
+ * 1 with NULL patterns
+ * 0 if refname fnmatch()es any ! prefaced pattern
+ * 1 if refname fnmatch()es any pattern
+ */
+extern int refname_match_patterns(const char **patterns, const char *refname);
+
#endif /* REFS_H */
--
1.7.8
^ permalink raw reply related
* [PATCHv2 2/4] tag: use refs.c:refname_match_patterns()
From: Tom Grennan @ 2012-02-11 2:16 UTC (permalink / raw)
To: pclouds; +Cc: git, gitster, krh, jasampler
In-Reply-To: <20120210185516.GA4903@tgrennan-laptop>
This will exclude tags matching patterns prefaced with the '!'
character. This has precedence over other matching patterns.
For example,
$ git tag -l \!*-rc? v1.7.8*
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
$ git tag -l v1.7.8* \!*-rc?
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
This is equivalent to,
$ git tag -l v1.7.8* | grep -v '\-rc.'
Without a matching pattern, filter all tags with the "!" patterns,
$ ./git-tag -l \!*-rc?
gitgui-0.10.0
gitgui-0.10.1
gitgui-0.10.2
...
v1.7.8.3
v1.7.8.4
v1.7.9
That is equivalent to,
$ git tag -l | grep -v '\-rc.'
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
---
Documentation/git-tag.txt | 10 ++++++----
builtin/tag.c | 15 ++-------------
2 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 53ff5f6..56ea2fa 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
<tagname> [<commit> | <object>]
'git tag' -d <tagname>...
-'git tag' [-n[<num>]] -l [--contains <commit>] [<pattern>...]
+'git tag' [-n[<num>]] -l [--contains <commit>] [[!]<pattern>...]
'git tag' -v <tagname>...
DESCRIPTION
@@ -75,13 +75,15 @@ OPTIONS
If no number is given to `-n`, only the first line is printed.
If the tag is not annotated, the commit message is displayed instead.
--l <pattern>::
---list <pattern>::
+-l [!]<pattern>::
+--list [!]<pattern>::
List tags with names that match the given pattern (or all if no
pattern is given). Running "git tag" without arguments also
lists all tags. The pattern is a shell wildcard (i.e., matched
using fnmatch(3)). Multiple patterns may be given; if any of
- them matches, the tag is shown.
+ them matches, the tag is shown. If the pattern is prefaced with
+ the '!' character, all tags matching the pattern are filtered
+ from the list.
--contains <commit>::
Only list tags which contain the specified commit.
diff --git a/builtin/tag.c b/builtin/tag.c
index 31f02e8..7f99424 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -19,7 +19,7 @@
static const char * const git_tag_usage[] = {
"git tag [-a|-s|-u <key-id>] [-f] [-m <msg>|-F <file>] <tagname> [<head>]",
"git tag -d <tagname>...",
- "git tag -l [-n[<num>]] [<pattern>...]",
+ "git tag -l [-n[<num>]] [[!]<pattern>...]",
"git tag -v <tagname>...",
NULL
};
@@ -30,17 +30,6 @@ struct tag_filter {
struct commit_list *with_commit;
};
-static int match_pattern(const char **patterns, const char *ref)
-{
- /* no pattern means match everything */
- if (!*patterns)
- return 1;
- for (; *patterns; patterns++)
- if (!fnmatch(*patterns, ref, 0))
- return 1;
- return 0;
-}
-
static int in_commit_list(const struct commit_list *want, struct commit *c)
{
for (; want; want = want->next)
@@ -88,7 +77,7 @@ static int show_reference(const char *refname, const unsigned char *sha1,
{
struct tag_filter *filter = cb_data;
- if (match_pattern(filter->patterns, refname)) {
+ if (refname_match_patterns(filter->patterns, refname)) {
int i;
unsigned long size;
enum object_type type;
--
1.7.8
^ permalink raw reply related
* [PATCHv2 4/4] for-each-ref: use refs.c:refname_match_patterns()
From: Tom Grennan @ 2012-02-11 2:16 UTC (permalink / raw)
To: pclouds; +Cc: git, gitster, krh, jasampler
In-Reply-To: <20120210185516.GA4903@tgrennan-laptop>
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
---
builtin/for-each-ref.c | 23 +++--------------------
1 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index b01d76a..2c9cc47 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -781,25 +781,8 @@ static int grab_single_ref(const char *refname, const unsigned char *sha1, int f
struct refinfo *ref;
int cnt;
- if (*cb->grab_pattern) {
- const char **pattern;
- int namelen = strlen(refname);
- for (pattern = cb->grab_pattern; *pattern; pattern++) {
- const char *p = *pattern;
- int plen = strlen(p);
-
- if ((plen <= namelen) &&
- !strncmp(refname, p, plen) &&
- (refname[plen] == '\0' ||
- refname[plen] == '/' ||
- p[plen-1] == '/'))
- break;
- if (!fnmatch(p, refname, FNM_PATHNAME))
- break;
- }
- if (!*pattern)
- return 0;
- }
+ if (!refname_match_patterns(cb->grab_pattern, refname))
+ return 0;
/*
* We do not open the object yet; sort may only need refname
@@ -974,7 +957,7 @@ static int opt_parse_sort(const struct option *opt, const char *arg, int unset)
}
static char const * const for_each_ref_usage[] = {
- "git for-each-ref [options] [<pattern>]",
+ "git for-each-ref [options] [[!]<pattern>...]",
NULL
};
--
1.7.8
^ permalink raw reply related
* [PATCHv2 3/4] branch: use refs.c:refname_match_patterns()
From: Tom Grennan @ 2012-02-11 2:16 UTC (permalink / raw)
To: pclouds; +Cc: git, gitster, krh, jasampler
In-Reply-To: <20120210185516.GA4903@tgrennan-laptop>
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
---
builtin/branch.c | 16 ++--------------
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 7095718..7dfc693 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -266,18 +266,6 @@ struct append_ref_cb {
int ret;
};
-static int match_patterns(const char **pattern, const char *refname)
-{
- if (!*pattern)
- return 1; /* no pattern always matches */
- while (*pattern) {
- if (!fnmatch(*pattern, refname, 0))
- return 1;
- pattern++;
- }
- return 0;
-}
-
static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
struct append_ref_cb *cb = (struct append_ref_cb *)(cb_data);
@@ -312,7 +300,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 (!refname_match_patterns(cb->pattern, refname))
return 0;
commit = NULL;
@@ -542,7 +530,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
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"))
+ if (detached && refname_match_patterns(pattern, "HEAD"))
show_detached(&ref_list);
for (i = 0; i < ref_list.index; i++) {
--
1.7.8
^ permalink raw reply related
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-11 2:16 UTC (permalink / raw)
To: pclouds; +Cc: git, gitster, krh, jasampler
In-Reply-To: <20120210185516.GA4903@tgrennan-laptop>
On Fri, 10 Feb 2012 10:55:16 -0800, Tom Grennan wrote:
>On Fri, Feb 10, 2012 at 01:34:26PM +0700, Nguyen Thai Ngoc Duy wrote:
>>On Fri, Feb 10, 2012 at 2:43 AM, Tom Grennan <tmgrennan@gmail.com> wrote:
>>> Please see the following patch which filters the tag list of "!" prefaced
>>> patterns. If this is deemed desirable and correct, I'll resubmit with updated
>>> documentation and unit tests.
>>
>>git-branch, git-tag and git-for-each-ref are in the same family. I
>>think it's good to that all three commands share things, like this
>>pattern matching.
>
>Yes, git-branch and git-tag could now use a common match_patterns() but
>git-for-each-ref needs some rearranging; as will: git-describe,
>git-replace, git-ls-remote, git-name-rev, and git-show-branch.
>
>If we pursue this, it may be best to first add match_patterns() to ./refs.[ch]
>then incrementally modify these builtin commands to use it.
The following series implements !<pattern> with: git-tag, git-branch, and
git-for-each-ref.
This still requires Documentation and unit test updates but I think these are
close to functionally complete.
>>About the '!' for exclusion, maybe it's better to move from fnmatch()
>>as matching machinery to pathspec. Then when git learns negative
>>pathspec [1], we have this feature for free.
>>
>>[1] http://thread.gmane.org/gmane.comp.version-control.git/189645/focus=190072
After looking at this some more, I don't understand the value of replacing
libc:fnmatch(). Or are you just referring to '--exclude' instead of
[!]<pattern> argument parsing?
---
Tom Grennan (4):
refs: add common refname_match_patterns()
tag: use refs.c:refname_match_patterns()
branch: use refs.c:refname_match_patterns()
for-each-ref: use refs.c:refname_match_patterns()
Documentation/git-tag.txt | 10 ++++++----
builtin/branch.c | 16 ++--------------
builtin/for-each-ref.c | 23 +++--------------------
builtin/tag.c | 15 ++-------------
refs.c | 14 ++++++++++++++
refs.h | 8 ++++++++
6 files changed, 35 insertions(+), 51 deletions(-)
--
1.7.8
^ permalink raw reply
* Re: git svn problem
From: Serhat Sevki Dincer @ 2012-02-11 0:52 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4F358A53.8010409@vilain.net>
On Fri, Feb 10, 2012 at 11:21 PM, Sam Vilain <sam@vilain.net> wrote:
> Import them separately to different git-svn remotes, and once they are in
> the same repository you can graft them together using .git/info/grafts (see
> man gitrepository-layout). Once it looks right (check using 'gitk' etc),
> make it permanent using git filter-branch. You'll also want to remove the
> .git/svn directory, and re–run 'git svn fetch' so that git svn's revision
> database is recomputed. Don't forget the -A option to 'git svn fetch'!
That sounds too complicated. There should be an easier way (i hope:)
I have the following at the moment:
rm -rf plone.app.locales ; mkdir plone.app.locales ; cd plone.app.locales
git svn init -T trunk http://svn.plone.org/svn/plone/plone.app.locales
touch start ; git add start ; git commit -m start
git svn fetch -r49624:HEAD
git rebase --onto master --root trunk --preserve-merges
git checkout -b plone
plone branch looks good, now I would like to do the same with
collective/plone.app.locales. I tried a couple of things but ended up
getting errors like:
Rebuilding .git/svn/refs/remotes/trunk/.rev_map.db7f04ef-aaf3-0310-a811-c281ed44c4ad
...
Done rebuilding
.git/svn/refs/remotes/trunk/.rev_map.db7f04ef-aaf3-0310-a811-c281ed44c4ad
RA layer request failed: REPORT of '/svn/collective/!svn/vcc/default':
Could not read chunk size: connection was closed by server
(http://svn.plone.org) at /usr/lib/git-core/git-svn line 5131
Is there some way around these errors?
Thanks..
Serhat
^ permalink raw reply
* What's cooking in git.git (Feb 2012, #04; Fri, 10)
From: Junio C Hamano @ 2012-02-10 23:37 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
This round mosty consists of topics to fix new features introduced in
1.7.9, in preparation for 1.7.9.1 maintenance release. There are a few
more of them to come.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* nk/ctype-for-perf (2012-02-10) 2 commits
(merged to 'next' on 2012-02-10 at b41c6bb)
+ ctype: implement islower/isupper macro
+ ctype.c only wants git-compat-util.h
* jn/ancient-meld-support (2012-02-10) 1 commit
- mergetools/meld: Use --help output to detect --output support
--------------------------------------------------
[Graduated to "master"]
* jc/branch-desc-typoavoidance (2012-02-05) 2 commits
(merged to 'next' on 2012-02-06 at 9fb0568)
+ branch --edit-description: protect against mistyped branch name
+ tests: add write_script helper function
(this branch is tangled with jk/tests-write-script.)
Typo in "git branch --edit-description my-tpoic" was not diagnosed.
* jc/merge-ff-only-stronger-than-signed-merge (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 0fabf12)
+ merge: do not create a signed tag merge under --ff-only option
(this branch is used by jn/merge-no-edit-fix.)
"git merge --ff-only $tag" failed because it cannot record the required
mergetag without creating a merge, but this is so common operation for
branch that is used _only_ to follow the upstream, so it is allowed to
fast-forward without recording the mergetag.
* jc/parse-date-raw (2012-02-03) 2 commits
(merged to 'next' on 2012-02-07 at 486ae6e)
+ parse_date(): '@' prefix forces git-timestamp
+ parse_date(): allow ancient git-timestamp
"rebase" and "commit --amend" failed to work on commits with ancient
timestamps near year 1970.
* jk/tests-write-script (2012-02-03) 2 commits
(merged to 'next' on 2012-02-05 at 4264ffa)
+ t0300: use write_script helper
+ tests: add write_script helper function
(this branch is tangled with jc/branch-desc-typoavoidance.)
* jn/rpm-spec (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at dba940b)
+ git.spec: Workaround localized messages not put in any RPM
Fix breakage in v1.7.9 Makefile; rpmbuild notices an unpackaged but
installed *.mo file and fails.
* js/add-e-submodule-fix (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at c8e2d28)
+ add -e: do not show difference in a submodule that is merely dirty
"add -e" learned not to show a diff for an otherwise unmodified submodule
that only has uncommitted local changes in the patch prepared by for the
user to edit.
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
* nd/columns (2012-02-08) 15 commits
- column: Fix some compiler and sparse warnings
- column: add a corner-case test to t3200
- columns: minimum coding style fixes
- tag: add --column
- column: support piping stdout to external git-column process
- status: add --column
- branch: add --column
- help: reuse print_columns() for help -a
- column: add column.ui for default column output settings
- column: support columns with different widths
- column: add columnar layout
- Stop starting pager recursively
- Add git-column and column mode parsing
- column: add API to print items in columns
- Save terminal width before setting up pager
The "show list of ..." mode of a handful of commands learn to produce
column-oriented output.
Expecting a reroll.
--------------------------------------------------
[Cooking]
* jk/config-include (2012-02-06) 2 commits
- config: add include directive
- docs: add a basic description of the config API
An assignment to the include.path pseudo-variable causes the named file
to be included in-place when Git looks up configuration variables.
* jk/maint-tag-show-fixes (2012-02-08) 3 commits
(merged to 'next' on 2012-02-08 at 18459c4)
+ tag: do not show non-tag contents with "-n"
+ tag: die when listing missing or corrupt objects
+ tag: fix output of "tag -n" when errors occur
Bugfixes to "git tag -n" that lacked much error checking.
Will merge to 'masster'.
* mm/empty-loose-error-message (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at f119cac)
+ fsck: give accurate error message on empty loose object files
Updates the error message emitted when we see an empty loose object.
Will merge to 'masster'.
* jc/maint-commit-ignore-i-t-a (2012-02-07) 1 commit
(merged to 'next' on 2012-02-10 at e0040cf)
+ commit: ignore intent-to-add entries instead of refusing
Replaces the nd/commit-ignore-i-t-a series that was made unnecessary
complicated by bad suggestions I made earlier.
Will merge to 'masster'.
* jk/userdiff-config-simplify (2012-02-07) 1 commit
(merged to 'next' on 2012-02-10 at e9854c1)
+ drop odd return value semantics from userdiff_config
Code cleanup.
* nd/cache-tree-api-refactor (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at a9abbca)
+ cache-tree: update API to take abitrary flags
Code cleanup.
* tg/tag-points-at (2012-02-08) 1 commit
(merged to 'next' on 2012-02-10 at 4bff88f)
+ tag: add --points-at list option
* jl/maint-submodule-relative (2012-02-09) 2 commits
- submodules: always use a relative path from gitdir to work tree
- submodules: always use a relative path to gitdir
The second one looked iffy.
* jn/merge-no-edit-fix (2012-02-09) 1 commit
(merged to 'next' on 2012-02-10 at 014eec9)
+ merge: do not launch an editor on "--no-edit $tag"
In 1.7.9, "merge --no-edit $tag" incorrectly ignored --no-edit.
* ld/git-p4-expanded-keywords (2012-02-09) 2 commits
- git-p4: initial demonstration of possible RCS keyword fixup
- git-p4: add test case for RCS keywords
Waiting for reviews and user reports.
* mp/make-cleanse-x-for-exe (2012-02-09) 1 commit
(merged to 'next' on 2012-02-09 at 35cc89d)
+ Explicitly set X to avoid potential build breakage
Will merge to 'master'.
* bw/inet-pton-ntop-compat (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 61303e6)
+ Drop system includes from inet_pton/inet_ntop compatibility wrappers
The inclusion order of header files bites Solaris again and this fixes it.
Will merge to 'master'.
* jc/checkout-out-of-unborn (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at 60eb328)
+ git checkout -b: allow switching out of an unborn branch
I was fairly negative on this one, but Michael Haggerty and Peff convinced
me that selling this as "'checkout -b' that lack the <start point> is
about creating a new branch from my current state" is perfectly fine.
* jc/maint-mailmap-output (2012-02-06) 1 commit
(merged to 'next' on 2012-02-06 at 0a21425)
+ mailmap: always return a plain mail address from map_user()
map_user() was not rewriting its output correctly, which resulted in the
user visible symptom that "git blame -e" sometimes showed excess '>' at
the end of email addresses.
* tt/profile-build-fix (2012-02-09) 2 commits
(merged to 'next' on 2012-02-09 at 1c183af)
+ Makefile: fix syntax for older make
(merged to 'next' on 2012-02-07 at c8c5f3f)
+ Fix build problems related to profile-directed optimization
* nd/diffstat-gramnum (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 7335ecc)
+ Use correct grammar in diffstat summary line
The commands in the "git diff" family and "git apply --stat" that count
the number of files changed and the number of lines inserted/deleted have
been updated to match the output from "diffstat". This also opens the
door to i18n this line.
* jk/grep-binary-attribute (2012-02-02) 9 commits
(merged to 'next' on 2012-02-05 at 9dffa7e)
+ grep: pre-load userdiff drivers when threaded
+ grep: load file data after checking binary-ness
+ grep: respect diff attributes for binary-ness
+ grep: cache userdiff_driver in grep_source
+ grep: drop grep_buffer's "name" parameter
+ convert git-grep to use grep_source interface
+ grep: refactor the concept of "grep source" into an object
+ grep: move sha1-reading mutex into low-level code
+ grep: make locking flag global
Fixes a longstanding bug that there was no way to tell "git grep" that a
path may look like text but it is not, which "git diff" can do using the
attributes system. Now "git grep" honors the same "binary" (or "-diff")
attribute.
* jk/git-dir-lookup (2012-02-02) 1 commit
(merged to 'next' on 2012-02-05 at 1856d74)
+ standardize and improve lookup rules for external local repos
When you have both .../foo and .../foo.git, "git clone .../foo" did not
favor the former but the latter.
* jk/prompt-fallback-to-tty (2012-02-03) 2 commits
(merged to 'next' on 2012-02-06 at c0c995a)
+ prompt: fall back to terminal if askpass fails
+ prompt: clean up strbuf usage
The code to ask for password did not fall back to the terminal input when
GIT_ASKPASS is set but does not work (e.g. lack of X with GUI askpass
helper).
* jn/gitweb-search-utf-8 (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 055e446)
+ gitweb: Allow UTF-8 encoded CGI query parameters and path_info
Search box in "gitweb" did not accept non-ASCII characters correctly.
* fc/zsh-completion (2012-02-06) 3 commits
(merged to 'next' on 2012-02-06 at c94dd12)
+ completion: simplify __gitcomp and __gitcomp_nl implementations
+ completion: use ls -1 instead of rolling a loop to do that ourselves
+ completion: work around zsh option propagation bug
Fix git subcommand completion for zsh (in contrib/completion).
* nd/find-pack-entry-recent-cache-invalidation (2012-02-01) 2 commits
(merged to 'next' on 2012-02-01 at e26aed0)
+ find_pack_entry(): do not keep packed_git pointer locally
+ sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()
* nd/pack-objects-parseopt (2012-02-01) 3 commits
(merged to 'next' on 2012-02-05 at d0dc25d)
+ pack-objects: convert to use parse_options()
+ pack-objects: remove bogus comment
+ pack-objects: do not accept "--index-version=version,"
"pack-objects" learned use parse-options, losing custom command line
parsing code.
^ permalink raw reply
* Re: Splitting gitweb (was: Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff)
From: Jakub Narebski @ 2012-02-10 22:52 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <20120210183319.2f56ff88@gmail.com>
Michał Kiedrowicz wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > Well, except the fact
> > that I'm rather wary about adding more code to gitweb when it is still
> > single monolithic script, rather than split into packages.
> >
>
> Yeah, jumping between 2k'th and 5k'th line isn't a great fun. Do you
There is an easy part, an almost easy part, and a hard part.
The easy part of splitting gitweb is creating infrastructure for it,
at least in the basic case. The 'gitweb/split' branch in my git forks:
http://repo.or.cz/w/git/jnareb-git.git
https://github.com/jnareb/git
contains changes to gitweb and gitweb/Makefile, and splitting off
Gitweb::Util as an example; I'd have to update this branch to current
state of gitweb.
The almost easy part is to come up with a way to split gitweb. Do we
follow SVN::Web (Subversion web interface in Perl), or maybe Gitalist
(git web interface in Perl, using Catalyst MVC framework)? Do we use
MVC paradigm? Or do we split on functionality: diffs, blobs, trees,
logs, etc.?
The hard part is about splitting main parts of gitweb. It is easy to
put generic subroutines that are not specific to git or gitweb in
Gitweb::Util (or Gitweb::Util::* submodules). It would be almost as
easy to put parsing of git command output in Gitweb::Parse (or
Gitweb::Parse::* submodules).
The problem is with putting actual actions in separate submodules.
For that we would need to replace our hacky "longjmp"-based error handling
(nonlocal goto in Perl is roughly equivalent to longjmp() in C) to
exception-based one, as I don't think going back to exit-based error
ahndling is a good idea. We would need exception-based error handling
if we want to implement HTTP output caching anyway, I think.
Not to not reimplement the wheel, badly, we will do better to use some
non-core Perl modules, namely Try::Tiny for capturing exceptions, and
HTTP::Exception (based on Exception::Class) for throwing exceptions.
So we would have to add a way to handle such non-core modules, perhaps
bundling them with gitweb, like Error is bundled with Git.pm and used
if it is not present on install.
Maybe Module::Install would help us there with bundling of such
dependencies for install; maybe "push @INC, __DIR__.'/inc' would be
a good idea.
It needs thinking about.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: nested git repos (not submodules)
From: Neal Kreitzinger @ 2012-02-10 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7vd39ns4py.fsf@alter.siamese.dyndns.org>
On 2/9/2012 10:16 PM, Junio C Hamano wrote:
>
> The repository controlled by worktree/.git should behave as if subdir/
> does not exist, except that obviously the project cannot have a regular
> file "subdir" in it. When you chdir to worktree/subdir, everything in
> there should behave as if worktree/.git directory does not exist.
>
> At least that is the design, and it indeed is how I arrange my primary
> working tree (I have two "clones" at /git/git.git/ and /git/git.git/Meta,
> and the latter has a checkout of the "todo" branch), so I would make
> noises about any breakage for such a layout.
>
I now see that most of the concept of "a repo worktree path with an o/s
subdir containing another repo" is valid provided that the repo is
ignoring the worktree of the subdir repo.
> I do not know offhand if an attempt to add files inside subdir to the
> repository controlled by worktree/.git is always correctly prohibited by
> the code, though, as our code often forgets to error out "stupid user
> mistakes", and running "git add subdir/bar" when in worktree/ falls into
> that category.
>
In my situation, WORKTREE/.git is tracking the worktree of
WORKTREE/SUBDIR/.git. Before WORKTREE/SUBDIR/.git was created,
WORKTREE/SUBDIR/ was already being tracked by WORKTREE/.git because
WORKTREE/SUBDIR/. directly correlates to the rest of WORKTREE/.,
WORKTREE/SUBDIR2/., etc. Now that I know that having "a repo tracking
the worktree of a nested repo" is not a sound model, I can advise
against it on a go-forward basis without being concerned that I am not
open to new ideas.
> And the use of that layout predates the submodules by a large margin.
> In fact, when people suggest use of submodules when the toplevel and the
> sublevel do not even need tight version dependencies, some of their use
> cases might be better supported by using the simply-nested layout without
> even letting the toplevel be aware of the sublevel.
I will keep this in mind when adding submodules.
Thanks!
v/r,
neal
^ permalink raw reply
* Re: [PATCH] mergetools/meld: Use --help output to detect --output support
From: Jeff Epler @ 2012-02-10 22:30 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, David Aguilar, git, Sebastian Schuberth,
Charles Bailey
In-Reply-To: <20120210215755.GL19216@burratino>
I can confirm that this iteration of the patch (meld --help | grep)
worked for me on meld 1.1.1, meld 1.1.5, and meld 1.3.0. Note however
that none of these are versions of meld that do support the --output
flag.
Tested-by: Jeff Epler <jepler@unpythonic.net>
Jeff
^ permalink raw reply
* Re: [PATCH] mergetools/meld: Use --help output to detect --output support
From: Jeff Epler @ 2012-02-10 22:23 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, David Aguilar, git, Sebastian Schuberth,
Charles Bailey
In-Reply-To: <20120210215755.GL19216@burratino>
I appreciate the interest you've all taken in my report, but I really
don't think there's any need to do anything about this "problem" besides
let people find this thread, in which they can learn to try upgrading
their meld to one that's only 5 1/2 years old.
That said, another possibility is to test whether
meld --commandline-option-that-cannot-possibly-exist --help
exits with status 0; if it does, then exit-status based probing of
meld's capabilities won't work. In this case, assume --output is not
available.
Jeff
On Fri, Feb 10, 2012 at 03:57:55PM -0600, Jonathan Nieder wrote:
> In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's "meld" support learned
> to use the --output option when calling versions of meld that are
> detected to support it (1.5.0 and newer, hopefully).
>
> Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as
> supporting the option, so on systems with such meld, instead of
> getting a nice merge helper, the operator gets a dialog box with the
> text "Wrong number of arguments (Got 5)". (Version 1.1.5 is when meld
> switched to using optparse. One consequence of that change was that
> errors in usage are detected and signalled through the exit status
> even when --help was passed.)
>
> Luckily there is a simpler check that is more reliable: the usage
> string printed by "meld --help" reliably reflects whether --output is
> supported in a given version. Use it.
>
> Reported-by: Jeff Epler <jepler@unpythonic.net>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Junio C Hamano wrote:
>
> > When an older meld fails when given --output for real (not with the dry
> > run current code tries with --help), can we sanely detect that particular
> > failure?
>
> Unfortunately it just pops up a GUI with a modal dialog box like this:
> ___________________________________
> | |
> | Wrong number of arguments (Got 5) |
> | |
> | [Quit] [OK] |
> |___________________________________|
>
> If I choose "Quit", the exit status is 0.
>
> But how about this? "meld --help | grep -e --output" seems to detect
> support for the option reliably. With 2>&1 on the upstream of the
> pipe, this even seems futureproof. ;-)
>
> mergetools/meld | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mergetools/meld b/mergetools/meld
> index eaa115cc..cb672a55 100644
> --- a/mergetools/meld
> +++ b/mergetools/meld
> @@ -23,7 +23,7 @@ check_meld_for_output_version () {
> meld_path="$(git config mergetool.meld.path)"
> meld_path="${meld_path:-meld}"
>
> - if "$meld_path" --output /dev/null --help >/dev/null 2>&1
> + if "$meld_path" --help 2>&1 | grep -e --output >/dev/null
> then
> meld_has_output_option=true
> else
> --
> 1.7.9
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: nested git repos (not submodules)
From: Neal Kreitzinger @ 2012-02-10 22:07 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Neal Kreitzinger, git
In-Reply-To: <CAH5451mU5G-_FaPkpuhKrHAt4_5wiECj=-j9wkA_Ctb=27ncQg@mail.gmail.com>
On 2/9/2012 9:47 PM, Andrew Ardill wrote:
> My understanding was that such a configuration is essentially
> tracking the same set of files in two different git repositories. The
> location of the .git is not important, I could just as easily set the
> working directory of any git repository to be a folder tracked by
> another repository.
>
> My concerns would be based primarily on the different repositories
> trying to act on the same files at the same time. Ignoring the
> sub-folder completely within the encompassing repository would avoid
> that, however you might have use cases that prohibit that.
>
WORKTREE/SUBDIR/ was already tracked by WORKTREE/.git because the files
in WORKTREE/SUBDIR/ directly correlate to WORKTREE/ files (ie.,
WORKTREE/., WORKTREE/SUBDIR2/., WORKTREE/SUBDIR3/.). This is the
published model.
> Out of interest, what itch are you scratching by using this model?
>
(I can only speculate) I think it was intended to ensure that he would
only be modifying the WORKTREE/SUBDIR/ files of WORKTREE/.git. He did
some sequence of commands with the end result of:
(a) bare repo HISPATH/SUBDIR.git
and
(b1)
WORKTREE/.git
WORKTREE/SUBDIR/
is now
(b2)
WORKTREE/.git
WORKTREE/SUBDIR/.git
which means that the files of WORKTREE/SUBDIR are now tracked by
WORKTREE/.git and WORKTREE/SUBDIR/.git, as you stated.
Due to a drop-dead short-term deadline, I am being compelled to "just
deal with it" (work around the annoyances) unless there is a dire reason
it will blow up in our faces. At this point, (b2) is more-or-less an
intermediate "integration repo" between (a) and (b1-canonical), and I'm
assuming I can just jump thru some hoops to accomplish the integration
when the time comes (unless I hear of or step on any landmines).
Now that the newsgroup has confirmed that having "a repo that tracks the
worktree of a nested repo" is not a sound model, I can advise against it
on a go-forward basis without being concerned that I'm not open to new
ideas.
v/r,
neal
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-10 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobt6nz31.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> Exactly. Why do you need @fill_only at all? If you are interested in
>>> ctags and you want to make sure ctags is available, the question you want
>>> to ask the helper function is "Does the project structure already have
>>> ctags field?". Why does the helper function needs to know anything else?
>>
>> It is to support incremental filling of project info. The code is to
>> go like this:
>>
>> create
>> filter
>> fill part
>> filter
>> fill rest
>>
>> We need @fill_only for the "fill part".
>
> Again, why?
So fill_project_list_info() knows what needs to be filled (notice: not
"what to fill"), as filter might need different fields in project info
to do its work.
> > As filling project info is
> > potentially expensive (especially the 'age' field),
>
> So you wouldn't say "I am interested in 'age' field" but show interest in,
> and fill, cheaper fields in the earlier "fill" calls, and then...
It is not about cheaper, it is about required by filter. It happens that
it is cheaper.
> > doing it on narrowed
> > (filtered) list of project is a performance win.
>
> ... you drop uninteresting projects by using the partially filled
> information, and show interest in more expensive 'age' in the later round
> for surviving projects.
>
> It still does not explain why you need @fill_only.
So I can use single subroutine fill_project_list_info() to fill what is
required, and to fill the rest of info.
create
filter
fill part('path', 'descr')
filter('path', 'descr')
fill rest
or
create
filter
fill part('ctags')
filter('ctags')
fill rest
Am I clear?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] mergetools/meld: Use --help output to detect --output support
From: Jonathan Nieder @ 2012-02-10 21:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Aguilar, Jeff Epler, git, Sebastian Schuberth,
Charles Bailey
In-Reply-To: <7vwr7unzs8.fsf@alter.siamese.dyndns.org>
In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's "meld" support learned
to use the --output option when calling versions of meld that are
detected to support it (1.5.0 and newer, hopefully).
Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as
supporting the option, so on systems with such meld, instead of
getting a nice merge helper, the operator gets a dialog box with the
text "Wrong number of arguments (Got 5)". (Version 1.1.5 is when meld
switched to using optparse. One consequence of that change was that
errors in usage are detected and signalled through the exit status
even when --help was passed.)
Luckily there is a simpler check that is more reliable: the usage
string printed by "meld --help" reliably reflects whether --output is
supported in a given version. Use it.
Reported-by: Jeff Epler <jepler@unpythonic.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> When an older meld fails when given --output for real (not with the dry
> run current code tries with --help), can we sanely detect that particular
> failure?
Unfortunately it just pops up a GUI with a modal dialog box like this:
___________________________________
| |
| Wrong number of arguments (Got 5) |
| |
| [Quit] [OK] |
|___________________________________|
If I choose "Quit", the exit status is 0.
But how about this? "meld --help | grep -e --output" seems to detect
support for the option reliably. With 2>&1 on the upstream of the
pipe, this even seems futureproof. ;-)
mergetools/meld | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mergetools/meld b/mergetools/meld
index eaa115cc..cb672a55 100644
--- a/mergetools/meld
+++ b/mergetools/meld
@@ -23,7 +23,7 @@ check_meld_for_output_version () {
meld_path="$(git config mergetool.meld.path)"
meld_path="${meld_path:-meld}"
- if "$meld_path" --output /dev/null --help >/dev/null 2>&1
+ if "$meld_path" --help 2>&1 | grep -e --output >/dev/null
then
meld_has_output_option=true
else
--
1.7.9
^ permalink raw reply related
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