* [PATCH 1/5] Make clone parse the default refspec with the normal code
From: Daniel Barkalow @ 2009-03-06 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Instead of creating a refspec by hand, go through the refspec parsing
code, so that changes in the refspec storage will be accounted for.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
builtin-clone.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910..06b5a7f 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -378,7 +378,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
- struct refspec refspec;
+ struct refspec *refspec;
+ const char *fetch_pattern;
junk_pid = getpid();
@@ -487,8 +488,14 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
strbuf_addf(&branch_top, "refs/remotes/%s/", option_origin);
}
+ strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
+
if (option_mirror || !option_bare) {
/* Configure the remote */
+ strbuf_addf(&key, "remote.%s.fetch", option_origin);
+ git_config_set_multivar(key.buf, value.buf, "^$", 0);
+ strbuf_reset(&key);
+
if (option_mirror) {
strbuf_addf(&key, "remote.%s.mirror", option_origin);
git_config_set(key.buf, "true");
@@ -497,19 +504,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
strbuf_addf(&key, "remote.%s.url", option_origin);
git_config_set(key.buf, repo);
- strbuf_reset(&key);
-
- strbuf_addf(&key, "remote.%s.fetch", option_origin);
- strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
- git_config_set_multivar(key.buf, value.buf, "^$", 0);
strbuf_reset(&key);
- strbuf_reset(&value);
}
- refspec.force = 0;
- refspec.pattern = 1;
- refspec.src = src_ref_prefix;
- refspec.dst = branch_top.buf;
+ fetch_pattern = value.buf;
+ refspec = parse_fetch_refspec(1, &fetch_pattern);
+
+ strbuf_reset(&value);
if (path && !is_bundle)
refs = clone_local(path, git_dir);
@@ -543,7 +544,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (refs) {
clear_extra_refs();
- mapped_refs = write_remote_refs(refs, &refspec, reflog_msg.buf);
+ mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
head_points_at = locate_head(refs, mapped_refs, &remote_head);
}
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* [PATCH 2/5] Use a single function to match names against patterns
From: Daniel Barkalow @ 2009-03-06 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This will help when the matching changes.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
remote.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index d7079c6..709300b 100644
--- a/remote.c
+++ b/remote.c
@@ -719,6 +719,12 @@ int remote_has_url(struct remote *remote, const char *url)
return 0;
}
+static int name_fits_pattern(const char *key, const char *name)
+{
+ int ret = !prefixcmp(key, name);
+ return ret;
+}
+
int remote_find_tracking(struct remote *remote, struct refspec *refspec)
{
int find_src = refspec->src == NULL;
@@ -742,7 +748,7 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec)
if (!fetch->dst)
continue;
if (fetch->pattern) {
- if (!prefixcmp(needle, key)) {
+ if (name_fits_pattern(key, needle)) {
*result = xmalloc(strlen(value) +
strlen(needle) -
strlen(key) + 1);
@@ -1020,7 +1026,7 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
continue;
}
- if (rs[i].pattern && !prefixcmp(src->name, rs[i].src))
+ if (rs[i].pattern && name_fits_pattern(rs[i].src, src->name))
return rs + i;
}
if (matching_refs != -1)
@@ -1160,7 +1166,7 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
for (ref = remote_refs; ref; ref = ref->next) {
if (strchr(ref->name, '^'))
continue; /* a dereference item */
- if (!prefixcmp(ref->name, refspec->src)) {
+ if (name_fits_pattern(refspec->src, ref->name)) {
const char *match;
struct ref *cpy = copy_ref(ref);
match = ref->name + remote_prefix_len;
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* [PATCH 3/5] Use the matching function to generate the match results
From: Daniel Barkalow @ 2009-03-06 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This puts all of the interpretation of the pattern representation in a
single function for easy manipulation.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
remote.c | 45 +++++++++++++++++++++++----------------------
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/remote.c b/remote.c
index 709300b..93fd03d 100644
--- a/remote.c
+++ b/remote.c
@@ -719,9 +719,19 @@ int remote_has_url(struct remote *remote, const char *url)
return 0;
}
-static int name_fits_pattern(const char *key, const char *name)
+static int name_fits_pattern(const char *key, const char *name,
+ const char *value, char **result)
{
- int ret = !prefixcmp(key, name);
+ size_t klen = strlen(key);
+ int ret = !strncmp(key, name, klen);
+ if (ret && value) {
+ size_t vlen = strlen(value);
+ *result = xmalloc(vlen +
+ strlen(name) -
+ klen + 1);
+ strcpy(*result, value);
+ strcpy(*result + vlen, name + klen);
+ }
return ret;
}
@@ -748,13 +758,7 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec)
if (!fetch->dst)
continue;
if (fetch->pattern) {
- if (name_fits_pattern(key, needle)) {
- *result = xmalloc(strlen(value) +
- strlen(needle) -
- strlen(key) + 1);
- strcpy(*result, value);
- strcpy(*result + strlen(value),
- needle + strlen(key));
+ if (name_fits_pattern(key, needle, value, result)) {
refspec->force = fetch->force;
return 0;
}
@@ -1026,7 +1030,8 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
continue;
}
- if (rs[i].pattern && name_fits_pattern(rs[i].src, src->name))
+ if (rs[i].pattern && name_fits_pattern(rs[i].src, src->name,
+ NULL, NULL))
return rs + i;
}
if (matching_refs != -1)
@@ -1080,11 +1085,9 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
} else {
const char *dst_side = pat->dst ? pat->dst : pat->src;
- dst_name = xmalloc(strlen(dst_side) +
- strlen(src->name) -
- strlen(pat->src) + 2);
- strcpy(dst_name, dst_side);
- strcat(dst_name, src->name + strlen(pat->src));
+ if (!name_fits_pattern(pat->src, src->name,
+ dst_side, &dst_name))
+ die("Didn't think it matches any more");
}
dst_peer = find_ref_by_name(dst, dst_name);
if (dst_peer) {
@@ -1160,19 +1163,17 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
struct ref *ret = NULL;
struct ref **tail = &ret;
- int remote_prefix_len = strlen(refspec->src);
- int local_prefix_len = strlen(refspec->dst);
+ char *expn_name;
for (ref = remote_refs; ref; ref = ref->next) {
if (strchr(ref->name, '^'))
continue; /* a dereference item */
- if (name_fits_pattern(refspec->src, ref->name)) {
- const char *match;
+ if (name_fits_pattern(refspec->src, ref->name,
+ refspec->dst, &expn_name)) {
struct ref *cpy = copy_ref(ref);
- match = ref->name + remote_prefix_len;
- cpy->peer_ref = alloc_ref_with_prefix(refspec->dst,
- local_prefix_len, match);
+ cpy->peer_ref = alloc_ref(expn_name);
+ free(expn_name);
if (refspec->force)
cpy->peer_ref->force = 1;
*tail = cpy;
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* [PATCH 4/5] Keep '*' in pattern refspecs
From: Daniel Barkalow @ 2009-03-06 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In order to do anything more capable with refspecs, the first step is
to keep the entire input. Additionally, validate patterns by checking
for the ref matching the rules for a pattern as given by
check_ref_format(). This requires a slight change to make it require
the '*' to be at the beginning of a path component.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
refs.c | 4 +---
remote.c | 24 +++++++++---------------
2 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/refs.c b/refs.c
index 6eb5f53..a50ba79 100644
--- a/refs.c
+++ b/refs.c
@@ -718,9 +718,7 @@ int check_ref_format(const char *ref)
while ((ch = *cp++) != 0) {
bad_type = bad_ref_char(ch);
if (bad_type) {
- return (bad_type == 2 && !*cp)
- ? CHECK_REF_FORMAT_WILDCARD
- : CHECK_REF_FORMAT_ERROR;
+ return CHECK_REF_FORMAT_ERROR;
}
if (ch == '/')
break;
diff --git a/remote.c b/remote.c
index 93fd03d..d0ce4c6 100644
--- a/remote.c
+++ b/remote.c
@@ -10,8 +10,8 @@ static struct refspec s_tag_refspec = {
0,
1,
0,
- "refs/tags/",
- "refs/tags/"
+ "refs/tags/*",
+ "refs/tags/*"
};
const struct refspec *tag_refspec = &s_tag_refspec;
@@ -451,16 +451,11 @@ static void read_config(void)
*/
static int verify_refname(char *name, int is_glob)
{
- int result, len = -1;
+ int result;
- if (is_glob) {
- len = strlen(name);
- assert(name[len - 1] == '/');
- name[len - 1] = '\0';
- }
result = check_ref_format(name);
- if (is_glob)
- name[len - 1] = '/';
+ if (is_glob && result == CHECK_REF_FORMAT_WILDCARD)
+ result = CHECK_REF_FORMAT_OK;
return result;
}
@@ -517,7 +512,7 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
if (rhs) {
size_t rlen = strlen(++rhs);
is_glob = (2 <= rlen && !strcmp(rhs + rlen - 2, "/*"));
- rs[i].dst = xstrndup(rhs, rlen - is_glob);
+ rs[i].dst = xstrndup(rhs, rlen);
}
llen = (rhs ? (rhs - lhs - 1) : strlen(lhs));
@@ -525,7 +520,6 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
if ((rhs && !is_glob) || (!rhs && fetch))
goto invalid;
is_glob = 1;
- llen--;
} else if (rhs && is_glob) {
goto invalid;
}
@@ -722,10 +716,10 @@ int remote_has_url(struct remote *remote, const char *url)
static int name_fits_pattern(const char *key, const char *name,
const char *value, char **result)
{
- size_t klen = strlen(key);
- int ret = !strncmp(key, name, klen);
+ size_t klen = strchr(key, '*') - key;
+ int ret = !strncmp(name, key, klen);
if (ret && value) {
- size_t vlen = strlen(value);
+ size_t vlen = strchr(value, '*') - value;
*result = xmalloc(vlen +
strlen(name) -
klen + 1);
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* [PATCH 5/5] Support '*' in the middle of a refspec
From: Daniel Barkalow @ 2009-03-06 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In order to keep the requirements strict, each * has to be a full path
component, and there may only be one * per side. This requirement is
enforced entirely by check_ref_format(); the matching implementation
will substitute the whatever matches the * in the lhs for the * in the
rhs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
refs.c | 11 +++++++----
remote.c | 27 ++++++++++++++++++---------
t/t5511-refspec.sh | 12 ++++++++++++
3 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/refs.c b/refs.c
index a50ba79..fef7c9f 100644
--- a/refs.c
+++ b/refs.c
@@ -694,6 +694,7 @@ static inline int bad_ref_char(int ch)
int check_ref_format(const char *ref)
{
int ch, level, bad_type;
+ int ret = CHECK_REF_FORMAT_OK;
const char *cp = ref;
level = 0;
@@ -709,9 +710,11 @@ int check_ref_format(const char *ref)
return CHECK_REF_FORMAT_ERROR;
bad_type = bad_ref_char(ch);
if (bad_type) {
- return (bad_type == 2 && !*cp)
- ? CHECK_REF_FORMAT_WILDCARD
- : CHECK_REF_FORMAT_ERROR;
+ if (bad_type == 2 && (!*cp || *cp == '/') &&
+ ret == CHECK_REF_FORMAT_OK)
+ ret = CHECK_REF_FORMAT_WILDCARD;
+ else
+ return CHECK_REF_FORMAT_ERROR;
}
/* scan the rest of the path component */
@@ -729,7 +732,7 @@ int check_ref_format(const char *ref)
if (!ch) {
if (level < 2)
return CHECK_REF_FORMAT_ONELEVEL;
- return CHECK_REF_FORMAT_OK;
+ return ret;
}
}
}
diff --git a/remote.c b/remote.c
index d0ce4c6..41005cf 100644
--- a/remote.c
+++ b/remote.c
@@ -511,12 +511,12 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
if (rhs) {
size_t rlen = strlen(++rhs);
- is_glob = (2 <= rlen && !strcmp(rhs + rlen - 2, "/*"));
+ is_glob = (1 <= rlen && strchr(rhs, '*'));
rs[i].dst = xstrndup(rhs, rlen);
}
llen = (rhs ? (rhs - lhs - 1) : strlen(lhs));
- if (2 <= llen && !memcmp(lhs + llen - 2, "/*", 2)) {
+ if (1 <= llen && memchr(lhs, '*', llen)) {
if ((rhs && !is_glob) || (!rhs && fetch))
goto invalid;
is_glob = 1;
@@ -716,15 +716,24 @@ int remote_has_url(struct remote *remote, const char *url)
static int name_fits_pattern(const char *key, const char *name,
const char *value, char **result)
{
- size_t klen = strchr(key, '*') - key;
- int ret = !strncmp(name, key, klen);
+ const char *keystar = strchr(key, '*');
+ size_t klen = keystar - key;
+ size_t ksuffixlen = strlen(keystar + 1);
+ size_t namelen = strlen(name);
+ int ret = !strncmp(name, key, klen) && namelen >= klen + ksuffixlen &&
+ !memcmp(name + namelen - ksuffixlen, keystar + 1, ksuffixlen);
if (ret && value) {
- size_t vlen = strchr(value, '*') - value;
- *result = xmalloc(vlen +
+ const char *valuestar = strchr(value, '*');
+ size_t vlen = valuestar - value;
+ size_t vsuffixlen = strlen(valuestar + 1);
+ *result = xmalloc(vlen + vsuffixlen +
strlen(name) -
- klen + 1);
- strcpy(*result, value);
- strcpy(*result + vlen, name + klen);
+ klen - ksuffixlen + 1);
+ strncpy(*result, value, vlen);
+ strncpy(*result + vlen,
+ name + klen, namelen - klen - ksuffixlen);
+ strcpy(*result + vlen + namelen - klen - ksuffixlen,
+ valuestar + 1);
}
return ret;
}
diff --git a/t/t5511-refspec.sh b/t/t5511-refspec.sh
index 22ba380..c289322 100755
--- a/t/t5511-refspec.sh
+++ b/t/t5511-refspec.sh
@@ -72,4 +72,16 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me'
test_refspec push ':refs/remotes/frotz/delete me' invalid
test_refspec fetch ':refs/remotes/frotz/HEAD to me' invalid
+test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid
+test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid
+
+test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' invalid
+test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' invalid
+
+test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid
+test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid
+
+test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*'
+test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*'
+
test_done
--
1.6.1.286.gd33a4.dirty
^ permalink raw reply related
* Re: [PATCH 0/5] Extend pattern refspecs
From: Jay Soffian @ 2009-03-06 5:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0903052346270.19665@iabervon.org>
On Thu, Mar 5, 2009 at 11:56 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> This series only supports the narrowest case of having the * in the middle
> of a side of a refspec: having it as a full path component on each side.
>
> Patches 1-3 centralize all of the parsing and matching rules to a pair of
> functions; patch 4 makes the stored representation more convenient (and
> serves as a distinguished bisection outcome for anything I missed that was
> relying on the contents of struct refspec for patterns); and patch 5
> extends the matching implementation and loosens the ref format
> requirements to allow the * to be in the middle.
>
> An easy followup would relax the restrictions further without requiring
> any particularly tricky further changes.
This series and js/remote-improvements (e5dcbfd) in pu may not get
along completely. "git remote show" tries to show how the refspecs
expand out. And actually, that should be fine since builtin-remote now
uses the same code as fetch/push to expand the refs.
However, "git remote show -n" (-n means don't query the remote) makes
use of a new function, get_push_ref_states_noquery(), which more or
less tries to reverse the parsed refspec back into the original
string. That function relies on the current (before your patch)
refspec semantics and assumes if refspec.pattern is set, then the '*'
is at the end. So it will need tweaking.
j.
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jeff King @ 2009-03-06 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Miles Bader, git
In-Reply-To: <7vy6vjy5js.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 05, 2009 at 02:21:27PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Yep, it is more invasive. But I consider it more maintainable in the
> > long run.
>
> Why do you think it is more confusing to ask "--date=local --date=iso"
> than asking "--local-time --date=iso"? If the patch under discussion were
> not mine, I would have said that --date=local that flips the "lie about
> timezone" bit and tells us to use the "default" format is a brilliant and
> elegant solution.
Because from the user's perspective --foo={bar,baz,bleep} is about
selecting exactly one of {bar,baz,bleep}. Having --date=local is like
having --pretty=abbrev-commit. Yes, it is vaguely related to date
display, but it is orthogonal to the selection of one of the mutually
exclusive options.
Maybe I am alone in viewing the options this way. But at the very least,
the documentation that reads:
--date={relative,local,default,iso,rfc,short}
should be updated to show that _some_ options are mutually exclusive but
others are not.
> I honestly do not see the point of what you are proposing to make
> "selector" and "format" independent; unless you are shooting for
> "--use-tz=Indian/Christmas --date=iso", that is.
No, I am not really proposing --use-tz as I have no use for it. But it
is an example of why syntactically keeping the orthogonal concept of
"which timezone to use" away from "which date style to use" is useful.
The only reason --date=local _doesn't_ look terrible is that it is a
simple boolean. Any date-related flags that took an argument would look
stupid as --date=option=foo.
-Peff
^ permalink raw reply
* Re: [PATCH] '%S' option for pretty printing to support --source
From: Jeff King @ 2009-03-06 5:25 UTC (permalink / raw)
To: Deskin Miller; +Cc: Petri Hodju, git, gitster, Johannes Schindelin
In-Reply-To: <86d4c5e00903051141u61a131beg26b3df95bafd65d3@mail.gmail.com>
On Thu, Mar 05, 2009 at 02:41:44PM -0500, Deskin Miller wrote:
> > - gracefully block concurrent use of conflicting features
>
> I agree that any blocking should be graceful, but ultimately I find
> the idea of disallowing features because they happen to use the same
> underlying implementation distasteful. With a little work we should
> be able to allow both with no problem.
Yes, I would prefer to avoid blocking if at all possible. But I included
it as a last resort until things can be fixed correctly. IOW, by
"graceful" I just meant "die with an error instead of segfaulting".
Which would still arguably be a bug, but at least would clue the user in
to what is happening.
Anyway, happy moving and I'll look forward to seeing your patch when it
is ready. :)
-Peff
^ permalink raw reply
* Re: [PATCHv4] Make git-clone respect branch.autosetuprebase
From: Junio C Hamano @ 2009-03-06 5:29 UTC (permalink / raw)
To: Pat Notz; +Cc: git
In-Reply-To: <1236308321-13557-1-git-send-email-pknotz@sandia.gov>
"Pat Notz" <pknotz@sandia.gov> writes:
> Signed-off-by: Pat Notz <pknotz@sandia.gov>
Thanks. I do not think there is substantial difference from the one I
queued in 'pu', so I'd keep that one instead, but here are a few comments
for future reference.
> diff --git a/branch.c b/branch.c
> index 1f00e44..332223b 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -32,21 +32,52 @@ static int find_tracked_branch(struct remote *remote, void *priv)
> return 0;
> }
>
> -static int should_setup_rebase(const struct tracking *tracking)
> +static int should_setup_rebase(const char * origin)
"const char *origin";
> +void install_branch_config(int verbose_flag,
> + const char *local,
> + const char *origin,
> + const char *remote)
> +{
I called the parameter "flag" not "verbose" very much on purpose; we can
introduce flags that control aspects other than verbosity if we wanted to
later. Renaming it to verbose_flag defeats the extensibility.
> diff --git a/branch.h b/branch.h
> index 9f0c2a2..9f7fdb0 100644
> --- a/branch.h
> +++ b/branch.h
> @@ -21,4 +21,15 @@ void create_branch(const char *head, const char *name, const char *start_name,
> */
> void remove_branch_state(void);
>
> +/*
> + * Configure local branch "local" to merge remote branch "remote"
> + * taken from origin "origin".
> + */
> +#define BRANCH_CONFIG_QUIET 00
This QUIET is also against the extensible design, as later flags may mean
things unrelated to verbosity. With bitfield "flags" parameter, an unset
bit simply means "do not trigger this feature" and it is customary to pass
0 to such a function when the caller does not want anything special.
^ permalink raw reply
* Gitk - Seeing just a specific remote ?
From: Aneesh Bhasin @ 2009-03-06 5:58 UTC (permalink / raw)
To: git
Hi All,
I have a git repository (say, new_develop) in which a remote
repository (say old_develop) is also there of some older work with the
associated remote branches. Is there a way to see all the branches of
only this remote older_develop repository graphically in gitk -
something that shows me the same thing that doing a 'gitk --all' would
have shown had I done it from the older_develop repository itself ? If
I say 'gitk --all' (in new_develop) it shows me all the branches
(local as well as remote). Specifying 'gitk --remotes' also shows all
the remote branches (not just from the old_develop remote repo) ? Is
there some other way that I am missing ? I have seen the man page of
git-rev-list too but there doesn't sem to be a way to do it.
Regards,
Aneesh
^ permalink raw reply
* Re: [PATCH 0/5] Extend pattern refspecs
From: Daniel Barkalow @ 2009-03-06 6:07 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490903052119y4d6a7e0ck24bfeb1c0964e413@mail.gmail.com>
On Fri, 6 Mar 2009, Jay Soffian wrote:
> On Thu, Mar 5, 2009 at 11:56 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > This series only supports the narrowest case of having the * in the middle
> > of a side of a refspec: having it as a full path component on each side.
> >
> > Patches 1-3 centralize all of the parsing and matching rules to a pair of
> > functions; patch 4 makes the stored representation more convenient (and
> > serves as a distinguished bisection outcome for anything I missed that was
> > relying on the contents of struct refspec for patterns); and patch 5
> > extends the matching implementation and loosens the ref format
> > requirements to allow the * to be in the middle.
> >
> > An easy followup would relax the restrictions further without requiring
> > any particularly tricky further changes.
>
> This series and js/remote-improvements (e5dcbfd) in pu may not get
> along completely. "git remote show" tries to show how the refspecs
> expand out. And actually, that should be fine since builtin-remote now
> uses the same code as fetch/push to expand the refs.
>
> However, "git remote show -n" (-n means don't query the remote) makes
> use of a new function, get_push_ref_states_noquery(), which more or
> less tries to reverse the parsed refspec back into the original
> string. That function relies on the current (before your patch)
> refspec semantics and assumes if refspec.pattern is set, then the '*'
> is at the end. So it will need tweaking.
Actually, you should be able to just drop your "buf" and use spec->src and
spec->dst, since it just stores the original strings. So that should be
easy enough, although it might be good to go through a remote.c function
just in case it becomes more complicated later. On the other hand,
get_head_names() should probably get a patch like my 1/5 to have it use
the remote.c parser, or should use a constant "head mirror" refspec like
that tag_refspec already in remote.c
Do you have tests for "git remote show -n"? Merging my series (on top of
origin/master) and e5dcbfd and adding a final '*' to the string in
get_head_names() made everything pass for me, without doing anything about
the extra *s, but the output is clearly not quite right.
I'm not seeing anything that makes assumptions about the matching
semantics of pattern refspecs, just stuff about how the stored form
relates to the config-file form.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/3] improve bash completion of fetch, pull, and push
From: Sverre Rabbelier @ 2009-03-06 6:43 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Markus Heidelberg, Junio C Hamano, Shawn O . Pearce
In-Reply-To: <cover.1236314073.git.jaysoffian@gmail.com>
Heya,
On Fri, Mar 6, 2009 at 05:39, Jay Soffian <jaysoffian@gmail.com> wrote:
> This series is intended to fix the original issue, as well as provide
> --option completion for all three commands. And, I made a clean spot, so
> I had to clean up a couple other things.
Thanks, I can't comment on the quality of the patch, but I'm glad you
went through the effort of fixing this :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Junio C Hamano @ 2009-03-06 6:50 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, Miles Bader, git
In-Reply-To: <20090306052318.GB3426@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Because from the user's perspective --foo={bar,baz,bleep} is about
> selecting exactly one of {bar,baz,bleep}.
I do not feel very strongly about this either way, and without any prior
end user "Huh?" input, I would probably have argued like you myself, but
I saw the original message from Miles about giving more than one --date
and getting perplexed to see that it did not work, so...
I am not likely to use --tz=Indian/Christmas myself; GMT and local might
however be useful in some situations, though.
^ permalink raw reply
* Re: [PATCH 0/5] Extend pattern refspecs
From: Jay Soffian @ 2009-03-06 6:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0903060038510.19665@iabervon.org>
On Fri, Mar 6, 2009 at 1:07 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Fri, 6 Mar 2009, Jay Soffian wrote:
>
> Actually, you should be able to just drop your "buf" and use spec->src and
> spec->dst, since it just stores the original strings. So that should be
> easy enough, although it might be good to go through a remote.c function
> just in case it becomes more complicated later. On the other hand,
> get_head_names() should probably get a patch like my 1/5 to have it use
> the remote.c parser, or should use a constant "head mirror" refspec like
> that tag_refspec already in remote.c
Okay.
> Do you have tests for "git remote show -n"?
Yes. Apparently not enough of them though if nothing is failing.
> Merging my series (on top of
> origin/master) and e5dcbfd and adding a final '*' to the string in
> get_head_names() made everything pass for me, without doing anything about
> the extra *s, but the output is clearly not quite right.
Hmm, alright.
> I'm not seeing anything that makes assumptions about the matching
> semantics of pattern refspecs, just stuff about how the stored form
> relates to the config-file form.
Okay, that sounds right.
I assume your series will end up in pu soon enough, and I think my
series is about to hop to next. What's the right way to to have them
be happy together?
j.
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jay Soffian @ 2009-03-06 6:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Miles Bader, git
In-Reply-To: <7vmybzw3el.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 6, 2009 at 1:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> Because from the user's perspective --foo={bar,baz,bleep} is about
>> selecting exactly one of {bar,baz,bleep}.
>
> I do not feel very strongly about this either way, and without any prior
> end user "Huh?" input, I would probably have argued like you myself, but
> I saw the original message from Miles about giving more than one --date
> and getting perplexed to see that it did not work, so...
>
> I am not likely to use --tz=Indian/Christmas myself; GMT and local might
> however be useful in some situations, though.
So I don't mind picking this up, but I'd like some guidance. There are
two issues:
1) The CLI. You and Jeff don't seem to have an agreement here, but
frankly, this is the easy part.
2) The internal implementation. Your implementation (enum -> bitfield)
is clever, but Jeff seems to prefer what I suggested (going to a
struct). The latter is quite a bit more work.
If we only care about fixing the original issue, I'll just pickup your
patch, make sure it compiles, and add some tests. I certainly don't
want to do more work than is needed, unless there's a good reason to
do so.
j.
^ permalink raw reply
* Re: [PATCH 0/5] Extend pattern refspecs
From: Daniel Barkalow @ 2009-03-06 7:03 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490903052252y1778aa41g8f3e52329f7bf288@mail.gmail.com>
On Fri, 6 Mar 2009, Jay Soffian wrote:
> On Fri, Mar 6, 2009 at 1:07 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > On Fri, 6 Mar 2009, Jay Soffian wrote:
> >
> > Actually, you should be able to just drop your "buf" and use spec->src and
> > spec->dst, since it just stores the original strings. So that should be
> > easy enough, although it might be good to go through a remote.c function
> > just in case it becomes more complicated later. On the other hand,
> > get_head_names() should probably get a patch like my 1/5 to have it use
> > the remote.c parser, or should use a constant "head mirror" refspec like
> > that tag_refspec already in remote.c
>
> Okay.
>
> > Do you have tests for "git remote show -n"?
>
> Yes. Apparently not enough of them though if nothing is failing.
It only seems to be off by saying:
Local ref configured for 'git push' (status not queried):
refs/heads/** forces to refs/heads/**
so you didn't necessarily miss much, just the one thing I seem to have
broken.
> > Merging my series (on top of
> > origin/master) and e5dcbfd and adding a final '*' to the string in
> > get_head_names() made everything pass for me, without doing anything about
> > the extra *s, but the output is clearly not quite right.
>
> Hmm, alright.
>
> > I'm not seeing anything that makes assumptions about the matching
> > semantics of pattern refspecs, just stuff about how the stored form
> > relates to the config-file form.
>
> Okay, that sounds right.
>
> I assume your series will end up in pu soon enough, and I think my
> series is about to hop to next. What's the right way to to have them
> be happy together?
The only "correctness of outcome" issue is the open-coded refspec
initialization, I think, which is probably actually cleaner to have as a
constant in remote.c anyway (unlike in builtin-clone, there's no
variability at all, so it might as well be a constant.
I can amend my series to avoid adding the extra * in the message when your
series graduates, and it should be clean enough to deal with if your
series wound up getting dropped later; it'll be the only change in that
file for my series, so I'd be able to drop it easily.
It'd be useful to have that message tested by your series, though, so I
can verify my series reliably without worrying about whether I
accidentally dropped both the fix and the test.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Using Git with windows
From: Tariq Hassanen @ 2009-03-06 7:23 UTC (permalink / raw)
To: git
In-Reply-To: <e878dbad0903052321l6c0d310bk2ba568138b409d36@mail.gmail.com>
Hi all,
I know there are some ports for it on windows such as msysGit and it
can also be done on Cygwin.
But is there a way around this if i run a linux VM with Git running
and mount a windows ntfs partition ?
Im trying to keep the power of Git running on linux and the ability to
use Git for .NET apps
Any ideas? Or am i best sticking with SVN until the ports are mature enough?
Tariq
^ permalink raw reply
* Re: [PATCH] Documentation - More examples for git bisect
From: Christian Couder @ 2009-03-06 7:46 UTC (permalink / raw)
To: John Tapsell; +Cc: git
In-Reply-To: <1236256574-24764-1-git-send-email-johnflux@gmail.com>
On a second look here are a few nit picks.
First the patch title could be:
"Documentation: More examples for git bisect"
instead of:
"Documentation - More examples for git bisect"
as it would be more consistent with other patches.
Le jeudi 5 mars 2009, John Tapsell a écrit :
> Including passing parameters to the programs, and running more
> complicated checks without requiring a seperate shell script.
>
> Signed-off-by: John Tapsell
> ---
> Documentation/git-bisect.txt | 18 +++++++++++++++++-
> 1 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 147ea38..e65c1ca 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -212,7 +212,7 @@ If you have a script that can tell if the current
> source code is good or bad, you can automatically bisect using:
>
> ------------
> -$ git bisect run my_script
> +$ git bisect run my_script arguments
> ------------
>
> Note that the "run" script (`my_script` in the above example) should
> @@ -252,6 +252,13 @@ $ git bisect start HEAD v1.2 -- # HEAD is bad,
> v1.2 is good $ git bisect run make # "make" builds the app
> ------------
>
> +* Automatically bisect a test failure between origin and HEAD:
> ++
> +------------
> +$ git bisect start HEAD origin -- # HEAD is bad, origin is good
> +$ git bisect run make test # "make test" builds and tests
> +------------
Perhaps we should add that the above may not work well if there are some
commits that don't build. And that it is fixed in the example below this
one.
> * Automatically bisect a broken test suite:
> +
> ------------
> @@ -291,6 +298,15 @@ It's safer if both "test.sh" and
> "check_test_case.sh" scripts are outside the repo to prevent interactions
> between the bisect, make and test processes and the scripts.
>
> +* Automatically bisect a broken test suite:
The title of the previous example is
* Automatically bisect a broken test case:
so if it is the same, then it should perhaps have the same title or perhaps:
* Automatically bisect a broken test case simplified:
or something like that.
> ++
> +------------
> +$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
> +$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
> +------------
> ++
> +Does the same as the previous example, but on a single line.
> +
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Johannes Sixt @ 2009-03-06 7:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kjetil Barvik, git
In-Reply-To: <7vd4cvzqkl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Record ns-timestamps if possible, but do not use it without USE_NSEC
>
> Traditionally, the lack of USE_NSEC meant "do not record nor use the
> nanosecond resolution part of the file timestamps". To avoid problems on
> filesystems that lose the ns part when the metadata is flushed to the disk
> and then later read back in, disabling USE_NSEC has been a good idea in
> general.
>
> If you are on a filesystem without such an issue, it does not hurt to read
> and store them in the cached stat data in the index entries even if your
> git is compiled without USE_NSEC. The index left with such a version of
> git can be read by git compiled with USE_NSEC and it can make use of the
> nanosecond part to optimize the check to see if the path on the filesystem
> hsa been modified since we last looked at.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
...
> +# Define NO_NSEC if your "struct stat" does not have "st_ctim.tv_nsec"
> +# available. This automatically turns USE_NSEC off.
> +#
...
> @@ -802,6 +805,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> RUNTIME_PREFIX = YesPlease
> NO_POSIX_ONLY_PROGRAMS = YesPlease
> NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
> + NO_NSEC = YesPlease
> COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/regex -Icompat/fnmatch
> COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
> COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
Thanks, with this the build no longer breaks on Windows. But I need this
option on AIX as well:
diff --git a/Makefile b/Makefile
index 137a3ff..b974978 100644
--- a/Makefile
+++ b/Makefile
@@ -737,6 +737,7 @@ ifeq ($(uname_S),AIX)
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
NO_STRLCPY = YesPlease
+ NO_NSEC = YesPlease
FREAD_READS_DIRECTORIES = UnfortunatelyYes
INTERNAL_QSORT = UnfortunatelyYes
NEEDS_LIBICONV=YesPlease
-- Hannes
^ permalink raw reply related
* Re: [PATCH 0/5] Extend pattern refspecs
From: Jay Soffian @ 2009-03-06 7:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0903060153490.19665@iabervon.org>
On Fri, Mar 6, 2009 at 2:03 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> It'd be useful to have that message tested by your series, though, so I
> can verify my series reliably without worrying about whether I
> accidentally dropped both the fix and the test.
I'll send a patch for it in the next day or two.
j.
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Junio C Hamano @ 2009-03-06 8:02 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Miles Bader, git
In-Reply-To: <76718490903052258j277fa8e9g963deae1c3264a22@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Fri, Mar 6, 2009 at 1:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>> Because from the user's perspective --foo={bar,baz,bleep} is about
>>> selecting exactly one of {bar,baz,bleep}.
>>
>> I do not feel very strongly about this either way, and without any prior
>> end user "Huh?" input, I would probably have argued like you myself, but
>> I saw the original message from Miles about giving more than one --date
>> and getting perplexed to see that it did not work, so...
>>
>> I am not likely to use --tz=Indian/Christmas myself; GMT and local might
>> however be useful in some situations, though.
>
> So I don't mind picking this up, but I'd like some guidance. There are
> two issues:
>
> 1) The CLI. You and Jeff don't seem to have an agreement here, but
> frankly, this is the easy part.
>
> 2) The internal implementation. Your implementation (enum -> bitfield)
> is clever, but Jeff seems to prefer what I suggested (going to a
> struct). The latter is quite a bit more work.
Is it? Isn't it just the matter of doing something like this?
struct date_mode {
enum {
DATE_NORMAL = 0,
DATE_RELATIVE,
...
DATE_RAW
} format;
enum {
DATE_ORIGINAL = 0,
DATE_LOCAL
/* perhaps ",DATE_GMT" later... */
} tz_offset;
};
/* In revision.c::handle_revision_opt() */
...
} else if (!strcmp(arg, "--date=local")) {
revs->date_mode.format = DATE_NORMAL;
revs->date_mode.tz_offset = DATE_LOCAL;
} else if (!prefixcmp(arg, "--date=")) {
revs->date_mode.format = parse_date_format(arg + 7);
} else if (!strcmp(arg, "--tz=local")) {
revs->date_mode.tz_offset = DATE_LOCAL;
}
...
/* In date.c::show_date() */
...
const char *show_date(unsigned long time, int tz, struct date_mode *mode_)
{
int mode = mode_->format;
if (mode_->tz_offset == DATE_LOCAL)
tz = local_tzoffset(time);
...
/* and remove the existing
if (mode == DATE_LOCAL)
tz = local_tzoffset(time);
that appears later in the code
*/
...
^ permalink raw reply
* Re: Gitk - Seeing just a specific remote ?
From: Johannes Sixt @ 2009-03-06 8:04 UTC (permalink / raw)
To: Aneesh Bhasin; +Cc: git
In-Reply-To: <f662f0210903052158q77aa0f2fo92c4f4a09c13780e@mail.gmail.com>
Aneesh Bhasin schrieb:
> I have a git repository (say, new_develop) in which a remote
> repository (say old_develop) is also there of some older work with the
> associated remote branches. Is there a way to see all the branches of
> only this remote older_develop repository graphically in gitk -
> something that shows me the same thing that doing a 'gitk --all' would
> have shown had I done it from the older_develop repository itself ? If
> I say 'gitk --all' (in new_develop) it shows me all the branches
> (local as well as remote). Specifying 'gitk --remotes' also shows all
> the remote branches (not just from the old_develop remote repo) ? Is
> there some other way that I am missing ? I have seen the man page of
> git-rev-list too but there doesn't sem to be a way to do it.
gitk has an option, --argscmd, that you can use:
gitk --argscmd="git for-each-ref --format='%(refname)'
refs/remotes/old_develop/*"
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/5] Use the matching function to generate the match results
From: Junio C Hamano @ 2009-03-06 8:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903052355240.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This puts all of the interpretation of the pattern representation in a
> single function for easy manipulation.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
I think this makes sense, but the helper function is not about "does this
name match the pattern?" boolean anymore, and may want to be renamed to
e.g. map_name_with_pattern().
> -static int name_fits_pattern(const char *key, const char *name)
> +static int name_fits_pattern(const char *key, const char *name,
> + const char *value, char **result)
> {
> - int ret = !prefixcmp(key, name);
> + size_t klen = strlen(key);
> + int ret = !strncmp(key, name, klen);
> + if (ret && value) {
> + size_t vlen = strlen(value);
> + *result = xmalloc(vlen +
> + strlen(name) -
> + klen + 1);
> + strcpy(*result, value);
> + strcpy(*result + vlen, name + klen);
> + }
> @@ -1080,11 +1085,9 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
>
> } else {
> const char *dst_side = pat->dst ? pat->dst : pat->src;
> - dst_name = xmalloc(strlen(dst_side) +
> - strlen(src->name) -
> - strlen(pat->src) + 2);
> - strcpy(dst_name, dst_side);
> - strcat(dst_name, src->name + strlen(pat->src));
> + if (!name_fits_pattern(pat->src, src->name,
> + dst_side, &dst_name))
> + die("Didn't think it matches any more");
> }
Hmm, we have been overallocating and nobody noticed so far?
^ permalink raw reply
* Re: [PATCH 4/5] Keep '*' in pattern refspecs
From: Junio C Hamano @ 2009-03-06 8:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903052355480.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> In order to do anything more capable with refspecs, the first step is
> to keep the entire input. Additionally, validate patterns by checking
> for the ref matching the rules for a pattern as given by
> check_ref_format(). This requires a slight change to make it require
> the '*' to be at the beginning of a path component.
I had a brief "Huh?" moment wondering about this "slight change", but at
this stage it does not change the rule at all ("/*" still must happen at
the end of the string), so there actually is no change.
> diff --git a/remote.c b/remote.c
> index 93fd03d..d0ce4c6 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -722,10 +716,10 @@ int remote_has_url(struct remote *remote, const char *url)
> static int name_fits_pattern(const char *key, const char *name,
> const char *value, char **result)
> {
> - size_t klen = strlen(key);
> - int ret = !strncmp(key, name, klen);
> + size_t klen = strchr(key, '*') - key;
> + int ret = !strncmp(name, key, klen);
Any particular reason why the first parameters to strncmp() were swapped?
> if (ret && value) {
> - size_t vlen = strlen(value);
> + size_t vlen = strchr(value, '*') - value;
We would want protection from programming error here, to catch keys and
values without any asterisk. This comment also applies to [5/5].
> *result = xmalloc(vlen +
> strlen(name) -
> klen + 1);
^ permalink raw reply
* What's in git.git (Mar 2009, #03; Fri, 06)
From: Junio C Hamano @ 2009-03-06 8:26 UTC (permalink / raw)
To: git
Quite a many topics that have been scheduled for 'master' for some time
have all graduated. With this pace we may be able to have a very short
cycle for a change before 1.6.3 final ;-).
* The 'master' branch has these since the last announcement.
Arjen Laarhoven (2):
Clean up use of ANSI color sequences
builtin-branch.c: Rename branch category color names
Deskin Miller (1):
add -i: revisit hunk on editor failure
Elijah Newren (1):
Ensure proper setup of git_dir for git-hash-object
Felipe Contreras (3):
config: Add new option to open an editor.
git config: codestyle cleanups
Add tests for git log --pretty, --format and --oneline.
Finn Arne Gangstad (1):
Support "\" in non-wildcard exclusion entries
Jay Soffian (6):
builtin-branch: improve output when displaying remote branches
send-email: allow send-email to run outside a repo
send-email: handle multiple Cc addresses when reading mbox message
send-email: --suppress-cc improvements
send-email: don't create temporary compose file until it is needed
send-email: add --confirm option and configuration setting
Jeff King (4):
valgrind: ignore ldso and more libz errors
branch: clean up repeated strlen
add basic branch display tests
never fallback relative times to absolute
Jeremy White (2):
Enable setting attach as the default in .gitconfig for git-format-patch.
imap.preformattedHTML to tell Thunderbird to send non-flowed text
Johannes Schindelin (11):
Add valgrind support in test scripts
Valgrind support: check for more than just programming errors
test-lib.sh: optionally output to test-results/$TEST.out, too
t/Makefile: provide a 'valgrind' target
Add a script to coalesce the valgrind outputs
Tests: let --valgrind imply --verbose and --tee
test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
valgrind: do not require valgrind 3.4.0 or newer
Avoid segfault with 'git branch' when the HEAD is detached
git config: trivial cleanup for editor action
MinGW: 64-bit file offsets
John Tapsell (1):
Documentation - More examples for git bisect
Junio C Hamano (4):
git-blame: refactor code to emit "porcelain format" output
blame: show "previous" information in --porcelain/--incremental format
git-add -i/-p: learn to unwrap C-quoted paths
Draft release notes: Carry forward the warning for behaviour changes
Marius Storm-Olsen (2):
Add bare repository indicator for __git_ps1
Fixup: Add bare repository indicator for __git_ps1
Nanako Shiraishi (3):
Add --format that is a synonym to --pretty
Give short-hands to --pretty=tformat:%formatstring
Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"
SZEDER Gábor (1):
rerere: remove duplicated functions
Sverre Rabbelier (1):
Teach rebase to rebase even if upstream is up to date
Ted Pavlic (4):
completion: For consistency, change "git rev-parse" to __gitdir calls
completion: Use consistent if [...] convention, not "test"
completion: Better __git_ps1 support when not in working directory
completion: More fixes to prevent unbound variable errors
Teemu Likonen (1):
bash completion: add --format= and --oneline options for "git log"
^ 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