* [PATCH 1/5] checkout: record full target ref in reflog
From: Nguyễn Thái Ngọc Duy @ 2013-03-03 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Matthieu Moy, Jonathan Niedier,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1362303681-6585-1-git-send-email-pclouds@gmail.com>
This simplifies parsing later on because the parser does not need to
do dwim on the target (and later dwim may be ambiguous if new refs are
added).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/checkout.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index a9c1b5a..b11bd31 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -398,6 +398,7 @@ static int reset_tree(struct tree *tree, const struct checkout_opts *o,
struct branch_info {
const char *name; /* The short name used */
+ const char *full_ref; /* The full name of a real ref */
const char *path; /* The full name of a real branch */
struct commit *commit; /* The named commit */
};
@@ -589,7 +590,8 @@ static void update_refs_for_switch(const struct checkout_opts *opts,
if (!old_desc && old->commit)
old_desc = sha1_to_hex(old->commit->object.sha1);
strbuf_addf(&msg, "checkout: moving from %s to %s",
- old_desc ? old_desc : "(invalid)", new->name);
+ old_desc ? old_desc : "(invalid)",
+ new->full_ref ? new->full_ref : new->name);
if (!strcmp(new->name, "HEAD") && !new->path && !opts->force_detach) {
/* Nothing to do. */
@@ -907,10 +909,21 @@ static int parse_branchname_arg(int argc, const char **argv,
setup_branch_path(new);
if (!check_refname_format(new->path, 0) &&
- !read_ref(new->path, branch_rev))
+ !read_ref(new->path, branch_rev)) {
hashcpy(rev, branch_rev);
- else
+ new->full_ref = xstrdup(new->path);
+ } else {
+ char *real_ref = NULL;
+ unsigned char sha1[20];
new->path = NULL; /* not an existing branch */
+ if (dwim_ref(new->name, strlen(new->name), sha1,
+ &real_ref) == 1 &&
+ !hashcmp(sha1, rev)) {
+ new->full_ref = real_ref;
+ real_ref = NULL;
+ }
+ free(real_ref);
+ }
new->commit = lookup_commit_reference_gently(rev, 1);
if (!new->commit) {
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH 3/5] wt-status: move wt_status_get_state() out to wt_status_print()
From: Nguyễn Thái Ngọc Duy @ 2013-03-03 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Matthieu Moy, Jonathan Niedier,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1362303681-6585-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
wt-status.c | 37 +++++++++++++++++++------------------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 183aafe..6a3566b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1044,31 +1044,29 @@ void wt_status_get_state(struct wt_status_state *state)
strbuf_release(&onto);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_print_state(struct wt_status *s,
+ struct wt_status_state *state)
{
const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
-
- wt_status_get_state(&state);
-
- if (state.merge_in_progress)
- show_merge_in_progress(s, &state, state_color);
- else if (state.am_in_progress)
- show_am_in_progress(s, &state, state_color);
- else if (state.rebase_in_progress || state.rebase_interactive_in_progress)
- show_rebase_in_progress(s, &state, state_color);
- else if (state.cherry_pick_in_progress)
- show_cherry_pick_in_progress(s, &state, state_color);
- if (state.bisect_in_progress)
- show_bisect_in_progress(s, &state, state_color);
- free(state.branch);
- free(state.onto);
+ if (state->merge_in_progress)
+ show_merge_in_progress(s, state, state_color);
+ else if (state->am_in_progress)
+ show_am_in_progress(s, state, state_color);
+ else if (state->rebase_in_progress || state->rebase_interactive_in_progress)
+ show_rebase_in_progress(s, state, state_color);
+ else if (state->cherry_pick_in_progress)
+ show_cherry_pick_in_progress(s, state, state_color);
+ if (state->bisect_in_progress)
+ show_bisect_in_progress(s, state, state_color);
}
void wt_status_print(struct wt_status *s)
{
const char *branch_color = color(WT_STATUS_ONBRANCH, s);
const char *branch_status_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(&state);
if (s->branch) {
const char *on_what = _("On branch ");
@@ -1087,7 +1085,10 @@ void wt_status_print(struct wt_status *s)
wt_status_print_tracking(s);
}
- wt_status_print_state(s);
+ wt_status_print_state(s, &state);
+ free(state.branch);
+ free(state.onto);
+
if (s->is_initial) {
status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH 2/5] wt-status: split wt_status_state parsing function out
From: Nguyễn Thái Ngọc Duy @ 2013-03-03 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Matthieu Moy, Jonathan Niedier,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1362303681-6585-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
wt-status.c | 52 +++++++++++++++++++++++++++++++---------------------
wt-status.h | 5 +++--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index ef405d0..183aafe 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -970,7 +970,7 @@ static void show_bisect_in_progress(struct wt_status *s,
* Extract branch information from rebase/bisect
*/
static void read_and_strip_branch(struct strbuf *sb,
- const char **branch,
+ char **branch,
const char *path)
{
unsigned char sha1[20];
@@ -994,52 +994,62 @@ static void read_and_strip_branch(struct strbuf *sb,
strbuf_addstr(sb, abbrev);
*branch = sb->buf;
} else if (!strcmp(sb->buf, "detached HEAD")) /* rebase */
- ;
+ *branch = NULL;
else /* bisect */
*branch = sb->buf;
+ if (*branch)
+ *branch = xstrdup(*branch);
}
-static void wt_status_print_state(struct wt_status *s)
+void wt_status_get_state(struct wt_status_state *state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
struct strbuf branch = STRBUF_INIT;
struct strbuf onto = STRBUF_INIT;
- struct wt_status_state state;
struct stat st;
- memset(&state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
if (!stat(git_path("MERGE_HEAD"), &st)) {
- state.merge_in_progress = 1;
+ state->merge_in_progress = 1;
} else if (!stat(git_path("rebase-apply"), &st)) {
if (!stat(git_path("rebase-apply/applying"), &st)) {
- state.am_in_progress = 1;
+ state->am_in_progress = 1;
if (!stat(git_path("rebase-apply/patch"), &st) && !st.st_size)
- state.am_empty_patch = 1;
+ state->am_empty_patch = 1;
} else {
- state.rebase_in_progress = 1;
- read_and_strip_branch(&branch, &state.branch,
+ state->rebase_in_progress = 1;
+ read_and_strip_branch(&branch, &state->branch,
"rebase-apply/head-name");
- read_and_strip_branch(&onto, &state.onto,
+ read_and_strip_branch(&onto, &state->onto,
"rebase-apply/onto");
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
- state.rebase_interactive_in_progress = 1;
+ state->rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
- read_and_strip_branch(&branch, &state.branch,
+ state->rebase_in_progress = 1;
+ read_and_strip_branch(&branch, &state->branch,
"rebase-merge/head-name");
- read_and_strip_branch(&onto, &state.onto,
+ read_and_strip_branch(&onto, &state->onto,
"rebase-merge/onto");
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
- state.cherry_pick_in_progress = 1;
+ state->cherry_pick_in_progress = 1;
}
if (!stat(git_path("BISECT_LOG"), &st)) {
- state.bisect_in_progress = 1;
- read_and_strip_branch(&branch, &state.branch,
+ state->bisect_in_progress = 1;
+ read_and_strip_branch(&branch, &state->branch,
"BISECT_START");
}
+ strbuf_release(&branch);
+ strbuf_release(&onto);
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(&state);
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
@@ -1051,8 +1061,8 @@ static void wt_status_print_state(struct wt_status *s)
show_cherry_pick_in_progress(s, &state, state_color);
if (state.bisect_in_progress)
show_bisect_in_progress(s, &state, state_color);
- strbuf_release(&branch);
- strbuf_release(&onto);
+ free(state.branch);
+ free(state.onto);
}
void wt_status_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 81e1dcf..5ddcbf6 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,13 +79,14 @@ struct wt_status_state {
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
- const char *branch;
- const char *onto;
+ char *branch;
+ char *onto;
};
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
+void wt_status_get_state(struct wt_status_state *state);
void wt_shortstatus_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH 4/5] status: show the ref that is checked out, even if it's detached
From: Nguyễn Thái Ngọc Duy @ 2013-03-03 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Matthieu Moy, Jonathan Niedier,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1362303681-6585-1-git-send-email-pclouds@gmail.com>
When a remote ref or a tag is checked out, HEAD is automatically
detached. There is no user friendly way to find out what ref is
checked out in this case. This patch digs in reflog for this
information and shows "Detached from origin/master" or "Detached from
v1.8.0" instead of "Currently not on any branch".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
wt-status.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
wt-status.h | 3 ++-
2 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 6a3566b..4b6421a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1001,7 +1001,60 @@ static void read_and_strip_branch(struct strbuf *sb,
*branch = xstrdup(*branch);
}
-void wt_status_get_state(struct wt_status_state *state)
+struct grab_1st_switch_cbdata {
+ struct strbuf buf;
+ unsigned char sha1[20];
+};
+
+static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,
+ const char *email, unsigned long timestamp, int tz,
+ const char *message, void *cb_data)
+{
+ struct grab_1st_switch_cbdata *cb = cb_data;
+ const char *target = NULL;
+
+ if (prefixcmp(message, "checkout: moving from "))
+ return 0;
+ message += strlen("checkout: moving from ");
+ target = strstr(message, " to ");
+ if (!target)
+ return 0;
+ target += strlen(" to ");
+ strbuf_reset(&cb->buf);
+ hashcpy(cb->sha1, nsha1);
+ if (!prefixcmp(target, "refs/")) {
+ const char *end = target;
+ while (*end && *end != '\n')
+ end++;
+ strbuf_add(&cb->buf, target, end - target);
+ }
+ return 0;
+}
+
+static void wt_status_get_detached_from(struct wt_status_state *state)
+{
+ struct grab_1st_switch_cbdata cb;
+ struct commit *commit;
+ unsigned char sha1[20];
+
+ strbuf_init(&cb.buf, 0);
+ for_each_recent_reflog_ent("HEAD", grab_1st_switch, 40960, &cb);
+ if (cb.buf.len &&
+ !read_ref(cb.buf.buf, sha1) &&
+ (commit = lookup_commit_reference_gently(sha1, 1)) != NULL &&
+ !hashcmp(cb.sha1, commit->object.sha1)) {
+ int ofs = 0;
+ if (!prefixcmp(cb.buf.buf, "refs/tags/"))
+ ofs = strlen("refs/tags/");
+ else if (!prefixcmp(cb.buf.buf, "refs/remotes/"))
+ ofs = strlen("refs/remotes/");
+ state->detached_from = xstrdup(cb.buf.buf + ofs);
+ }
+ strbuf_release(&cb.buf);
+}
+
+void wt_status_get_state(struct wt_status_state *state,
+ int get_detached_from)
{
struct strbuf branch = STRBUF_INIT;
struct strbuf onto = STRBUF_INIT;
@@ -1040,6 +1093,10 @@ void wt_status_get_state(struct wt_status_state *state)
read_and_strip_branch(&branch, &state->branch,
"BISECT_START");
}
+
+ if (get_detached_from)
+ wt_status_get_detached_from(state);
+
strbuf_release(&branch);
strbuf_release(&onto);
}
@@ -1066,7 +1123,8 @@ void wt_status_print(struct wt_status *s)
const char *branch_status_color = color(WT_STATUS_HEADER, s);
struct wt_status_state state;
- wt_status_get_state(&state);
+ wt_status_get_state(&state,
+ s->branch && !strcmp(s->branch, "HEAD"));
if (s->branch) {
const char *on_what = _("On branch ");
@@ -1074,9 +1132,14 @@ void wt_status_print(struct wt_status *s)
if (!prefixcmp(branch_name, "refs/heads/"))
branch_name += 11;
else if (!strcmp(branch_name, "HEAD")) {
- branch_name = "";
branch_status_color = color(WT_STATUS_NOBRANCH, s);
- on_what = _("Not currently on any branch.");
+ if (state.detached_from) {
+ branch_name = state.detached_from;
+ on_what = _("Detached from ");
+ } else {
+ branch_name = "";
+ on_what = _("Not currently on any branch.");
+ }
}
status_printf(s, color(WT_STATUS_HEADER, s), "");
status_printf_more(s, branch_status_color, "%s", on_what);
@@ -1088,6 +1151,7 @@ void wt_status_print(struct wt_status *s)
wt_status_print_state(s, &state);
free(state.branch);
free(state.onto);
+ free(state.detached_from);
if (s->is_initial) {
status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
diff --git a/wt-status.h b/wt-status.h
index 5ddcbf6..74c9055 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -81,12 +81,13 @@ struct wt_status_state {
int bisect_in_progress;
char *branch;
char *onto;
+ char *detached_from;
};
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
-void wt_status_get_state(struct wt_status_state *state);
+void wt_status_get_state(struct wt_status_state *state, int get_detached_from);
void wt_shortstatus_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH 5/5] branch: show more information when HEAD is detached
From: Nguyễn Thái Ngọc Duy @ 2013-03-03 9:41 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Matthieu Moy, Jonathan Niedier,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1362303681-6585-1-git-send-email-pclouds@gmail.com>
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases? Is it detached because the user checks out a remote ref or a
tag (and which one)?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/branch.c | 25 ++++++++++++++++++++++++-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 6371bf9..02dee0d 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -18,6 +18,7 @@
#include "string-list.h"
#include "column.h"
#include "utf8.h"
+#include "wt-status.h"
static const char * const builtin_branch_usage[] = {
N_("git branch [options] [-r | -a] [--merged | --no-merged]"),
@@ -550,6 +551,28 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description()
+{
+ struct strbuf desc = STRBUF_INIT;
+ struct wt_status_state state;
+ wt_status_get_state(&state, 1);
+ if (state.rebase_in_progress ||
+ state.rebase_interactive_in_progress)
+ strbuf_addf(&desc, _("(no branch, rebasing %s)"),
+ state.branch);
+ else if (state.bisect_in_progress)
+ strbuf_addf(&desc, _("(no branch, bisecting %s)"),
+ state.branch);
+ else if (state.detached_from)
+ strbuf_addf(&desc, _("(detached from %s)"),
+ state.detached_from);
+ else
+ strbuf_addstr(&desc, _("(no branch)"));
+ free(state.branch);
+ free(state.onto);
+ free(state.detached_from);
+ return strbuf_detach(&desc, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +580,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit && is_descendant_of(head_commit, ref_list->with_commit)) {
struct ref_item item;
- item.name = xstrdup(_("(no branch)"));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..9b6f0d0 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
cp .git/BISECT_START saved &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
- test_i18ngrep "* (no branch)" branch.output > /dev/null &&
+ test_i18ngrep "* (no branch, bisecting other)" branch.output > /dev/null &&
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* What's cooking in git.git (Mar 2013, #01; Sun, 3)
From: Junio C Hamano @ 2013-03-03 10:00 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'.
The tip of the 'master' is at 1.8.2-rc2. Hopefully we can tag the
final in the middle of the month.
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
--------------------------------------------------
[Graduated to "master"]
* mh/maint-ceil-absolute (2013-02-22) 1 commit
(merged to 'next' on 2013-02-26 at ba83c45)
+ Provide a mechanism to turn off symlink resolution in ceiling paths
An earlier workaround designed to help people who list logical
directories that will not match what getcwd(3) returns in the
GIT_CEILING_DIRECTORIES had an adverse effect when it is slow to
stat and readlink a directory component of an element listed on it.
--------------------------------------------------
[New Topics]
* kb/name-hash (2013-02-27) 1 commit
- name-hash.c: fix endless loop with core.ignorecase=true
The code to keep track of what directory names are known to Git on
platforms with case insensitive filesystems can get confused upon
a hash collision between these pathnames and looped forever.
* rs/zip-compresssed-size-with-export-subst (2013-02-27) 1 commit
(merged to 'next' on 2013-03-03 at c1ac6d8)
+ archive-zip: fix compressed size for stored export-subst files
When export-subst is used, "zip" output recorded incorrect
size of the file.
Will cook in 'next'.
* hv/config-from-strbuf (2013-02-28) 4 commits
- teach config parsing to read from strbuf
- config: make parsing stack struct independent from actual data source
- config: drop file pointer validity check in get_next_char()
- config: factor out config file stack management
* jc/describe (2013-02-28) 1 commit
- describe: --match=<pattern> must limit the refs even when used with --all
Comments?
* jk/mailsplit-maildir-muttsort (2013-03-02) 1 commit
(merged to 'next' on 2013-03-03 at d5f7735)
+ mailsplit: sort maildir filenames more cleverly
Will cook in 'next'.
* pc/subtree-add-before-fetch (2013-02-28) 1 commit
- contrib/subtree: allow addition of remote branch with name not locally present
Comments?
* tr/line-log (2013-02-28) 5 commits
- log -L: :pattern:file syntax to find by funcname
- Implement line-history search (git log -L)
- Export rewrite_parents() for 'log -L'
- blame: introduce $ as "end of file" in -L syntax
- Refactor parse_loc
--------------------------------------------------
[Stalled]
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
There seems to be some interest. Let's see if it results in a solid
execution of a sensible transition plan towards Git 2.0.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* jc/perl-cat-blob (2013-02-22) 1 commit
(merged to 'next' on 2013-02-25 at 7c0079a)
+ Git.pm: fix cat_blob crashes on large files
perl/Git.pm::cat_blob slurped everything in core only to write it
out to a file descriptor, which was not a very smart thing to do.
Will cook in 'next'.
* nd/doc-index-format (2013-02-23) 3 commits
(merged to 'next' on 2013-02-26 at 4d3caea)
+ update-index: list supported idx versions and their features
+ read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr()
+ index-format.txt: mention of v4 is missing in some places
Update the index format documentation to mention the v4 format.
Will cook in 'next'.
* ap/maint-diff-rename-avoid-overlap (2013-03-02) 3 commits
- tests: make sure rename pretty print works
(merged to 'next' on 2013-02-26 at 19d70bf)
+ diff: prevent pprint_rename from underrunning input
(merged to 'next' on 2013-02-25 at c9bd6d3)
+ diff: Fix rename pretty-print when suffix and prefix overlap
The logic used by "git diff -M --stat" to shorten the names of
files before and after a rename did not work correctly when the
common prefix and suffix between the two filenames overlapped.
Will cook in 'next' (the tip may still be rerolled).
* ap/maint-update-index-h-is-for-help (2013-02-23) 1 commit
(merged to 'next' on 2013-02-25 at f5f767c)
+ update-index: allow "-h" to also display options
Will cook in 'next'.
* jc/color-diff-doc (2013-02-22) 1 commit
(merged to 'next' on 2013-02-25 at c37541c)
+ diff-options: unconfuse description of --color
Will cook in 'next'.
* nd/branch-error-cases (2013-02-23) 1 commit
(merged to 'next' on 2013-02-25 at 1d0289f)
+ branch: segfault fixes and validation
"git branch" had more cases where it did not bother to check
nonsense command line parameters.
Will cook in 'next'.
* rt/commit-cleanup-config (2013-02-23) 1 commit
(merged to 'next' on 2013-02-25 at 8249b61)
+ t7502: perform commits using alternate editor in a subshell
Fix tests that contaminated their environments and affected new
tests introduced later in the sequence by containing their effects
in their own subshells.
Will cook in 'next'.
* wk/doc-pre-rebase (2013-02-24) 1 commit
(merged to 'next' on 2013-02-25 at a6ec310)
+ Documentation/githooks: Explain pre-rebase parameters
Will cook in 'next'.
* da/downcase-u-in-usage (2013-02-24) 20 commits
(merged to 'next' on 2013-02-26 at 977b67e)
+ contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
+ contrib/examples/git-remote.perl: use a lowercase "usage:" string
+ tests: use a lowercase "usage:" string
+ git-svn: use a lowercase "usage:" string
+ Documentation/user-manual.txt: use a lowercase "usage:" string
+ templates/hooks--update.sample: use a lowercase "usage:" string
+ contrib/hooks/setgitperms.perl: use a lowercase "usage:" string
+ contrib/examples: use a lowercase "usage:" string
+ contrib/fast-import/import-zips.py: use spaces instead of tabs
+ contrib/fast-import/import-zips.py: fix broken error message
+ contrib/fast-import: use a lowercase "usage:" string
+ contrib/credential: use a lowercase "usage:" string
+ git-cvsimport: use a lowercase "usage:" string
+ git-cvsimport: use a lowercase "usage:" string
+ git-cvsexportcommit: use a lowercase "usage:" string
+ git-archimport: use a lowercase "usage:" string
+ git-merge-one-file: use a lowercase "usage:" string
+ git-relink: use a lowercase "usage:" string
+ git-svn: use a lowercase "usage:" string
+ git-sh-setup: use a lowercase "usage:" string
Will cook in 'next'.
* dm/ni-maxhost-may-be-missing (2013-02-25) 1 commit
(merged to 'next' on 2013-02-26 at 93ec2c9)
+ git-compat-util.h: Provide missing netdb.h definitions
Will cook in 'next'.
* gp/avoid-explicit-mention-of-dot-git-refs (2013-02-24) 1 commit
(merged to 'next' on 2013-02-26 at ec42d98)
+ Fix ".git/refs" stragglers
Will cook in 'next'.
* gp/describe-match-uses-glob-pattern (2013-02-24) 1 commit
(merged to 'next' on 2013-02-26 at c9cc789)
+ describe: Document --match pattern format
(this branch is used by gp/forbid-describe-all-match.)
Will cook in 'next'.
* gp/forbid-describe-all-match (2013-02-24) 1 commit
- describe: make --all and --match=PATTERN mutually incompatible
(this branch uses gp/describe-match-uses-glob-pattern.)
"describe --match=<pattern> --all <commit>" ought to mean "use refs
that match <pattern> to describe <commit>; you do not have to limit
yourself to annotated tags." But it doesn't. Disable the
combination.
We may want to discard this if jc/describe topic turns out to be a
better idea.
* jk/common-make-variables-export-safety (2013-02-25) 1 commit
- Makefile: make mandir, htmldir and infodir absolute
Make the three variables safer to be exported to submakes by
ensuring that they are full paths so that they can be used as
installation location.
* jk/suppress-clang-warning (2013-02-25) 1 commit
- fix clang -Wtautological-compare with unsigned enum
* mg/qnx6 (2013-02-25) 1 commit
- QNX: newer QNX 6.x.x is not so crippled
Still under discussion.
Not ready for inclusion.
* mg/unsigned-time-t (2013-02-25) 2 commits
- Fix time offset calculation in case of unsigned time_t
- date.c: fix unsigned time_t comparison
A few workarounds for systems with unsigned time_t.
* rj/msvc-build (2013-02-25) 5 commits
(merged to 'next' on 2013-02-26 at 7493068)
+ msvc: avoid collisions between "tags" and "TAGS"
+ msvc: test-svn-fe: Fix linker "unresolved external" error
+ msvc: Fix build by adding missing symbol defines
+ msvc: git-daemon: Fix linker "unresolved external" errors
+ msvc: Fix compilation errors caused by poll.h emulation
Will cook in 'next'.
* wk/user-manual-literal-format (2013-02-25) 1 commit
(merged to 'next' on 2013-02-26 at d59ce38)
+ user-manual: Standardize backtick quoting
Will cook in 'next'.
* jk/utf-8-can-be-spelled-differently (2013-02-25) 1 commit
(merged to 'next' on 2013-02-26 at c079525)
+ utf8: accept alternate spellings of UTF-8
Will cook in 'next'.
* jk/pkt-line-cleanup (2013-02-24) 19 commits
(merged to 'next' on 2013-02-25 at d83e970)
+ remote-curl: always parse incoming refs
+ remote-curl: move ref-parsing code up in file
+ remote-curl: pass buffer straight to get_remote_heads
+ teach get_remote_heads to read from a memory buffer
+ pkt-line: share buffer/descriptor reading implementation
+ pkt-line: provide a LARGE_PACKET_MAX static buffer
+ pkt-line: move LARGE_PACKET_MAX definition from sideband
+ pkt-line: teach packet_read_line to chomp newlines
+ pkt-line: provide a generic reading function with options
+ pkt-line: drop safe_write function
+ pkt-line: move a misplaced comment
+ write_or_die: raise SIGPIPE when we get EPIPE
+ upload-archive: use argv_array to store client arguments
+ upload-archive: do not copy repo name
+ send-pack: prefer prefixcmp over memcmp in receive_status
+ fetch-pack: fix out-of-bounds buffer offset in get_ack
+ upload-pack: remove packet debugging harness
+ upload-pack: do not add duplicate objects to shallow list
+ upload-pack: use get_sha1_hex to parse "shallow" lines
Cleans up pkt-line API, implementation and its callers to make
them more robust.
Will cook in 'next'.
* ob/imap-send-ssl-verify (2013-02-20) 1 commit
(merged to 'next' on 2013-02-25 at e897609)
+ imap-send: support Server Name Indication (RFC4366)
Correctly connect to SSL/TLS sites that serve multiple hostnames on
a single IP by including Server Name Indication in the client-hello.
Will cook in 'next'.
* jc/format-patch (2013-02-21) 2 commits
- format-patch: --inline-single
- format-patch: rename "no_inline" field
A new option to send a single patch to the standard output to be
appended at the bottom of a message. I personally have no need for
this, but it was easy enough to cobble together. Tests, docs and
stripping out more MIMEy stuff are left as exercises to interested
parties.
Not ready for inclusion.
* tk/doc-filter-branch (2013-02-26) 2 commits
(merged to 'next' on 2013-02-26 at bd4638b)
+ Documentation: filter-branch env-filter example
+ git-filter-branch.txt: clarify ident variables usage
Will cook in 'next'.
* bc/commit-complete-lines-given-via-m-option (2013-02-19) 4 commits
(merged to 'next' on 2013-02-19 at cf622b7)
+ Documentation/git-commit.txt: rework the --cleanup section
+ git-commit: only append a newline to -m mesg if necessary
+ t7502: demonstrate breakage with a commit message with trailing newlines
+ t/t7502: compare entire commit message with what was expected
'git commit -m "$str"' when $str was already terminated with a LF
now avoids adding an extra LF to the message.
Will cook in 'next'.
* da/difftool-fixes (2013-02-21) 4 commits
(merged to 'next' on 2013-02-25 at 687db1f)
+ t7800: "defaults" is no longer a builtin tool name
+ t7800: modernize tests
+ t7800: update copyright notice
+ difftool: silence uninitialized variable warning
Minor maintenance updates to difftool, and updates to its tests.
Will cook in 'next'.
* nd/read-directory-recursive-optim (2013-02-17) 1 commit
(merged to 'next' on 2013-02-17 at 36ba9f4)
+ read_directory: avoid invoking exclude machinery on tracked files
"git status" has been optimized by taking advantage of the fact
that paths that are already known to the index do not have to be
checked against the .gitignore mechanism under some conditions.
Will cook in 'next'.
* mg/gpg-interface-using-status (2013-02-14) 5 commits
(merged to 'next' on 2013-02-26 at 93f0e72)
+ pretty: make %GK output the signing key for signed commits
+ pretty: parse the gpg status lines rather than the output
+ gpg_interface: allow to request status return
+ log-tree: rely upon the check in the gpg_interface
+ gpg-interface: check good signature in a reliable way
Call "gpg" using the right API when validating the signature on
tags.
Will cook in 'next'.
* jn/shell-disable-interactive (2013-02-11) 2 commits
- shell: pay attention to exit status from 'help' command
- shell doc: emphasize purpose and security model
Expecting a reroll.
$gmane/216229
* jc/fetch-raw-sha1 (2013-02-07) 4 commits
(merged to 'next' on 2013-02-14 at ffa3c65)
+ fetch: fetch objects by their exact SHA-1 object names
+ upload-pack: optionally allow fetching from the tips of hidden refs
+ fetch: use struct ref to represent refs to be fetched
+ parse_fetch_refspec(): clarify the codeflow a bit
Allows requests to fetch objects at any tip of refs (including
hidden ones). It seems that there may be use cases even outside
Gerrit (e.g. $gmane/215701).
Will cook in 'next'.
* mn/send-email-works-with-credential (2013-02-27) 6 commits
(merged to 'next' on 2013-02-27 at ee7ae0e)
+ git-send-email: use git credential to obtain password
+ Git.pm: add interface for git credential command
+ Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipe
+ Git.pm: refactor command_close_bidi_pipe to use _cmd_close
+ Git.pm: fix example in command_close_bidi_pipe documentation
+ Git.pm: allow command_close_bidi_pipe to be called as method
Hooks the credential system to send-email.
Will cook in 'next'.
* nd/branch-show-rebase-bisect-state (2013-02-08) 1 commit
- branch: show rebase/bisect info when possible instead of "(no branch)"
Expecting a reroll.
$gmane/215771
* nd/count-garbage (2013-02-15) 4 commits
(merged to 'next' on 2013-02-17 at b2af923)
+ count-objects: report how much disk space taken by garbage files
+ count-objects: report garbage files in pack directory too
+ sha1_file: reorder code in prepare_packed_git_one()
+ git-count-objects.txt: describe each line in -v output
Will cook in 'next'.
* tz/credential-authinfo (2013-02-25) 1 commit
(merged to 'next' on 2013-02-27 at 7a261cb)
+ Add contrib/credentials/netrc with GPG support
A new read-only credential helper (in contrib/) to interact with
the .netrc/.authinfo files. Hopefully mn/send-email-authinfo topic
can rebuild on top of something like this.
Will cook in 'next'.
* jl/submodule-deinit (2013-02-17) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/216498
* jc/remove-export-from-config-mak-in (2013-02-12) 2 commits
(merged to 'next' on 2013-02-12 at eb8af04)
+ Makefile: do not export mandir/htmldir/infodir
(merged to 'next' on 2013-02-07 at 33f7d4f)
+ config.mak.in: remove unused definitions
config.mak.in template had an "export" line to cause a few
common makefile variables to be exported; if they need to be
expoted for autoconf/configure users, they should also be exported
for people who write config.mak the same way. Move the "export" to
the main Makefile. Also, stop exporting mandir that used to be
exported (only) when config.mak.autogen was used. It would have
broken installation of manpages (but not other documentation
formats).
Will cook in 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will cook in 'next'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0.
* bc/append-signed-off-by (2013-02-23) 13 commits
(merged to 'next' on 2013-02-25 at 32f7ac2)
+ git-commit: populate the edit buffer with 2 blank lines before s-o-b
+ Unify appending signoff in format-patch, commit and sequencer
+ format-patch: update append_signoff prototype
+ t4014: more tests about appending s-o-b lines
+ sequencer.c: teach append_signoff to avoid adding a duplicate newline
+ sequencer.c: teach append_signoff how to detect duplicate s-o-b
+ sequencer.c: always separate "(cherry picked from" from commit body
+ sequencer.c: require a conforming footer to be preceded by a blank line
+ sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
+ t/t3511: add some tests of 'cherry-pick -s' functionality
+ t/test-lib-functions.sh: allow to specify the tag name to test_commit
+ commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
+ sequencer.c: rework search for start of footer to improve clarity
Will cook in 'next'.
^ permalink raw reply
* [ANNOUNCE] Git v1.8.2-rc2
From: Junio C Hamano @ 2013-03-03 10:01 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git v1.8.2-rc2 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
b10a10d8e6351860fde123ffc62081e3800d602c git-1.8.2.rc2.tar.gz
de47a731c9fd426fca6385e2810d5345f85e32d9 git-htmldocs-1.8.2.rc2.tar.gz
a90c7cf8bded4fcede74c1a370df712e15b3ba45 git-manpages-1.8.2.rc2.tar.gz
Also the following public repositories all have a copy of the v1.8.2-rc2
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.2 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the next major release Git 2.0 (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this.
"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
that already exists in the repository $there, if the rewritten tag
you are pushing points at a commit that is a descendant of a commit
that the old tag v1.2.3 points at. This was found to be error prone
and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force".
When "git add -u" and "git add -A", that does not specify what paths
to add on the command line, is run from inside a subdirectory, the
scope of the operation has always been limited to the subdirectory.
Many users found this counter-intuitive, given that "git commit -a"
and other commands operate on the entire tree regardless of where you
are. In this release, these commands give warning in such a case and
encourage the user to say "git add -u/-A ." instead when restricting
the scope to the current directory.
At Git 2.0 (not *this* one), we plan to change these commands without
pathspec to operate on the entire tree. Forming a habit to type "."
when you mean to limit the command to the current working directory
will protect you against the planned future change, and that is the
whole point of the new message (there will be no configuration
variable to squelch this warning---it goes against the "habit forming"
objective).
Updates since v1.8.1
--------------------
UI, Workflows & Features
* Initial ports to QNX and z/OS UNIX System Services have started.
* Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* Mention of "GIT/Git/git" in the documentation have been updated to
be more uniform and consistent. The name of the system and the
concept it embodies is "Git"; the command the users type is "git".
All-caps "GIT" was merely a way to imitate "Git" typeset in small
caps in our ASCII text only documentation and to be avoided.
* The completion script (in contrib/completion) used to let the
default completer to suggest pathnames, which gave too many
irrelevant choices (e.g. "git add" would not want to add an
unmodified path). It learnt to use a more git-aware logic to
enumerate only relevant ones.
* In bare repositories, "git shortlog" and other commands now read
mailmap files from the tip of the history, to help running these
tools in server settings.
* Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the
"--format=" option of "git log" and friends can be disabled when
the output is not sent to a terminal by prefixing them with
"auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)".
* Scripts can ask Git that wildcard patterns in pathspecs they give do
not have any significance, i.e. take them as literal strings.
* The patterns in .gitignore and .gitattributes files can have **/,
as a pattern that matches 0 or more levels of subdirectory.
E.g. "foo/**/bar" matches "bar" in "foo" itself or in a
subdirectory of "foo".
* When giving arguments without "--" disambiguation, object names
that come earlier on the command line must not be interpretable as
pathspecs and pathspecs that come later on the command line must
not be interpretable as object names. This disambiguation rule has
been tweaked so that ":/" (no other string before or after) is
always interpreted as a pathspec; "git cmd -- :/" is no longer
needed, you can just say "git cmd :/".
* Various "hint" lines Git gives when it asks the user to edit
messages in the editor are commented out with '#' by default. The
core.commentchar configuration variable can be used to customize
this '#' to a different character.
* "git add -u" and "git add -A" without pathspec issues warning to
make users aware that they are only operating on paths inside the
subdirectory they are in. Use ":/" (everything from the top) or
"." (everything from the $cwd) to disambiguate.
* "git blame" (and "git diff") learned the "--no-follow" option.
* "git branch" now rejects some nonsense combinations of command line
arguments (e.g. giving more than one branch name to rename) with
more case-specific error messages.
* "git check-ignore" command to help debugging .gitignore files has
been added.
* "git cherry-pick" can be used to replay a root commit to an unborn
branch.
* "git commit" can be told to use --cleanup=whitespace by setting the
configuration variable commit.cleanup to 'whitespace'.
* "git diff" and other Porcelain commands can be told to use a
non-standard algorithm by setting diff.algorithm configuration
variable.
* "git fetch --mirror" and fetch that uses other forms of refspec
with wildcard used to attempt to update a symbolic ref that match
the wildcard on the receiving end, which made little sense (the
real ref that is pointed at by the symbolic ref would be updated
anyway). Symbolic refs no longer are affected by such a fetch.
* "git format-patch" now detects more cases in which a whole branch
is being exported, and uses the description for the branch, when
asked to write a cover letter for the series.
* "git format-patch" learned "-v $count" option, and prepends a
string "v$count-" to the names of its output files, and also
automatically sets the subject prefix to "PATCH v$count". This
allows patches from rerolled series to be stored under different
names and makes it easier to reuse cover letter messages.
* "git log" and friends can be told with --use-mailmap option to
rewrite the names and email addresses of people using the mailmap
mechanism.
* "git log --cc --graph" now shows the combined diff output with the
ancestry graph.
* "git log --grep=<pattern>" honors i18n.logoutputencoding to look
for the pattern after fixing the log message to the specified
encoding.
* "git mergetool" and "git difftool" learned to list the available
tool backends in a more consistent manner.
* "git mergetool" is aware of TortoiseGitMerge now and uses it over
TortoiseMerge when available.
* "git push" now requires "-f" to update a tag, even if it is a
fast-forward, as tags are meant to be fixed points.
* Error messages from "git push" when it stops to prevent remote refs
from getting overwritten by mistake have been improved to explain
various situations separately.
* "git push" will stop without doing anything if the new "pre-push"
hook exists and exits with a failure.
* When "git rebase" fails to generate patches to be applied (e.g. due
to oom), it failed to detect the failure and instead behaved as if
there were nothing to do. A workaround to use a temporary file has
been applied, but we probably would want to revisit this later, as
it hurts the common case of not failing at all.
* Input and preconditions to "git reset" has been loosened where
appropriate. "git reset $fromtree Makefile" requires $fromtree to
be any tree (it used to require it to be a commit), for example.
"git reset" (without options or parameters) used to error out when
you do not have any commits in your history, but it now gives you
an empty index (to match non-existent commit you are not even on).
* "git status" says what branch is being bisected or rebased when
able, not just "bisecting" or "rebasing".
* "git submodule" started learning a new mode to integrate with the
tip of the remote branch (as opposed to integrating with the commit
recorded in the superproject's gitlink).
* "git upload-pack" which implements the service "ls-remote" and
"fetch" talk to can be told to hide ref hierarchies the server
side internally uses (and that clients have no business learning
about) with transfer.hiderefs configuration.
Foreign Interface
* "git fast-export" has been updated for its use in the context of
the remote helper interface.
* A new remote helper to interact with bzr has been added to contrib/.
* "git p4" got various bugfixes around its branch handling. It is
also made usable with Python 2.4/2.5. In addition, its various
portability issues for Cygwin have been addressed.
* The remote helper to interact with Hg in contrib/ has seen a few
fixes.
Performance, Internal Implementation, etc.
* "git fsck" has been taught to be pickier about entries in tree
objects that should not be there, e.g. ".", ".git", and "..".
* Matching paths with common forms of pathspecs that contain wildcard
characters has been optimized further.
* We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* "git reset" internals has been reworked and should be faster in
general. We tried to be careful not to break any behaviour but
there could be corner cases, especially when running the command
from a conflicted state, that we may have missed.
* The implementation of "imap-send" has been updated to reuse xml
quoting code from http-push codepath, and lost a lot of unused
code.
* There is a simple-minded checker for the test scripts in t/
directory to catch most common mistakes (it is not enabled by
default).
* You can build with USE_WILDMATCH=YesPlease to use a replacement
implementation of pattern matching logic used for pathname-like
things, e.g. refnames and paths in the repository. This new
implementation is not expected change the existing behaviour of Git
in this release, except for "git for-each-ref" where you can now
say "refs/**/master" and match with both refs/heads/master and
refs/remotes/origin/master. We plan to use this new implementation
in wider places (e.g. "git ls-files '**/Makefile' may find Makefile
at the top-level, and "git log '**/t*.sh'" may find commits that
touch a shell script whose name begins with "t" at any level) in
future versions of Git, but we are not there yet. By building with
USE_WILDMATCH, using the resulting Git daily and reporting when you
find breakages, you can help us get closer to that goal.
* Some reimplementations of Git do not write all the stat info back
to the index due to their implementation limitations (e.g. jgit).
A configuration option can tell Git to ignore changes to most of
the stat fields and only pay attention to mtime and size, which
these implementations can reliably update. This can be used to
avoid excessive revalidation of contents.
* Some platforms ship with old version of expat where xmlparse.h
needs to be included instead of expat.h; the build procedure has
been taught about this.
* "make clean" on platforms that cannot compute header dependencies
on the fly did not work with implementations of "rm" that do not
like an empty argument list.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.1
------------------
Unless otherwise noted, all the fixes since v1.8.1 in the maintenance
track are contained in this release (see release notes to them for
details).
* An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* When attempting to read the XDG-style $HOME/.config/git/config and
finding that $HOME/.config/git is a file, we gave a wrong error
message, instead of treating the case as "a custom config file does
not exist there" and moving on.
* The behaviour visible to the end users was confusing, when they
attempt to kill a process spawned in the editor that was in turn
launched by Git with SIGINT (or SIGQUIT), as Git would catch that
signal and die. We ignore these signals now.
(merge 0398fc34 pf/editor-ignore-sigint later to maint).
* A child process that was killed by a signal (e.g. SIGINT) was
reported in an inconsistent way depending on how the process was
spawned by us, with or without a shell in between.
* After failing to create a temporary file using mkstemp(), failing
pathname was not reported correctly on some platforms.
* We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part.
* The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does. The initial implementation of this that
was merged to 'maint' and 1.8.1.2 was with a severe performance
degradations and needs to merge a fix-up topic.
* The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
* "git am" did not parse datestamp correctly from Hg generated patch,
when it is run in a locale outside C (or en).
* "git apply" misbehaved when fixing whitespace breakages by removing
excess trailing blank lines.
* "git apply --summary" has been taught to make sure the similarity
value shown in its output is sensible, even when the input had a
bogus value.
* A tar archive created by "git archive" recorded a directory in a
way that made NetBSD's implementation of "tar" sometimes unhappy.
* "git archive" did not record uncompressed size in the header when
streaming a zip archive, which confused some implementations of unzip.
* "git archive" did not parse configuration values in tar.* namespace
correctly.
(merge b3873c3 jk/config-parsing-cleanup later to maint).
* Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.
* "git clean" showed what it was going to do, but sometimes end up
finding that it was not allowed to do so, which resulted in a
confusing output (e.g. after saying that it will remove an
untracked directory, it found an embedded git repository there
which it is not allowed to remove). It now performs the actions
and then reports the outcome more faithfully.
* When "git clone --separate-git-dir=$over_there" is interrupted, it
failed to remove the real location of the $GIT_DIR it created.
This was most visible when interrupting a submodule update.
* "git cvsimport" mishandled timestamps at DST boundary.
* We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
* "git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
(merge cfb70e1 nd/fetch-depth-is-broken later to maint).
* "git log --all -p" that walked refs/notes/textconv/ ref can later
try to use the textconv data incorrectly after it gets freed.
* We forgot to close the file descriptor reading from "gpg" output,
killing "git log --show-signature" on a long history.
* The way "git svn" asked for password using SSH_ASKPASS and
GIT_ASKPASS was not in line with the rest of the system.
* The --graph code fell into infinite loop when asked to do what the
code did not expect.
* http transport was wrong to ask for the username when the
authentication is done by certificate identity.
* "git pack-refs" that ran in parallel to another process that
created new refs had a nasty race.
* Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
* After "git add -N" and then writing a tree object out of the
index, the cache-tree data structure got corrupted.
* "git clone" used to allow --bare and --separate-git-dir=$there
options at the same time, which was nonsensical.
* "git rebase --preserve-merges" lost empty merges in recent versions
of Git.
* "git merge --no-edit" computed who were involved in the work done
on the side branch, even though that information is to be discarded
without getting seen in the editor.
* "git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook.
* A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer when showing an error message.
* When users spell "cc:" in lowercase in the fake "header" in the
trailer part, "git send-email" failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
* Output from "git status --ignored" showed an unexpected interaction
with "--untracked".
* "gitweb", when sorting by age to show repositories with new
activities first, used to sort repositories with absolutely
nothing in it early, which was not very useful.
* "gitweb"'s code to sanitize control characters before passing it to
"highlight" filter lost known-to-be-safe control characters by
mistake.
* "gitweb" pages served over HTTPS, when configured to show picon or
gravatar, referred to these external resources to be fetched via
HTTP, resulting in mixed contents warning in browsers.
* When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed
to add a newline after such a line.
* Command line completion leaked an unnecessary error message while
looking for possible matches with paths in <tree-ish>.
* Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* Command line completion code was inadvertently made incompatible with
older versions of bash by using a newer array notation.
* "git push" was taught to refuse updating the branch that is
currently checked out long time ago, but the user manual was left
stale.
(merge 50995ed wk/man-deny-current-branch-is-default-these-days later to maint).
* Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.
* Some scripted programs written in Python did not get updated when
PYTHON_PATH changed.
(cherry-pick 96a4647fca54031974cd6ad1 later to maint).
* When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
* A fix was added to the build procedure to work around buggy
versions of ccache broke the auto-generation of dependencies, which
unfortunately is still relevant because some people use ancient
distros.
* The autoconf subsystem passed --mandir down to generated
config.mak.autogen but forgot to do the same for --htmldir.
(merge 55d9bf0 ct/autoconf-htmldir later to maint).
* A change made on v1.8.1.x maintenance track had a nasty regression
to break the build when autoconf is used.
(merge 7f1b697 jn/less-reconfigure later to maint).
* We have been carrying a translated and long-unmaintained copy of an
old version of the tutorial; removed.
* t0050 had tests expecting failures from a bug that was fixed some
time ago.
* t4014, t9502 and t0200 tests had various portability issues that
broke on OpenBSD.
* t9020 and t3600 tests had various portability issues.
* t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you
need to be in the cvsadmin group on NetBSD 6.0).
* t9020 and t9810 had a few non-portable shell script construct.
* Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
* An element on GIT_CEILING_DIRECTORIES could be a "logical" pathname
that uses a symbolic link to point at somewhere else (e.g. /home/me
that points at /net/host/export/home/me, and the latter directory
is automounted). Earlier when Git saw such a pathname e.g. /home/me
on this environment variable, the "ceiling" mechanism did not take
effect. With this release (the fix has also been merged to the
v1.8.1.x maintenance series), elements on GIT_CEILING_DIRECTORIES
are by default checked for such aliasing coming from symbolic
links. As this needs to actually resolve symbolic links for each
element on the GIT_CEILING_DIRECTORIES, you can disable this
mechanism for some elements by listing them after an empty element
on the GIT_CEILING_DIRECTORIES. e.g. Setting /home/me::/home/him to
GIT_CEILING_DIRECTORIES makes Git resolve symbolic links in
/home/me when checking if the current directory is under /home/me,
but does not do so for /home/him.
(merge 7ec30aa mh/maint-ceil-absolute later to maint).
----------------------------------------------------------------
Changes since v1.8.2-rc1 are as follows:
Andrew Wong (1):
Documentation/githooks: Fix linkgit
Brad King (1):
Documentation/submodule: Add --force to update synopsis
Erik Faye-Lund (1):
Revert "compat: add strtok_r()"
Junio C Hamano (3):
Update draft release notes to 1.8.1.5
Git 1.8.1.5
Git 1.8.2-rc2
Karsten Blees (2):
wincred: accept CRLF on stdin to simplify console usage
wincred: improve compatibility with windows versions
Michael Haggerty (1):
Provide a mechanism to turn off symlink resolution in ceiling paths
Thomas Rast (1):
Make !pattern in .gitattributes non-fatal
^ permalink raw reply
* Re: [PATCH] Revert "graph.c: mark private file-scope symbols as static"
From: John Keeping @ 2013-03-03 10:29 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Johan Herland
In-Reply-To: <87haktwr2a.fsf@pctrast.inf.ethz.ch>
On Sat, Mar 02, 2013 at 08:16:13PM +0100, Thomas Rast wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
> >
> > CGit uses these symbols to output the correct HTML around graph
> > elements. Making these symbols private means that CGit cannot be
> > updated to use Git 1.8.0 or newer, so let's not do that.
> >
> > Signed-off-by: John Keeping <john@keeping.me.uk>
> > ---
> >
> > I realise that Git isn't a library so making the API useful for outside
> > projects isn't a priority, but making these two methods public makes
> > life a lot easier for CGit.
> >
> > Additionally, it seems that Johan added graph_set_column_colors
> > specifically so that CGit should use it - there's no value to having
> > that as a method just for its use in graph.c and he was the author of
> > CGit commit 268b34a (ui-log: Colorize commit graph, 2010-11-15).
>
> Perhaps you could add a comment in the source to prevent this from
> happening again?
That feels wrong to me; would we really want a list of "$OUTSIDE_PROJECT
uses this" against all methods? CGit is using Git's internal API and so
should be prepared for breakage and to do what is necessary to work
around it - it's just this one case where adding a 2 line function to
Git makes CGit's life a lot easier.
I would hope that having this message in the history should be enough to
prevent this changing in the future; and it means that the comment is
associated with a date so that someone can decide to check whether CGit
is still using this function in the distant future.
John
^ permalink raw reply
* [PATCH v2 1/5] Show 'git help <guide>' usage, with examples
From: Philip Oakley @ 2013-03-03 20:21 UTC (permalink / raw)
To: GitList
In-Reply-To: <1362342072-1412-1-git-send-email-philipoakley@iee.org>
The git(1) man page must be accessed via 'git help git' on Git for Windows
as it has no 'man' command. And it prompts users to read the git(1) page,
rather than hoping they follow a subsidiary link within another
documentation page. The 'tutorial' is an obvious guide to suggest.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
git.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git.c b/git.c
index b10c18b..d9b71c1 100644
--- a/git.c
+++ b/git.c
@@ -13,7 +13,9 @@ const char git_usage_string[] =
" <command> [<args>]";
const char git_more_info_string[] =
- N_("See 'git help <command>' for more information on a specific command.");
+ N_("See 'git help <command>' for more information on a specific command.\n"
+ "While 'git help <guide>', will show the selected Git concept guide.\n"
+ "Examples: 'git help git', 'git help branch', 'git help tutorial'...");
static struct startup_info git_startup_info;
static int use_pager = -1;
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2 4/5] Help.c: add list_common_guides_help() function
From: Philip Oakley @ 2013-03-03 20:21 UTC (permalink / raw)
To: GitList
In-Reply-To: <1362342072-1412-1-git-send-email-philipoakley@iee.org>
Re-use list_common_cmds_help but simply change the array name.
Candidate for future refactoring to pass a pointer to the array.
The common-guides.h list was generated with a simple variant of the
generate-cmdlist.sh and command-list.txt.
Do not list User-manual and Everday Git which not follow the naming
convention, nor gitrepository-layout which doesn't fit within the
name field size.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 1 +
common-guides.h | 11 +++++++++++
help.c | 18 ++++++++++++++++++
help.h | 1 +
4 files changed, 31 insertions(+)
create mode 100644 common-guides.h
diff --git a/builtin/help.c b/builtin/help.c
index 6089d72..e21ffa5 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -434,6 +434,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (!show_guides) return 0;
}
if (show_guides) {
+ list_common_guides_help();
return 0;
}
if (!argv[0]) {
diff --git a/common-guides.h b/common-guides.h
new file mode 100644
index 0000000..0e94fdc
--- /dev/null
+++ b/common-guides.h
@@ -0,0 +1,11 @@
+/* re-use struct cmdname_help in common-commands.h */
+
+static struct cmdname_help common_guides[] = {
+ {"attributes", "defining attributes per path"},
+ {"glossary", "A GIT Glossary"},
+ {"ignore", "Specifies intentionally untracked files to ignore"},
+ {"modules", "defining submodule properties"},
+ {"revisions", "specifying revisions and ranges for git"},
+ {"tutorial", "A tutorial introduction to git (for version 1.5.1 or newer)"},
+ {"workflows", "An overview of recommended workflows with git"},
+};
diff --git a/help.c b/help.c
index 1dfa0b0..f4de407 100644
--- a/help.c
+++ b/help.c
@@ -4,6 +4,7 @@
#include "levenshtein.h"
#include "help.h"
#include "common-cmds.h"
+#include "common-guides.h"
#include "string-list.h"
#include "column.h"
#include "version.h"
@@ -240,6 +241,23 @@ void list_common_cmds_help(void)
}
}
+void list_common_guides_help(void)
+{
+ int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
+ if (longest < strlen(common_guides[i].name))
+ longest = strlen(common_guides[i].name);
+ }
+
+ puts(_("The common Git guides are:"));
+ for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
+ printf(" %s ", common_guides[i].name);
+ mput_char(' ', longest - strlen(common_guides[i].name));
+ puts(_(common_guides[i].help));
+ }
+}
+
int is_in_cmdlist(struct cmdnames *c, const char *s)
{
int i;
diff --git a/help.h b/help.h
index 0ae5a12..4ae1fd7 100644
--- a/help.h
+++ b/help.h
@@ -17,6 +17,7 @@ static inline void mput_char(char c, unsigned int num)
}
extern void list_common_cmds_help(void);
+extern void list_common_guides_help(void);
extern const char *help_unknown_cmd(const char *cmd);
extern void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2 0/5] Git help option to list user guides
From: Philip Oakley @ 2013-03-03 20:21 UTC (permalink / raw)
To: GitList
This is the much truncated (was 0/13] and updated series for
noting that 'git help' can display the existing guides that are
formatted as man pages, and providing a 'git help' option to list
a few of the most useful guides.
The series is rebased on top of V1.8.2-rc1
Differences relative to V1 numbering
Patch 1: Use 'Git' in help messages
Dropped.
a. the 'git version' string is used in the wild for version checking,
in particular Git Gui checks the string is 'git version'.
b. a recent patch series fixed on lower case messages for 'usage:',
respect that.
c. many consider that the 'git' reference was to the 'git <cmd>' format
rather than (the system) Git's commands.
Patch 2 (now 1/5): Show 'git help <guide>' usage, with examples
Correct elipsis dots for unterminated list of examples.
Patch 2 (now 2/5): Help.c use OPT_COUNTUP
Unchanged.
Patch 4 (now 3/5): Help.c add --guide option
Update commit message to explain the -g|--guide logic.
Patch 5 (now 4/5): Help.c: add list_common_guides_help() function
Removed the 'build artefact' /* */ comment line.
Note that these are just the common guides and used in a usage message.
The data was generated by a script variant of generate-cmdlist.sh
Patch (new 5/5): Help doc: Include --guide option description
Update the documentation/git-help.txt - I had been caught out by
the same 'focus on the code' mistake made by many and forgot
the documenation ;-)
Patch 6 - 13:
All dropped.
Drop the separate guide list.txt and extraction script, which was
copied from the common command list and script. If the guide usage
list is useful, extend the command-list.txt and generate-cmdlist.sh
at a later date.
Drop the rename of user-manual and everyday because they are not
formatted as manuals. They can't be started by help's call to 'man'
(and possibly other paths) anyway.
Philip Oakley (5):
Show 'git help <guide>' usage, with examples
Help.c use OPT_COUNTUP
Help.c add --guide option
Help.c: add list_common_guides_help() function
Help doc: Include --guide option description
Documentation/git-help.txt | 28 +++++++++++++++++++++-------
builtin/help.c | 11 ++++++++---
common-guides.h | 11 +++++++++++
git.c | 4 +++-
help.c | 18 ++++++++++++++++++
help.h | 1 +
6 files changed, 62 insertions(+), 11 deletions(-)
create mode 100644 common-guides.h
--
1.8.1.msysgit.1
^ permalink raw reply
* [PATCH v2 2/5] Help.c use OPT_COUNTUP
From: Philip Oakley @ 2013-03-03 20:21 UTC (permalink / raw)
To: GitList
In-Reply-To: <1362342072-1412-1-git-send-email-philipoakley@iee.org>
rename deprecated option in preparation for 'git help --guides'.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin/help.c
index d1d7181..d10cbed 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -39,7 +39,7 @@ static int show_all = 0;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_COUNTUP('a', "all", &show_all, N_("print all available commands")),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2 3/5] Help.c add --guide option
From: Philip Oakley @ 2013-03-03 20:21 UTC (permalink / raw)
To: GitList
In-Reply-To: <1362342072-1412-1-git-send-email-philipoakley@iee.org>
Logic, but no actions, included.
The --all commands option, if given, will display first.
The --guide option's list will then be displayed.
The common commands list is only displayed if neither option,
nor a command or guide name, is given.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index d10cbed..6089d72 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -36,10 +36,12 @@ enum help_format {
static const char *html_path;
static int show_all = 0;
+static int show_guides = 0;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
OPT_COUNTUP('a', "all", &show_all, N_("print all available commands")),
+ OPT_COUNTUP('g', "guides", &show_guides, N_("print list of useful guides")),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -49,7 +51,7 @@ static struct option builtin_help_options[] = {
};
static const char * const builtin_help_usage[] = {
- N_("git help [--all] [--man|--web|--info] [command]"),
+ N_("git help [--all] [--guides] [--man|--web|--info] [command]"),
NULL
};
@@ -429,9 +431,11 @@ int cmd_help(int argc, const char **argv, const char *prefix)
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
+ if (!show_guides) return 0;
+ }
+ if (show_guides) {
return 0;
}
-
if (!argv[0]) {
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_common_cmds_help();
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2 5/5] Help doc: Include --guide option description
From: Philip Oakley @ 2013-03-03 20:21 UTC (permalink / raw)
To: GitList
In-Reply-To: <1362342072-1412-1-git-send-email-philipoakley@iee.org>
Note that the ability to display an individual guide was
always possible. Include this in the update.
Also tell readers how git(1) can be accessed, especially for
Git for Windows users who do not have the 'man' command.
Likewise include a commentary on how to access this page (Catch 22).
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/git-help.txt | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index e07b6dc..498a94e 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -8,31 +8,45 @@ git-help - Display help information about Git
SYNOPSIS
--------
[verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+'git help' [-a|--all] [-g|--guide]
+ [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
-----------
-With no options and no COMMAND given, the synopsis of the 'git'
+With no options and no COMMAND|GUIDE given, the synopsis of the 'git'
command and a list of the most commonly used Git commands are printed
on the standard output.
If the option '--all' or '-a' is given, then all available commands are
printed on the standard output.
-If a Git subcommand is named, a manual page for that subcommand is brought
-up. The 'man' program is used by default for this purpose, but this
-can be overridden by other options or configuration variables.
+If the option '--guide' or '-g' is given then, a list of the useful
+Git guides is also printed on the standard output.
-Note that `git --help ...` is identical to `git help ...` because the
+If a Git subcommand, or a Git guide, is given, a manual page for that
+subcommand is brought up. The 'man' program is used by default for this
+purpose, but this can be overridden by other options or configuration
+variables.
+
+Note that 'git --help ...' is identical to 'git help ...' because the
former is internally converted into the latter.
+To display the linkgit:git[1] man page use 'git help git'.
+
+This page can be displayed with 'git help help' or 'git help --help'
+
OPTIONS
-------
-a::
--all::
Prints all the available commands on the standard output. This
- option supersedes any other option.
+ option overides any given command or guide name.
+
+-g::
+--guides::
+ Prints a list of useful guides on the standard output. This
+ option overides any given command or guide name.
-i::
--info::
--
1.8.1.msysgit.1
^ permalink raw reply related
* Re: [PATCH 2/2] describe: Exclude --all --match=PATTERN
From: Greg Price @ 2013-03-03 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uc1jyq0.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
On Wed, Feb 27, 2013 at 12:20:07PM -0800, Junio C Hamano wrote:
> Without "--all" the command considers only the annotated tags to
> base the descripion on, and with "--all", a ref that is not
> annotated tags can be used as a base, but with a lower priority (if
> an annotated tag can describe a given commit, that tag is used).
>
> So naïvely I would expect "--all" and "--match" to base the
> description on refs that match the pattern without limiting the
> choice of base to annotated tags, and refs that do not match the
> given pattern should not appear even as the last resort. It appears
> to me that the current situation is (3).
Hmm. It seems to me that "--all" says two things:
(a) allow unannotated (rather than only annotated)
(b) allow refs of any name (rather than only tags)
With "--match", particularly because the pattern always refers only to
tags, (b) is obliterated, and your proposed semantics are (a) plus a
sort of inverse of (b):
(c) allow only refs matching the pattern
which is what "--match" means alone. But if what we are going for is
(a) and (c), then we don't need "--all" for (a) -- we can get
precisely that with "--tags". So these semantics make "--all --match=PAT"
equivalent to "--tags --match=PAT".
Given that, I think the user is better off if we reject "--all
--match" with an error message -- and perhaps the error message should
advise them to use "--tags" instead. Otherwise we have "--all"
telling us (b) as well as (a), and "--match" countermanding (b) and
going precisely the other direction to (c). If the user has written
that by hand, then they may be confused, and if the command line was
generated, perhaps called from a script, then I fear a bug in the
script is likely, what with the conflicting expectations expressed by
"--all" and "--match".
Patch below to suggest "--tags" in the error message.
Greg
[-- Attachment #2: 0001-describe-Better-error-message-on-all-match.patch --]
[-- Type: text/x-diff, Size: 1090 bytes --]
>From 66f985b2510c870e62e313732de4b6709894b074 Mon Sep 17 00:00:00 2001
From: Greg Price <price@mit.edu>
Date: Sun, 3 Mar 2013 12:19:57 -0800
Subject: [PATCH] describe: Better error message on --all --match
The reason they conflict is that --all means
(a) allow unannotated, and
(b) allow refs of any name (rather than only tags),
while --match contradicts (b) and goes further to
(c) allow only tags matching pattern.
If what the user wants is (a) and (c), they can use --tags to get (a)
without (b).
---
builtin/describe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 2ef3f10..6581c40 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -436,7 +436,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
die(_("--long is incompatible with --abbrev=0"));
if (pattern && all)
- die(_("--match is incompatible with --all"));
+ die(_("--all conflicts with --match; do you mean --tags?"));
if (contains) {
const char **args = xmalloc((7 + argc) * sizeof(char *));
--
1.7.11.3
^ permalink raw reply related
* Re: [PATCH] Revert "graph.c: mark private file-scope symbols as static"
From: Junio C Hamano @ 2013-03-03 21:08 UTC (permalink / raw)
To: John Keeping; +Cc: Thomas Rast, git, Johan Herland
In-Reply-To: <20130303102946.GH7738@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Sat, Mar 02, 2013 at 08:16:13PM +0100, Thomas Rast wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>> > This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
>> >
>> > CGit uses these symbols to output the correct HTML around graph
>> > elements. Making these symbols private means that CGit cannot be
>> > updated to use Git 1.8.0 or newer, so let's not do that.
>> >
>> > Signed-off-by: John Keeping <john@keeping.me.uk>
>> > ---
>> >
>> > I realise that Git isn't a library so making the API useful for outside
>> > projects isn't a priority, but making these two methods public makes
>> > life a lot easier for CGit.
>> >
>> > Additionally, it seems that Johan added graph_set_column_colors
>> > specifically so that CGit should use it - there's no value to having
>> > that as a method just for its use in graph.c and he was the author of
>> > CGit commit 268b34a (ui-log: Colorize commit graph, 2010-11-15).
>>
>> Perhaps you could add a comment in the source to prevent this from
>> happening again?
> ...
> I would hope that having this message in the history should be enough to
> prevent this changing in the future....
Given how it happened in the first place, I do not think anything
short of in-code comment would have helped. There wouldn't be any
hint to look into the history without one.
^ permalink raw reply
* Re: [PATCH 2/2] describe: Exclude --all --match=PATTERN
From: Junio C Hamano @ 2013-03-03 21:15 UTC (permalink / raw)
To: Greg Price; +Cc: git
In-Reply-To: <20130303205232.GL22203@biohazard-cafe.mit.edu>
Greg Price <price@MIT.EDU> writes:
> On Wed, Feb 27, 2013 at 12:20:07PM -0800, Junio C Hamano wrote:
>> Without "--all" the command considers only the annotated tags to
>> base the descripion on, and with "--all", a ref that is not
>> annotated tags can be used as a base, but with a lower priority (if
>> an annotated tag can describe a given commit, that tag is used).
>>
>> So naïvely I would expect "--all" and "--match" to base the
>> description on refs that match the pattern without limiting the
>> choice of base to annotated tags, and refs that do not match the
>> given pattern should not appear even as the last resort. It appears
>> to me that the current situation is (3).
>
> Hmm. It seems to me that "--all" says two things:
>
> (a) allow unannotated (rather than only annotated)
>
> (b) allow refs of any name (rather than only tags)
>
> With "--match", particularly because the pattern always refers only to
> tags, (b) is obliterated, and your proposed semantics are (a) plus a
> sort of inverse of (b):
>
> (c) allow only refs matching the pattern
I would think it is more like "only (a), without changing the
documented semantics of what '--all' and '--match' are by adding (b)
or (c)".
I do not think in the longer term it is wrong per-se to change the
semantics of "--match" from the documented "Only consider tags
matching the pattern" to "Only consider refs matching the pattern",
and such a change can and should be made as a separate patch
"describe: loosen --match to allow any ref, not just tags" on top of
the patch I sent which was meant to be bugfix-only.
^ permalink raw reply
* Re: [PATCH] Revert "graph.c: mark private file-scope symbols as static"
From: John Keeping @ 2013-03-03 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johan Herland
In-Reply-To: <7vk3pob38d.fsf@alter.siamese.dyndns.org>
On Sun, Mar 03, 2013 at 01:08:50PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > On Sat, Mar 02, 2013 at 08:16:13PM +0100, Thomas Rast wrote:
> >> John Keeping <john@keeping.me.uk> writes:
> >>
> >> > This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
> >> >
> >> > CGit uses these symbols to output the correct HTML around graph
> >> > elements. Making these symbols private means that CGit cannot be
> >> > updated to use Git 1.8.0 or newer, so let's not do that.
> >> >
> >> > Signed-off-by: John Keeping <john@keeping.me.uk>
> >> > ---
> >> >
> >> > I realise that Git isn't a library so making the API useful for outside
> >> > projects isn't a priority, but making these two methods public makes
> >> > life a lot easier for CGit.
> >> >
> >> > Additionally, it seems that Johan added graph_set_column_colors
> >> > specifically so that CGit should use it - there's no value to having
> >> > that as a method just for its use in graph.c and he was the author of
> >> > CGit commit 268b34a (ui-log: Colorize commit graph, 2010-11-15).
> >>
> >> Perhaps you could add a comment in the source to prevent this from
> >> happening again?
> > ...
> > I would hope that having this message in the history should be enough to
> > prevent this changing in the future....
>
> Given how it happened in the first place, I do not think anything
> short of in-code comment would have helped. There wouldn't be any
> hint to look into the history without one.
So you'd accept a patch doing that? Something like this perhaps:
NOTE: Although these functions aren't used in Git outside graph.c,
they are used by CGit.
^ permalink raw reply
* Re: [PATCH 2/2] describe: Exclude --all --match=PATTERN
From: Greg Price @ 2013-03-03 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfw0cb2xi.fsf@alter.siamese.dyndns.org>
On Sun, Mar 03, 2013 at 01:15:21PM -0800, Junio C Hamano wrote:
> Greg Price <price@MIT.EDU> writes:
> > It seems to me that "--all" says two things:
> >
> > (a) allow unannotated (rather than only annotated)
> >
> > (b) allow refs of any name (rather than only tags)
> >
> > With "--match", particularly because the pattern always refers only to
> > tags, (b) is obliterated, and your proposed semantics are (a) plus a
> > sort of inverse of (b):
> >
> > (c) allow only refs matching the pattern
>
> I would think it is more like "only (a), without changing the
> documented semantics of what '--all' and '--match' are by adding (b)
> or (c)".
Perhaps I'm confused somehow? I believe (a) and (b) together are the
documented semantics of what '--all' is. And I believe (c), which
contradicts (b) and indeed goes in the opposite direction, is the
documented semantics of what '--match' is.
Certainly we could choose to resolve the conflict by saying that
'--match' overrides '--all', so that '--all' plus '--match' means
(a)+(c). I believe that's what you suggested.
I think it would be preferable to recognize the conflict and let the
user sort out what they actually mean, because if they (or their
script) gave these options together then I think there's a substantial
likelihood that they are confused or their script is buggy. If they
mean (a)+(c), they can get it more clearly with '--tag --match'.
> I do not think in the longer term it is wrong per-se to change the
> semantics of "--match" from the documented "Only consider tags
> matching the pattern" to "Only consider refs matching the pattern",
> and such a change can and should be made as a separate patch
> "describe: loosen --match to allow any ref, not just tags" on top of
> the patch I sent which was meant to be bugfix-only.
Yeah, that could be useful. What form of pattern would you suggest
that the new '--match' accept? The obvious, and unambiguous, form of
pattern is glob patterns on the full ref name, as with 'for-each-ref'.
Those are a little unwieldy for interactive use, but are perfect for a
script. And probably 'describe --match' itself already makes the most
sense in a scripted context, as for interactive use one can go into
'gitk' or 'git log --oneline --decorate' or the like and find out the
same information plus more detail.
Particularly when handling both tags and other refs, I can also
imagine wanting to specify a disjunction of several patterns. So we
might want to accept the option several times cumulatively.
I'd worry about changing the semantics of existing 'describe --match'
invocations in people's scripts, etc. Perhaps we'd give it a new name
like '--match-ref'. Or we could say something like, if it starts with
"refs/" it's a pattern on the whole refname, else it's a pattern on
just the tag name, and accept that if someone has a ref called
"refs/tags/refs/foo" and was finding it with 'describe --match' then
that will break until they edit the pattern.
Cheers,
Greg
^ permalink raw reply
* Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached
From: Junio C Hamano @ 2013-03-03 22:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <1362303681-6585-5-git-send-email-pclouds@gmail.com>
> When a remote ref or a tag is checked out, HEAD is automatically
> detached. There is no user friendly way to find out what ref is
> checked out in this case. This patch digs in reflog for this
> information and shows "Detached from origin/master" or "Detached from
> v1.8.0" instead of "Currently not on any branch".
"Detached from" is a nice attempt to compromise in the phrasing.
We usually say you detach HEAD at v1.8.0, but what is shown is what
started from such a state but then the user may have built more
history on top of it and may no longer be at v1.8.0, so obviously we
do not want to say "Detached at". We are in a "detached at v1.8.0
and then possibly built one or more commits on top" state (would it
be helpful to differentiate the "nothing built on top" and "some
commits have been built on top" cases, I wonder).
Also I wonder if you could do a bit more to help the users who do:
$ git checkout $(git merge-base HEAD nd/branch-show-rebase-bisect-state)
aka
$ git checkout ...nd/branch-show-rebase-bisect-state
and then do one or more commits on top.
Instead of punting to "Currently not on any branch", would it help
to show the place you first detached at, so that the user can then
grab that commit object name and run
$ git log --oneline $that_commit..
or something?
> +static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,
> + const char *email, unsigned long timestamp, int tz,
> + const char *message, void *cb_data)
> +{
> + struct grab_1st_switch_cbdata *cb = cb_data;
> + const char *target = NULL;
> +
> + if (prefixcmp(message, "checkout: moving from "))
> + return 0;
> + message += strlen("checkout: moving from ");
> + target = strstr(message, " to ");
> + if (!target)
> + return 0;
> + target += strlen(" to ");
> + strbuf_reset(&cb->buf);
> + hashcpy(cb->sha1, nsha1);
> + if (!prefixcmp(target, "refs/")) {
> + const char *end = target;
> + while (*end && *end != '\n')
> + end++;
> + strbuf_add(&cb->buf, target, end - target);
> + }
> + return 0;
> +}
Can't this be done by generalizing grab_nth_branch_switch() and then
exposing it as part of the general API?
I also feel uneasy about two issues this and the previous change
introduces:
1) It is somewhat unnerving that this step reads what comes after
"to", while nth_branch_switch() reads what comes between "from"
and "to", but it probably cannot be avoided because this series
wants to know what we switched "to" earlier, while "checkout -"
wants to know what we switched "from"
2) The previous one records this sequence in a funny way:
: start from branch A
git checkout B
git checkout C
The resulting reflog entries result in
checkout: moving from A to refs/heads/B
checkout: moving from B to refs/heads/C
even though existing code and tools are expecting to read
checkout: moving from A to B
checkout: moving from B to C
By the way, even though the title of this patch is "status: show the
ref that is checked out, even if it's detached", a quick check with
$ cd ../linux-3.0
$ git describe
v3.8-rc7
$ ../git.git/git-checkout v3.8-rc7
$ tail -n 1 .git/logs/HEAD | sed -e 's/.*checkout/checkout/'
checkout: moving from master to refs/tags/v3.8-rc7
$ ../git.git/git-status | head -n 1
# Not currently on any branch.
$ ../git.git/git-branch -v
* (no branch) 836dc9e Linux 3.8-rc7
master 836dc9e Linux 3.8-rc7
does not seem to give me anything more helpful.
^ permalink raw reply
* Re: [PATCH 5/5] branch: show more information when HEAD is detached
From: Junio C Hamano @ 2013-03-03 22:28 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <1362303681-6585-6-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This prints more helpful info when HEAD is detached: is it detached
> because of bisect or rebase? What is the original branch name in those
> cases? Is it detached because the user checks out a remote ref or a
> tag (and which one)?
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> builtin/branch.c | 25 ++++++++++++++++++++++++-
> t/t6030-bisect-porcelain.sh | 2 +-
> 2 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 6371bf9..02dee0d 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -18,6 +18,7 @@
> #include "string-list.h"
> #include "column.h"
> #include "utf8.h"
> +#include "wt-status.h"
>
> static const char * const builtin_branch_usage[] = {
> N_("git branch [options] [-r | -a] [--merged | --no-merged]"),
> @@ -550,6 +551,28 @@ static int calc_maxwidth(struct ref_list *refs)
> return w;
> }
>
> +static char *get_head_description()
s/()/(void)/;
I think the series is much easier to read than the previous round
(except for some nits, which I'll send separately). We would want
to add tests to protect the "where did we detach from" feature done
by [PATCH 4/5], which does not seem to have any.
^ permalink raw reply
* Re: [PATCH] Revert "graph.c: mark private file-scope symbols as static"
From: Junio C Hamano @ 2013-03-03 22:49 UTC (permalink / raw)
To: John Keeping; +Cc: Thomas Rast, git, Johan Herland, Lars Hjemli
In-Reply-To: <20130303214206.GL7738@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Sun, Mar 03, 2013 at 01:08:50PM -0800, Junio C Hamano wrote:
>> >> > Additionally, it seems that Johan added graph_set_column_colors
>> >> > specifically so that CGit should use it - there's no value to having
>> >> > that as a method just for its use in graph.c and he was the author of
>> >> > CGit commit 268b34a (ui-log: Colorize commit graph, 2010-11-15).
>> >>
>> >> Perhaps you could add a comment in the source to prevent this from
>> >> happening again?
>> > ...
>> > I would hope that having this message in the history should be enough to
>> > prevent this changing in the future....
>>
>> Given how it happened in the first place, I do not think anything
>> short of in-code comment would have helped. There wouldn't be any
>> hint to look into the history without one.
>
> So you'd accept a patch doing that?
The answer obviously depends on the specifics of "that" ;-) I was
merely agreeing with what Thomas said. A straight-revert would be
insufficient to prevent this from recurring again.
> Something like this perhaps:
>
> NOTE: Although these functions aren't used in Git outside graph.c,
> they are used by CGit.
It would be a good place to start, although I prefer to see it
completed with s/used by CGit/& in order to do such and such/ by
somebody working on CGit.
Also it probably is worth adding contact information for folks who
work on CGit (http://hjemli.net/git/cgit/ might be sufficient), as
changing these functions (e.g. changing the function signature) will
affect them; making them "static" is not the only way to hurt them.
Thanks.
^ permalink raw reply
* Re: [PATCH] Revert "graph.c: mark private file-scope symbols as static"
From: John Keeping @ 2013-03-03 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johan Herland, Lars Hjemli
In-Reply-To: <7vppzg9k0n.fsf@alter.siamese.dyndns.org>
On Sun, Mar 03, 2013 at 02:49:12PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > On Sun, Mar 03, 2013 at 01:08:50PM -0800, Junio C Hamano wrote:
> >> >> > Additionally, it seems that Johan added graph_set_column_colors
> >> >> > specifically so that CGit should use it - there's no value to having
> >> >> > that as a method just for its use in graph.c and he was the author of
> >> >> > CGit commit 268b34a (ui-log: Colorize commit graph, 2010-11-15).
> >> >>
> >> >> Perhaps you could add a comment in the source to prevent this from
> >> >> happening again?
> >> > ...
> >> > I would hope that having this message in the history should be enough to
> >> > prevent this changing in the future....
> >>
> >> Given how it happened in the first place, I do not think anything
> >> short of in-code comment would have helped. There wouldn't be any
> >> hint to look into the history without one.
> >
> > So you'd accept a patch doing that?
>
> The answer obviously depends on the specifics of "that" ;-) I was
> merely agreeing with what Thomas said. A straight-revert would be
> insufficient to prevent this from recurring again.
>
> > Something like this perhaps:
> >
> > NOTE: Although these functions aren't used in Git outside graph.c,
> > they are used by CGit.
>
> It would be a good place to start, although I prefer to see it
> completed with s/used by CGit/& in order to do such and such/ by
> somebody working on CGit.
CGit uses graph_set_column_colors() to set the column colors to:
"<span class='column1'>",
...
"<span class='column6'>",
"</span>"
(the last value is RESET), thus avoiding the need to filter the output
to convert ANSI colours to HTML.
Similarly, it accesses graph_next_line() directly so that it can output
the necessary HTML around each line.
> Also it probably is worth adding contact information for folks who
> work on CGit (http://hjemli.net/git/cgit/ might be sufficient),
The current CGit homepage is http://git.zx2c4.com/cgit/
> as
> changing these functions (e.g. changing the function signature) will
> affect them; making them "static" is not the only way to hurt them.
But since CGit uses a specific version of Git (as a submodule), in
general it doesn't need to worry about keeping consistency across
different versions. CGit has been using Git 1.7.6 for quite a while -
I posted a series of patches to take it to 1.7.12 yesterday [1] but hit
this issue when I got to 1.8.x.
I think CGit expects to have to respond to changes in Git, so I don't
think it's worth restricting changes in Git for that reason - it's just
a case of exposing useful functionality somehow.
[1] http://hjemli.net/pipermail/cgit/2013-March/000933.html
^ permalink raw reply
* Re: [PATCH] Revert "graph.c: mark private file-scope symbols as static"
From: Junio C Hamano @ 2013-03-03 23:32 UTC (permalink / raw)
To: John Keeping; +Cc: Thomas Rast, git, Johan Herland, Lars Hjemli
In-Reply-To: <20130303232413.GN7738@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
>> Also it probably is worth adding contact information for folks who
>> work on CGit (http://hjemli.net/git/cgit/ might be sufficient),
>
> The current CGit homepage is http://git.zx2c4.com/cgit/
As the hjemli.net address is what I got as the first hit by asking
[CGit] to websearch, it makes it clearer that we do need such
contact information there.
> I think CGit expects to have to respond to changes in Git, so I don't
> think it's worth restricting changes in Git for that reason - it's just
> a case of exposing useful functionality somehow.
I think you misread me.
It is not about restricting. It is to use their expertise to come up
with generally more useful API than responding only to the immediate
need we see in in-tree users. We want a discussion/patch to update
the graph.c infrastructure to be Cc'ed to them.
For example, with the current codeflow, the callers of these
functions we have in-tree may be limited to those in graph.c but if
there are legitimate reason CGit wants to call them from sideways,
perhaps there may be use cases in our codebase in the future to call
them from outside the normal graph.c codeflow.
^ permalink raw reply
* Re: [PATCH v2 1/5] Show 'git help <guide>' usage, with examples
From: Junio C Hamano @ 2013-03-03 23:38 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1362342072-1412-2-git-send-email-philipoakley@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
> The git(1) man page must be accessed via 'git help git' on Git for Windows
> as it has no 'man' command. And it prompts users to read the git(1) page,
> rather than hoping they follow a subsidiary link within another
> documentation page. The 'tutorial' is an obvious guide to suggest.
>
> Signed-off-by: Philip Oakley <philipoakley@iee.org>
> ---
> git.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/git.c b/git.c
> index b10c18b..d9b71c1 100644
> --- a/git.c
> +++ b/git.c
> @@ -13,7 +13,9 @@ const char git_usage_string[] =
> " <command> [<args>]";
>
> const char git_more_info_string[] =
> - N_("See 'git help <command>' for more information on a specific command.");
> + N_("See 'git help <command>' for more information on a specific command.\n"
> + "While 'git help <guide>', will show the selected Git concept guide.\n"
> + "Examples: 'git help git', 'git help branch', 'git help tutorial'...");
While I think it is a good idea to mention that the argument to
"help" does not have to be the name of a subcommand, I have two
issues with this patch.
* A free-standing "While" looks strange. I would expect a sentence
that begins with "While 'git help <guide>' shows X" to end with
something negative like "it is not recommended". Perhaps it is
just me.
* It took me two readings to realize that "selected" in "selected
Git concept guide" refers to "what the user chose to see by
naming the <guide>". It looked as if the command will give users
only a selected few among 47 available ones, chosen by the
implementors.
How about doing it this way if you are adding two lines anyway?
'git help -a' and 'git help -g' lists available subcommands
and concept guides. See 'git help <command>' or 'git help
<concept>' to read about a specific subcommand or concept.
Replacing "Examples:" that has to stay incomplete for brevity with
the way to get the list of subcommands and concepts would a better
approach, I think. Teach them how to fish, instead of giving them
fish.
^ 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