* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-22 21:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: Michael Haggerty, Junio C Hamano, git discussion list
In-Reply-To: <20110922205856.GA8563@sigill.intra.peff.net>
On Thu, Sep 22, 2011 at 04:58:56PM -0400, Jeff King wrote:
> That makes some sense to me. As Junio pointed out, there is a catch with
> "diff -R". In that case, I would still think you would use the "second"
> commit, even though we're reversing the diff. So:
>
> git diff A B
>
> would not be exactly equivalent to:
>
> git diff -R B A
>
> in that the second would use attributes from "A" instead of "B".
I misread Junio's comment a bit. Re-reading it, this is exactly the
inconsistency he complained about. However, I consider it somewhat of a
feature. We currently have two ways to express the same thing, and you
arrive at one or the other based on the way you are thinking of the
problem. But we can use that to disambiguate between the two cases; one
is about going from A to B, and one is about inverting the operation of
going from B to A. Right now they're equivalent, but they don't have to
be.
If you read the rest of my message, you will see that I think picking
"first" or "second" arbitrarily like this might be barking up the wrong
tree. But I just wanted to clarify that point.
-Peff
^ permalink raw reply
* [PATCH 1/2] Teach '--cached' option to check-attr
From: Jay Soffian @ 2011-09-22 21:44 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano, Jeff King, Michael Haggerty
This option causes check-attr to consider .gitattributes from the index
only, ignoring .gitattributes from the working tree. This allows it to
be used in situations where a working tree does not exist.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
This doesn't seem too controversial to me, and allows server-side
reading of .gitattributes, albeit with the need to setup an index.
Still that's better than having to setup an entire working tree.
Documentation/git-check-attr.txt | 3 +++
builtin/check-attr.c | 5 +++++
t/t0003-attributes.sh | 28 ++++++++++++++++++++++++----
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 1f7312a189..22537fea23 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -24,6 +24,9 @@ OPTIONS
paths. If this option is used, then 'unspecified' attributes
will not be included in the output.
+--cached::
+ Consider .gitattributes in the index only, ignoring the working tree.
+
--stdin::
Read file names from stdin instead of from the command-line.
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 708988a0e1..5682f6d2c7 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -5,6 +5,7 @@
#include "parse-options.h"
static int all_attrs;
+static int cached_attrs;
static int stdin_paths;
static const char * const check_attr_usage[] = {
"git check-attr [-a | --all | attr...] [--] pathname...",
@@ -16,6 +17,7 @@ static int null_term_line;
static const struct option check_attr_options[] = {
OPT_BOOLEAN('a', "all", &all_attrs, "report all attributes set on file"),
+ OPT_BOOLEAN(0, "cached", &cached_attrs, "use cached .gitattributes"),
OPT_BOOLEAN(0 , "stdin", &stdin_paths, "read file names from stdin"),
OPT_BOOLEAN('z', NULL, &null_term_line,
"input paths are terminated by a null character"),
@@ -99,6 +101,9 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
die("invalid cache");
}
+ if (cached_attrs)
+ git_attr_set_direction(GIT_ATTR_INDEX, NULL);
+
doubledash = -1;
for (i = 0; doubledash < 0 && i < argc; i++) {
if (!strcmp(argv[i], "--"))
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index ae2f1da28f..2e1b4a7f75 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -134,10 +134,20 @@ test_expect_success 'attribute test: read paths from stdin' '
test_expect_success 'attribute test: --all option' '
- grep -v unspecified < expect-all | sort > expect &&
- sed -e "s/:.*//" < expect-all | uniq |
- git check-attr --stdin --all | sort > actual &&
- test_cmp expect actual
+ grep -v unspecified < expect-all | sort > specified-all &&
+ sed -e "s/:.*//" < expect-all | uniq > stdin-all &&
+ git check-attr --stdin --all < stdin-all | sort > actual &&
+ test_cmp specified-all actual
+'
+
+test_expect_success 'attribute test: --cached option' '
+
+ :> empty &&
+ git check-attr --cached --stdin --all < stdin-all | sort > actual &&
+ test_cmp empty actual &&
+ git add .gitattributes a/.gitattributes a/b/.gitattributes &&
+ git check-attr --cached --stdin --all < stdin-all | sort > actual &&
+ test_cmp specified-all actual
'
test_expect_success 'root subdir attribute test' '
@@ -168,6 +178,16 @@ test_expect_success 'bare repository: check that .gitattribute is ignored' '
'
+test_expect_success 'bare repository: check that --cached honors index' '
+
+ export GIT_INDEX_FILE=../.git/index &&
+ git check-attr --cached --stdin --all < ../stdin-all |
+ sort > actual &&
+ test_cmp ../specified-all actual
+
+'
+
+
test_expect_success 'bare repository: test info/attributes' '
(
--
1.7.7.rc2.5.g12a2f
^ permalink raw reply related
* [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Jay Soffian @ 2011-09-22 21:44 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano, Jeff King, Michael Haggerty
In-Reply-To: <1316727861-90460-1-git-send-email-jaysoffian@gmail.com>
When diff'ing the index against a tree (using either diff-index
or diff --cached), git previously looked at .gitattributes in the
working tree before considering .gitattributes in the index, even
though the diff itself otherwise ignores the working tree.
Further, with an index, but no working tree, the in-index
.gitattributes were ignored entirely.
Calling git_attr_set_direction(GIT_ATTR_INDEX) before generating
the diff fixes both of these behaviors.
---
This is a weather balloon patch I guess.
Obviously there is a behavior change here as evidenced by the change to
t4020-diff-external.sh. I think the old behavior was wrong and this is a
bug fix. But the old behavior has been that way a long time, so maybe
we should use '--cached-attributes' instead for the "correct" behavior.
Since I'm not really sure what we should do with --cached -R, I'm
punting on that for now.
Jeff's message regarding diff-tree made my head hurt, so tackling that
will have to wait...
diff-lib.c | 3 +++
t/t4020-diff-external.sh | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index f8454dd291..fe218931e6 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -11,6 +11,7 @@
#include "unpack-trees.h"
#include "refs.h"
#include "submodule.h"
+#include "attr.h"
/*
* diff-files
@@ -476,6 +477,8 @@ static int diff_cache(struct rev_info *revs,
int run_diff_index(struct rev_info *revs, int cached)
{
struct object_array_entry *ent;
+ if (cached)
+ git_attr_set_direction(GIT_ATTR_INDEX, NULL);
ent = revs->pending.objects;
if (diff_cache(revs, ent->item->sha1, ent->name, cached))
diff --git a/t/t4020-diff-external.sh b/t/t4020-diff-external.sh
index 083f62d1d6..c6fdab3e87 100755
--- a/t/t4020-diff-external.sh
+++ b/t/t4020-diff-external.sh
@@ -160,10 +160,10 @@ test_expect_success 'external diff with autocrlf = true' '
'
test_expect_success 'diff --cached' '
- git add file &&
+ git add .gitattributes file &&
git update-index --assume-unchanged file &&
echo second >file &&
- git diff --cached >actual &&
+ git diff --cached file >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
--
1.7.7.rc2.5.g12a2f
^ permalink raw reply related
* [PATCH 0/6] A handful of "branch description" patches
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <7vy5xi4y3m.fsf@alter.siamese.dyndns.org>
Here are a few patches that I have queued in 'pu', redoing some of the
patches I already sent out to the list, around "branch description".
The original motivation was to make the push/pull workflow appear more
robust by allowing human-to-human communication to leave audit trail that
can be verified when it becomes necessary. Namely:
* request-pull message carries the SHA-1 of what is expected to be
merged; and
* "signed push" leaves the SHA-1 of what was pushed to the remote,
cryptographically signed.
Linus's reaction, as I understood him, was "if we are spending efforts to
add more information, the end result should be more informative to humans
not just to machines", and I agree. An example of piece of information we
often talk about is branch description---what a particular branch is meant
to achieve. Both request-pull messages and declarations of what was pushed
are good places to record that piece of information.
So here is a partially re-rolled series to get us closer.
* The logic to read from an existing branch description was in
builtin/branch.c in the original series, but the first patch separates
it out into branch.c as a helper function;
* The second one is a digression; the branch description describes what
the topic aims to achieve, so it was natural to use it to prime the
cover letter while preparing a patch series with format-patch;
* The third one that adds "branch --edit-description" is basically
unchanged modulo small leakfix from the original round;
* And the remainder of the series for request-pull is the same as the
last round.
The second patch uses facility introduced in bk/ancestry-path topic, so
it would be the easiest to apply the series on top of a merge of c05b988
to 'master'.
I haven't updated the "signed push" patch to use this information yet.
Junio C Hamano (6):
branch: add read_branch_desc() helper function
format-patch: use branch description in cover letter
branch: teach --edit-description option
request-pull: modernize style
request-pull: state what commit to expect
request-pull: use the branch description
Documentation/git-branch.txt | 5 +++
branch.c | 31 ++++++++++++++++++
branch.h | 5 +++
builtin/branch.c | 56 +++++++++++++++++++++++++++++++-
builtin/log.c | 71 +++++++++++++++++++++++++++++++++++++++--
git-request-pull.sh | 73 ++++++++++++++++++++++++++---------------
t/t5150-request-pull.sh | 6 +++
7 files changed, 215 insertions(+), 32 deletions(-)
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply
* [PATCH 1/6] branch: add read_branch_desc() helper function
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
This will be used by various callers that make use of the branch
description throughout the system, so that if we need to update
the implementation the callers do not have to be modified.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 31 +++++++++++++++++++++++++++++++
branch.h | 5 +++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/branch.c b/branch.c
index fecedd3..88da275 100644
--- a/branch.c
+++ b/branch.c
@@ -135,6 +135,37 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
return 0;
}
+struct branch_desc_cb {
+ const char *config_name;
+ const char *value;
+};
+
+static int read_branch_desc_cb(const char *var, const char *value, void *cb)
+{
+ struct branch_desc_cb *desc = cb;
+ if (strcmp(desc->config_name, var))
+ return 0;
+ free((char *)desc->value);
+ return git_config_string(&desc->value, var, value);
+}
+
+int read_branch_desc(struct strbuf *buf, const char *branch_name)
+{
+ struct branch_desc_cb cb;
+ struct strbuf name = STRBUF_INIT;
+ strbuf_addf(&name, "branch.%s.description", branch_name);
+ cb.config_name = name.buf;
+ cb.value = NULL;
+ if (git_config(read_branch_desc_cb, &cb)) {
+ strbuf_release(&name);
+ return -1;
+ }
+ if (cb.value)
+ strbuf_addstr(buf, cb.value);
+ strbuf_release(&name);
+ return 0;
+}
+
int validate_new_branchname(const char *name, struct strbuf *ref,
int force, int attr_only)
{
diff --git a/branch.h b/branch.h
index 1285158..1493f73 100644
--- a/branch.h
+++ b/branch.h
@@ -46,4 +46,9 @@ void remove_branch_state(void);
#define BRANCH_CONFIG_VERBOSE 01
extern void install_branch_config(int flag, const char *local, const char *origin, const char *remote);
+/*
+ * Read branch description
+ */
+extern int read_branch_desc(struct strbuf *, const char *branch_name);
+
#endif
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 2/6] format-patch: use branch description in cover letter
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Use the description for the branch when preparing the cover letter
when available.
While at it, mark a loosely written codepath that would do a random and
useless thing given an unusual input (e.g. "^master HEAD HEAD^"), which
we may want to fix someday.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
branch.c | 2 +-
builtin/log.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/branch.c b/branch.c
index 88da275..50088a4 100644
--- a/branch.c
+++ b/branch.c
@@ -156,7 +156,7 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)
strbuf_addf(&name, "branch.%s.description", branch_name);
cb.config_name = name.buf;
cb.value = NULL;
- if (git_config(read_branch_desc_cb, &cb)) {
+ if (git_config(read_branch_desc_cb, &cb) < 0) {
strbuf_release(&name);
return -1;
}
diff --git a/builtin/log.c b/builtin/log.c
index f5d4930..e80a925 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -19,6 +19,7 @@
#include "remote.h"
#include "string-list.h"
#include "parse-options.h"
+#include "branch.h"
/* Set a default date-time format for git log ("log.date" config variable) */
static const char *default_date_mode = NULL;
@@ -746,10 +747,24 @@ static void print_signature(void)
printf("-- \n%s\n\n", signature);
}
+static void add_branch_description(struct strbuf *buf, const char *branch_name)
+{
+ struct strbuf desc = STRBUF_INIT;
+ if (!branch_name || !*branch_name)
+ return;
+ read_branch_desc(&desc, branch_name);
+ if (desc.len) {
+ strbuf_addch(buf, '\n');
+ strbuf_add(buf, desc.buf, desc.len);
+ strbuf_addch(buf, '\n');
+ }
+}
+
static void make_cover_letter(struct rev_info *rev, int use_stdout,
int numbered, int numbered_files,
struct commit *origin,
int nr, struct commit **list, struct commit *head,
+ const char *branch_name,
int quiet)
{
const char *committer;
@@ -807,6 +822,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
pp_user_info(&pp, NULL, &sb, committer, encoding);
pp_title_line(&pp, &msg, &sb, encoding, need_8bit_cte);
pp_remainder(&pp, &msg, &sb, 0);
+ add_branch_description(&sb, branch_name);
printf("%s\n", sb.buf);
strbuf_release(&sb);
@@ -1006,6 +1022,35 @@ static int cc_callback(const struct option *opt, const char *arg, int unset)
return 0;
}
+static char *find_branch_name(struct rev_info *rev)
+{
+ int i, positive = -1;
+ unsigned char branch_sha1[20];
+ struct strbuf buf = STRBUF_INIT;
+ const char *branch;
+
+ for (i = 0; i < rev->cmdline.nr; i++) {
+ if (rev->cmdline.rev[i].flags & UNINTERESTING)
+ continue;
+ if (positive < 0)
+ positive = i;
+ else
+ return NULL;
+ }
+ if (positive < 0)
+ return NULL;
+ strbuf_addf(&buf, "refs/heads/%s", rev->cmdline.rev[positive].name);
+ branch = resolve_ref(buf.buf, branch_sha1, 1, 0);
+ if (!branch ||
+ prefixcmp(branch, "refs/heads/") ||
+ hashcmp(rev->cmdline.rev[positive].item->sha1, branch_sha1))
+ branch = NULL;
+ strbuf_release(&buf);
+ if (branch)
+ return xstrdup(rev->cmdline.rev[positive].name);
+ return NULL;
+}
+
int cmd_format_patch(int argc, const char **argv, const char *prefix)
{
struct commit *commit;
@@ -1027,6 +1072,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
struct strbuf buf = STRBUF_INIT;
int use_patch_format = 0;
int quiet = 0;
+ char *branch_name = NULL;
const struct option builtin_format_patch_options[] = {
{ OPTION_CALLBACK, 'n', "numbered", &numbered, NULL,
"use [PATCH n/m] even with a single patch",
@@ -1217,8 +1263,16 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
* origin" that prepares what the origin side still
* does not have.
*/
+ unsigned char sha1[20];
+ const char *ref;
+
rev.pending.objects[0].item->flags |= UNINTERESTING;
add_head_to_pending(&rev);
+ ref = resolve_ref("HEAD", sha1, 1, NULL);
+ if (ref && !prefixcmp(ref, "refs/heads/"))
+ branch_name = xstrdup(ref + strlen("refs/heads/"));
+ else
+ branch_name = xstrdup(""); /* no branch */
}
/*
* Otherwise, it is "format-patch -22 HEAD", and/or
@@ -1234,16 +1288,26 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.show_root_diff = 1;
if (cover_letter) {
- /* remember the range */
+ /*
+ * NEEDSWORK:randomly pick one positive commit to show
+ * diffstat; this is often the tip and the command
+ * happens to do the right thing in most cases, but a
+ * complex command like "--cover-letter a b c ^bottom"
+ * picks "c" and shows diffstat between bottom..c
+ * which may not match what the series represents at
+ * all and totally broken.
+ */
int i;
for (i = 0; i < rev.pending.nr; i++) {
struct object *o = rev.pending.objects[i].item;
if (!(o->flags & UNINTERESTING))
head = (struct commit *)o;
}
- /* We can't generate a cover letter without any patches */
+ /* There is nothing to show; it is not an error, though. */
if (!head)
return 0;
+ if (!branch_name)
+ branch_name = find_branch_name(&rev);
}
if (ignore_if_in_upstream) {
@@ -1294,7 +1358,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (thread)
gen_message_id(&rev, "cover");
make_cover_letter(&rev, use_stdout, numbered, numbered_files,
- origin, nr, list, head, quiet);
+ origin, nr, list, head, branch_name, quiet);
total++;
start_number--;
}
@@ -1366,6 +1430,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
fclose(stdout);
}
free(list);
+ free(branch_name);
string_list_clear(&extra_to, 0);
string_list_clear(&extra_cc, 0);
string_list_clear(&extra_hdr, 0);
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 3/6] branch: teach --edit-description option
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Using branch.$name.description as the configuration key, give users a
place to write about what the purpose of the branch is and things like
that, so that various subsystems, e.g. "push -s", "request-pull", and
"format-patch --cover-letter", can later be taught to use this
information.
The "-m" option similar to "commit/tag" is deliberately omitted, as the
whole point of branch description is about giving descriptive information
(the name of the branch itself is a better place for information that fits
on a single-line).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-branch.txt | 5 +++
builtin/branch.c | 56 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 507b8d0..8871a4e 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -14,6 +14,7 @@ SYNOPSIS
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
+'git branch' --edit-description [<branchname>]
DESCRIPTION
-----------
@@ -144,6 +145,10 @@ start-point is either a local or remote-tracking branch.
like '--track' would when creating the branch, except that where
branch points to is not changed.
+--edit-description::
+ Open an editor and edit the text to explain what the branch is
+ for, to be used by various other commands (e.g. `request-pull`).
+
--contains <commit>::
Only list branches which contain the specified commit.
diff --git a/builtin/branch.c b/builtin/branch.c
index f49596f..fffa319 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -606,11 +606,49 @@ static int opt_parse_merge_filter(const struct option *opt, const char *arg, int
return 0;
}
+static const char edit_description[] = "BRANCH_DESCRIPTION";
+
+static int edit_branch_description(const char *branch_name)
+{
+ FILE *fp;
+ int status;
+ struct strbuf buf = STRBUF_INIT;
+ struct strbuf name = STRBUF_INIT;
+
+ read_branch_desc(&buf, branch_name);
+ if (!buf.len || buf.buf[buf.len-1] != '\n')
+ strbuf_addch(&buf, '\n');
+ strbuf_addf(&buf,
+ "# Please edit the description for the branch\n"
+ "# %s\n"
+ "# Lines starting with '#' will be stripped.\n",
+ branch_name);
+ fp = fopen(git_path(edit_description), "w");
+ if ((fwrite(buf.buf, 1, buf.len, fp) < buf.len) || fclose(fp)) {
+ strbuf_release(&buf);
+ return error(_("could not write branch description template: %s\n"),
+ strerror(errno));
+ }
+ strbuf_reset(&buf);
+ if (launch_editor(git_path(edit_description), &buf, NULL)) {
+ strbuf_release(&buf);
+ return -1;
+ }
+ stripspace(&buf, 1);
+
+ strbuf_addf(&name, "branch.%s.description", branch_name);
+ status = git_config_set(name.buf, buf.buf);
+ strbuf_release(&name);
+ strbuf_release(&buf);
+
+ return status;
+}
+
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, rename = 0, force_create = 0;
int verbose = 0, abbrev = -1, detached = 0;
- int reflog = 0;
+ int reflog = 0, edit_description = 0;
enum branch_track track;
int kinds = REF_LOCAL_BRANCH;
struct commit_list *with_commit = NULL;
@@ -648,6 +686,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
+ OPT_BOOLEAN(0, "edit-description", &edit_description,
+ "edit the description for the branch"),
OPT__FORCE(&force_create, "force creation (when already exists)"),
{
OPTION_CALLBACK, 0, "no-merged", &merge_filter_ref,
@@ -694,7 +734,19 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
- else if (argc == 0)
+ else if (edit_description) {
+ const char *branch_name;
+ if (detached)
+ die("Cannot give description to detached HEAD");
+ if (!argc)
+ branch_name = head;
+ else if (argc == 1)
+ branch_name = argv[0];
+ else
+ usage_with_options(builtin_branch_usage, options);
+ if (edit_branch_description(branch_name))
+ return 1;
+ } else if (argc == 0)
return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 4/6] request-pull: modernize style
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Make it a bit more conforming to Documentation/Codingstyle
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 29 +++++++++++++----------------
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index fc080cc..afb75e8 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,27 +35,24 @@ do
shift
done
-base=$1
-url=$2
-head=${3-HEAD}
+base=$1 url=$2 head=${3-HEAD}
-[ "$base" ] || usage
-[ "$url" ] || usage
+test -n "$base" && test -n "$url" || usage
+baserev=$(git rev-parse --verify "$base"^0) &&
+headrev=$(git rev-parse --verify "$head"^0) || exit
-baserev=`git rev-parse --verify "$base"^0` &&
-headrev=`git rev-parse --verify "$head"^0` || exit
-
-merge_base=`git merge-base $baserev $headrev` ||
+merge_base=$(git merge-base $baserev $headrev) ||
die "fatal: No commits in common between $base and $head"
-branch=$(git ls-remote "$url" \
- | sed -n -e "/^$headrev refs.heads./{
- s/^.* refs.heads.//
- p
- q
- }")
+find_matching_branch="/^$headrev "'refs\/heads\//{
+ s/^.* refs\/heads\///
+ p
+ q
+}'
+branch=$(git ls-remote "$url" | sed -n -e "$find_matching_branch")
url=$(git ls-remote --get-url "$url")
-if [ -z "$branch" ]; then
+if test -z "$branch"
+then
echo "warn: No branch of $url is at:" >&2
git log --max-count=1 --pretty='tformat:warn: %h: %s' $headrev >&2
echo "warn: Are you sure you pushed $head there?" >&2
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 6/6] request-pull: use the branch description
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
Now we have branch descriptions stored in the repository, we can
use it when preparing the request-pull message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 438e7eb..626cf25 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,7 +35,18 @@ do
shift
done
-base=$1 url=$2 head=${3-HEAD} status=0
+base=$1 url=$2 head=${3-HEAD} status=0 branch_name=
+
+headref=$(git symbolic-ref -q "$head")
+if git show-ref -q --verify "$headref"
+then
+ branch_name=${headref#refs/heads/}
+ if test "z$branch_name" = "z$headref" ||
+ ! git config "branch.$branch_name.description" >/dev/null
+ then
+ branch_name=
+ fi
+fi
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
@@ -66,6 +77,13 @@ for you to fetch changes up to %H:
----------------------------------------------------------------' $headrev &&
+if test -n "$branch_name"
+then
+ echo "(from the branch description for $branch local branch)"
+ echo
+ git config "branch.$branch_name.description"
+ echo "----------------------------------------------------------------"
+fi &&
git shortlog ^$baserev $headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 5/6] request-pull: state what commit to expect
From: Junio C Hamano @ 2011-09-22 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <1316729362-7714-1-git-send-email-gitster@pobox.com>
The message gives a detailed explanation of the commit the requester based
the changes on, but lacks information that is necessary for the person who
performs a fetch & merge in order to verify that the correct branch was
fetched when responding to the pull request.
Add a few more lines to describe the commit at the tip expected to be
fetched to the same level of detail as the base commit.
Also update the warning message slightly when the script notices that the
commit may not have been pushed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 34 +++++++++++++++++++---------------
t/t5150-request-pull.sh | 6 ++++++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index afb75e8..438e7eb 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,7 +35,7 @@ do
shift
done
-base=$1 url=$2 head=${3-HEAD}
+base=$1 url=$2 head=${3-HEAD} status=0
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
@@ -51,25 +51,29 @@ find_matching_branch="/^$headrev "'refs\/heads\//{
}'
branch=$(git ls-remote "$url" | sed -n -e "$find_matching_branch")
url=$(git ls-remote --get-url "$url")
-if test -z "$branch"
-then
- echo "warn: No branch of $url is at:" >&2
- git log --max-count=1 --pretty='tformat:warn: %h: %s' $headrev >&2
- echo "warn: Are you sure you pushed $head there?" >&2
- echo >&2
- echo >&2
- branch=..BRANCH.NOT.VERIFIED..
- status=1
-fi
git show -s --format='The following changes since commit %H:
%s (%ci)
-are available in the git repository at:' $baserev &&
-echo " $url $branch" &&
-echo &&
+are available in the git repository at:
+' $baserev &&
+echo " $url${branch+ $branch}" &&
+git show -s --format='
+for you to fetch changes up to %H:
+
+ %s (%ci)
+
+----------------------------------------------------------------' $headrev &&
git shortlog ^$baserev $headrev &&
-git diff -M --stat --summary $patch $merge_base..$headrev || exit
+git diff -M --stat --summary $patch $merge_base..$headrev || status=1
+
+if test -z "$branch"
+then
+ echo "warn: No branch of $url is at:" >&2
+ git show -s --format='warn: %h: %s' $headrev >&2
+ echo "warn: Are you sure you pushed '$head' there?" >&2
+ status=1
+fi
exit $status
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 9cc0a42..5bd1682 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -193,8 +193,14 @@ test_expect_success 'pull request format' '
SUBJECT (DATE)
are available in the git repository at:
+
URL BRANCH
+ for you to fetch changes up to OBJECT_NAME:
+
+ SUBJECT (DATE)
+
+ ----------------------------------------------------------------
SHORTLOG
DIFFSTAT
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* Re: [PATCH 1/2] fast-import: don't allow to tag empty branch
From: Sverre Rabbelier @ 2011-09-22 22:28 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Jonathan Nieder, Shawn O. Pearce, David Barr
In-Reply-To: <1316720825-32552-2-git-send-email-divanorama@gmail.com>
Heya,
On Thu, Sep 22, 2011 at 21:47, Dmitry Ivankov <divanorama@gmail.com> wrote:
> 'reset' command makes fast-import start a branch from scratch. It's name
> is kept in lookup table but it's sha1 is null_sha1 (special value).
> 'tag' command can be used to tag a branch by it's name. lookup_branch()
> is used it that case and it doesn't check for null_sha1. So fast-import
> writes a tag for null_sha1 object instead of giving a error.
>
> Add a check to deny tagging an empty branch and add a corresponding test.
Makes sense to me.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: don't allow to note on empty branch
From: Sverre Rabbelier @ 2011-09-22 22:29 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Jonathan Nieder, Shawn O. Pearce, David Barr
In-Reply-To: <1316720825-32552-3-git-send-email-divanorama@gmail.com>
Heya,
On Thu, Sep 22, 2011 at 21:47, Dmitry Ivankov <divanorama@gmail.com> wrote:
> 'reset' command makes fast-import start a branch from scratch. It's name
> is kept in lookup table but it's sha1 is null_sha1 (special value).
> 'notemodify' command can be used to add a note on branch head given it's
> name. lookup_branch() is used it that case and it doesn't check for
> null_sha1. So fast-import writes a note for null_sha1 object instead of
> giving a error.
>
> Add a check to deny adding a note on empty branch and add a corresponding
> test.
Makes sense as well.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Junio C Hamano @ 2011-09-22 22:39 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <1316727861-90460-2-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> When diff'ing the index against a tree (using either diff-index
> or diff --cached), git previously looked at .gitattributes in the
> working tree before considering .gitattributes in the index, even
> though the diff itself otherwise ignores the working tree.
We can take attributes only from one place (so far from the working tree
and perhaps from the index), people had to live within the limitation that
comes from the "single source only" semantics. It also happens to be
easier to understand (recall the complexity of the examples Jeff gave
about "textconv" during "diff" which ideally should apply from its own
side and "funcname", which does not even have a right answer).
In practice, because development progresses by making everything
(including the .gitattributes file) better, I think "use the newer one"
would be a good compromise when we have two possible sources to grab
attributes from but we can only use one source.
In that sense, I am somewhat skeptical about what this patch tries to
do. The working tree is where people make the progress to update the
index.
A related tangent.
I think the logical conclusion of assuming that we will keep the "single
source only" semantics (which I think we will, by the way, unless I hear a
concrete proposal to how we apply attributes from more than one sources in
what way to which side of the diff) is that a patch might be an
improvement over the current behaviour if it teaches "diff-tree" to read
from the tree and populate the in-core index (never writing it out to
$GIT_DIR/index) from the postimage tree (i.e. "diff preimage postimage" or
"diff -R postimage preimage") when it is run in a bare repository. It
would be a regression if the attributes mechanism is used for auditing
purposes (as we start reading from a tree that is being audited using the
very attributes it brings in), though.
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jakub Narebski @ 2011-09-22 22:54 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git discussion list, Jay Soffian
In-Reply-To: <4E7AF1AE.5030005@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Thanks for the reply and for explaining how the index can(not) be used
> for this purpose. But what you propose is not flexible enough for me.
> I would like the checking configuration to be *versioned* along with the
> code. [...]
[...]
> For this to be possible, I would need to determine the git attributes to
> apply to a particular file in a particular commit; something like
>
> git check-attr check-space-indent $SHA1:path/to/file
>
> This does not seem to be possible today without writing my own code to
> crawl and parse the gitattributes files from a particular commit.
Unfortunately it doesn't seem to be there mechanism to query about
state of gitattributes at given commit.
There is a slight problem from the UI point of view of git-check-attr,
namely that there are _three_ pieces of information: a place to read
.gitattributes from (working tree, index, commit), list of attributes
to check (or --all) and list of files (list of paths). You can use
"--" to separate _two_ pieces of information.
Nb. the ability to read gitattributes from given commit would be
useful also for gitweb (the `encoding` gitattribute, etc.).
--
Jakub Narębski
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Jakub Narebski @ 2011-09-22 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9xyxpf.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> --------------------------------------------------
> [New Topics]
> * jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
> - Documentation/gitnamespaces.txt: cater to older asciidoc
I'll need this to e.g. test the "rpm" target after adding
Documentation/gitweb.txt and Documentation/gitweb.conf.txt
But it is not something very urgent; the series are cooking now:
"[PATCH/RFCv4 0/4] Moving gitweb documentation to manpages"
http://thread.gmane.org/gmane.comp.version-control.git/181605
--
Jakub Narębski
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-22 23:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3r538qj0j.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> --------------------------------------------------
>> [New Topics]
>
>> * jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
>> - Documentation/gitnamespaces.txt: cater to older asciidoc
>
> I'll need this to e.g. test the "rpm" target after adding
> Documentation/gitweb.txt and Documentation/gitweb.conf.txt
>
> But it is not something very urgent...
Now I am confused. If you apply your patch on top of "master" then you
cannot create "rpm" on your platform, not because your patch is busted,
but because "master" lacks the documentation fix from that topic. Is that
what you mean?
If the reason the documentation fix for "master" is needed is because a
new feature scheduled for the upcoming release has broken documentation,
then wouldn't we need the fix before the release, whether you are working
on your patch or not? How can it be not urgent if that is the case?
On my boxes with recent Debian, Ubuntu, and F14, I am not suffering from
the lack of the workaround, but if distros need the workaround, then the
time to apply it is now, not post release.
Hmmm....
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Jakub Narebski @ 2011-09-22 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4o04xjcb.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> --------------------------------------------------
>>> [New Topics]
>>
>>> * jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
>>> - Documentation/gitnamespaces.txt: cater to older asciidoc
>>
>> I'll need this to e.g. test the "rpm" target after adding
>> Documentation/gitweb.txt and Documentation/gitweb.conf.txt
>>
>> But it is not something very urgent...
>
> Now I am confused. If you apply your patch on top of "master" then you
> cannot create "rpm" on your platform, not because your patch is busted,
> but because "master" lacks the documentation fix from that topic. Is that
> what you mean?
Yes, that is what I mean... but that it is only because I use old
version of asciidoc (7.1.2).
"make doc" (which is part of "make rpm") fails on my box with
ASCIIDOC gitnamespaces.html
ERROR: gitnamespaces.txt: line 9: second section must be named SYNOPSIS
make[1]: *** [gitnamespaces.html] Error 1
> If the reason the documentation fix for "master" is needed is because a
> new feature scheduled for the upcoming release has broken documentation,
> then wouldn't we need the fix before the release, whether you are working
> on your patch or not? How can it be not urgent if that is the case?
>
> On my boxes with recent Debian, Ubuntu, and F14, I am not suffering from
> the lack of the workaround, but if distros need the workaround, then the
> time to apply it is now, not post release.
I don't think _modern_ distributions need this workaround... asciidoc 8.4.5
which fixed the issue with "Synopsis" section was released 2009-05-24:
http://www.methods.co.nz/asciidoc/CHANGELOG.html
Version 8.4.5 (2009-05-24)
--------------------------
Additions and changes
~~~~~~~~~~~~~~~~~~~~~
* Added manpage "Name" and "Synopsis" section title customization to
languages configuration files.
* "Synopsis" manpage section no longer mandatory.
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/2] Teach '--cached' option to check-attr
From: Junio C Hamano @ 2011-09-22 23:36 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <1316727861-90460-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> This doesn't seem too controversial to me, and allows server-side
> reading of .gitattributes, albeit with the need to setup an index.
Thanks; will queue with a few trivial tweaks.
> +test_expect_success 'bare repository: check that --cached honors index' '
> +
> + export GIT_INDEX_FILE=../.git/index &&
> + git check-attr --cached --stdin --all < ../stdin-all |
> + sort > actual &&
> + test_cmp ../specified-all actual
> +
> +'
This is unfriendly to others who need to add more tests after this piece
by contaminating their environment. A single-shot export would be more
appropriate here:
GIT_INDEX_FILE=../.git/index git check-attr --cached ...
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-22 23:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201109230133.33214.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I don't think _modern_ distributions need this workaround... asciidoc 8.4.5
> which fixed the issue with "Synopsis" section was released 2009-05-24:
Thanks for a clarification. I'll then hold it off until the upcoming
release and then merge it to see if anybody screams.
^ permalink raw reply
* ( MESSAGE FROM TOKYO JAPAN)
From: Mr. Kang Hoon @ 2011-09-22 23:50 UTC (permalink / raw)
To: mrkanghoon@yahoo.com.hk
Hello,
Good day, how are you today hope healthy? Please my English speaking is not
very good, but I can write better than to speak.
I am Mr Kang Hoon, From Republic of Korea writing from Home Center Kohnan,
Koto Fukagawa (Tokyo) Japan. I worked as the general caretaker to
Mr.Masamichi Kazama, late Mr. Kazama, his a banker and real estate developer
living in Fukushima Japan but died during the tsunami disaster (earthquake)
in Fukushima Japan, I am the closes person that work with late Mr. Masamichi
Kazama before his death.
Mr. Masamichi Kazama have a safe deposit fund of US$22,600,000.00 with a
private vault house abroad and which I have the original certificate of
deposit with me for the claims, all I need from you is to contact the
private vault house abroad with prove of the certificate of deposit for the
released of the safe deposit in your favor. We share 60% for you and 40% for
me if you are interested contact me with my private email for more details
(infomrkanghoon@yahoo.com.hk )
Read more about lost of life's, peoples relatives lost businesses, huge
amount of money, properties and many more on the link below
http://www.huffingtonpost.com/2011/04/10/japan-lost-money-safes-cash_n_8472
43.html
I am waiting to hear from you.
Sincerely yours,
Mr. Kang Hoon
Tokyo - Japan.
This is a confidential message
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Jay Soffian @ 2011-09-23 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <7v8vpgxkvb.fsf@alter.siamese.dyndns.org>
On Thu, Sep 22, 2011 at 6:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> When diff'ing the index against a tree (using either diff-index
>> or diff --cached), git previously looked at .gitattributes in the
>> working tree before considering .gitattributes in the index, even
>> though the diff itself otherwise ignores the working tree.
>
> We can take attributes only from one place (so far from the working tree
> and perhaps from the index), people had to live within the limitation that
> comes from the "single source only" semantics. It also happens to be
> easier to understand (recall the complexity of the examples Jeff gave
> about "textconv" during "diff" which ideally should apply from its own
> side and "funcname", which does not even have a right answer).
>
> In practice, because development progresses by making everything
> (including the .gitattributes file) better, I think "use the newer one"
> would be a good compromise when we have two possible sources to grab
> attributes from but we can only use one source.
I agree with that...
> In that sense, I am somewhat skeptical about what this patch tries to
> do. The working tree is where people make the progress to update the
> index.
... but it still seems inconsistent that --cached ignores the working
tree except for .gitattributes.
This also happens to be the only way to get diff-index to work with a
bare repo and temporary (on-disk) index. But that's less important if
we implement what's suggested in the next paragraph.
> A related tangent.
>
> I think the logical conclusion of assuming that we will keep the "single
> source only" semantics (which I think we will, by the way, unless I hear a
> concrete proposal to how we apply attributes from more than one sources in
> what way to which side of the diff) is that a patch might be an
> improvement over the current behaviour if it teaches "diff-tree" to read
> from the tree and populate the in-core index (never writing it out to
> $GIT_DIR/index) from the postimage tree (i.e. "diff preimage postimage" or
> "diff -R postimage preimage") when it is run in a bare repository.
Okay, I can give that a try.
> It
> would be a regression if the attributes mechanism is used for auditing
> purposes (as we start reading from a tree that is being audited using the
> very attributes it brings in), though.
--[no-]tree-attributes?
j.
^ permalink raw reply
* permission to re-license archive-zip.c and zlib.c as LGPL
From: Brandon Casey @ 2011-09-23 3:51 UTC (permalink / raw)
To: rene.scharfe, Junio C Hamano, git, dpotapov, vagabon.xyz
To those who have contributed to archive-zip.c and zlib.c,
I'd like to make a library for writing zip files. I really don't see
another library out there that does it as easily as archive-zip. So,
with your consent, I'd like to re-license the code in archive-zip.c
and zlib.c as LGPL so that I can create an archive-zip library. The
reason for LGPL, of course, is so that it can be linked with non-GPL
code.
Please offer your consent to re-license your contributions under LGPL
by replying to this email.
All comments welcome.
Thanks,
-Brandon
^ permalink raw reply
* What's The Right Way to Do This?
From: Jon Forrest @ 2011-09-23 4:48 UTC (permalink / raw)
To: git
I'm just now starting to use git for more than trivial things.
Today I got myself in trouble. Here's what happened:
1) I pulled the master branch from the IT repository from our
main git server.
2) I created a branch from this called "J" and started making changes.
3) Other people pulled master from IT and then pushed changes back.
4) I merged J with my master branch.
5) I tried pushing my master back to origin but this failed with
the usual message saying I first needed to pull from origin.
So, I pulled and then pushed. This worked.
6) On another server where I was going to use my changes I pulled
master from IT.
6) It turned out that my changes were incorrect. So, I tried to revert
using various methods I found by googling "git revert". What happened
was that when I tried to revert back to the commit before the one I
made, the files I had modified *and* the files that apparently were
modified by other people in #3 above were reverted. This wasn't what
I wanted. I only wanted to revert the changes I had made.
With the help of someone more experienced than me we were able to get
things back to normal but this experience left me wondering what I
should have done in the first place. There's a chance I'm going to
have to go through all this again as I try to fix the problem with
my changes.
Any suggestions would be appreciated.
Thanks,
Jon Forrest
^ permalink raw reply
* deleting non-existent ref via push
From: Sitaram Chamarty @ 2011-09-23 5:04 UTC (permalink / raw)
To: Git Mailing List
Hello,
Pushing to delete a non-existent ref (git push origin :refs/heads/foo)
works without error, except for a warning that the remote is "Allowing
deletion of corrupt ref". By "works" I mean all hooks are also
executed.
Is this expected/supported behaviour? Can I rely on it continuing to
work, especially in terms of executing hooks.
Seem like a great way to "poke" a remote repo into executing hooks
without having to make a dummy change and push :-)
--
Sitaram
^ permalink raw reply
* Re: What's The Right Way to Do This?
From: Michael Witten @ 2011-09-23 5:08 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
In-Reply-To: <loom.20110923T064720-366@post.gmane.org>
On Fri, Sep 23, 2011 at 04:48, Jon Forrest <nobozo@gmail.com> wrote:
> ... So, I tried to revert using various methods I found by
> googling "git revert"...
> ...
> ...this experience left me wondering what I should have
> done in the first place.
What you should have done in the first place is RTFM; while
not fantastic, there is a decent amount of official git
documentation.
> What happened was that when I tried to revert back to the
> commit before the one I made, the files I had modified
> *and* the files that apparently were modified by other
> people in #3 above were reverted. This wasn't what
> I wanted. I only wanted to revert the changes I had made.
It would be a good idea to reproduce the unexpected behavior
you are experiencing by means of a minimal set of commands
that you can post here for others to try.
> With the help of someone more experienced than me we were
> able to get things back to normal... There's a chance I'm
> going to have to go through all this again as I try to fix
> the problem with my changes.
Why don't you ask that person about it?
^ 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