* [PATCH v3 01/23] doc: Add a link from gitattributes(5) to git-check-attr(1)
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/gitattributes.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 2bbe76b..25e46ae 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -955,6 +955,9 @@ frotz unspecified
----------------------------------------------------------------
+SEE ALSO
+--------
+linkgit:git-check-attr[1].
GIT
---
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 08/23] git-check-attr: Use git_attr_name()
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/check-attr.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 3016d29..5f04126 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -21,7 +21,7 @@ static const struct option check_attr_options[] = {
};
static void check_attr(int cnt, struct git_attr_check *check,
- const char** name, const char *file)
+ const char *file)
{
int j;
if (git_checkattr(file, cnt, check))
@@ -37,12 +37,11 @@ static void check_attr(int cnt, struct git_attr_check *check,
value = "unspecified";
quote_c_style(file, NULL, stdout, 0);
- printf(": %s: %s\n", name[j], value);
+ printf(": %s: %s\n", git_attr_name(check[j].attr), value);
}
}
-static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
- const char** name)
+static void check_attr_stdin_paths(int cnt, struct git_attr_check *check)
{
struct strbuf buf, nbuf;
int line_termination = null_term_line ? 0 : '\n';
@@ -56,7 +55,7 @@ static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
die("line is badly quoted");
strbuf_swap(&buf, &nbuf);
}
- check_attr(cnt, check, name, buf.buf);
+ check_attr(cnt, check, buf.buf);
maybe_flush_or_die(stdout, "attribute to stdout");
}
strbuf_release(&buf);
@@ -113,10 +112,10 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
}
if (stdin_paths)
- check_attr_stdin_paths(cnt, check, argv);
+ check_attr_stdin_paths(cnt, check);
else {
for (i = doubledash; i < argc; i++)
- check_attr(cnt, check, argv, argv[i]);
+ check_attr(cnt, check, argv[i]);
maybe_flush_or_die(stdout, "attribute to stdout");
}
return 0;
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 06/23] git-check-attr: Add tests of command-line parsing
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
t/t0003-attributes.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index dae76b3..f1debeb 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -44,6 +44,13 @@ test_expect_success 'setup' '
test_expect_success 'command line checks' '
+ test_must_fail git check-attr &&
+ test_must_fail git check-attr -- &&
+ test_must_fail git check-attr -- f &&
+ echo "f" | test_must_fail git check-attr --stdin &&
+ echo "f" | test_must_fail git check-attr --stdin -- f &&
+ echo "f" | test_must_fail git check-attr --stdin test -- f &&
+ echo "f" | test_must_fail git check-attr --stdin test f &&
test_must_fail git check-attr "" -- f
'
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 09/23] Teach prepare_attr_stack() to figure out dirlen itself
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
attr.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/attr.c b/attr.c
index bfa1f43..7f0f390 100644
--- a/attr.c
+++ b/attr.c
@@ -535,11 +535,18 @@ static void bootstrap_attr_stack(void)
}
}
-static void prepare_attr_stack(const char *path, int dirlen)
+static void prepare_attr_stack(const char *path)
{
struct attr_stack *elem, *info;
- int len;
+ int dirlen, len;
struct strbuf pathbuf;
+ const char *cp;
+
+ cp = strrchr(path, '/');
+ if (!cp)
+ dirlen = 0;
+ else
+ dirlen = cp - path;
strbuf_init(&pathbuf, dirlen+2+strlen(GITATTRIBUTES_FILE));
@@ -709,20 +716,14 @@ static int macroexpand_one(int attr_nr, int rem)
int git_checkattr(const char *path, int num, struct git_attr_check *check)
{
struct attr_stack *stk;
- const char *cp;
- int dirlen, pathlen, i, rem;
+ int pathlen, i, rem;
bootstrap_attr_stack();
for (i = 0; i < attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
pathlen = strlen(path);
- cp = strrchr(path, '/');
- if (!cp)
- dirlen = 0;
- else
- dirlen = cp - path;
- prepare_attr_stack(path, dirlen);
+ prepare_attr_stack(path);
rem = attr_nr;
for (stk = attr_stack; 0 < rem && stk; stk = stk->prev)
rem = fill(path, pathlen, stk, rem);
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 07/23] Provide access to the name attribute of git_attr
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
It will be present in any likely future reimplementation, and its
availability simplifies other code.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/technical/api-gitattributes.txt | 3 ++-
attr.c | 5 +++++
attr.h | 7 +++++++
3 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt
index 916720f..ab3a84d 100644
--- a/Documentation/technical/api-gitattributes.txt
+++ b/Documentation/technical/api-gitattributes.txt
@@ -13,7 +13,8 @@ Data Structure
An attribute is an opaque object that is identified by its name.
Pass the name to `git_attr()` function to obtain the object of
this type. The internal representation of this structure is
- of no interest to the calling programs.
+ of no interest to the calling programs. The name of the
+ attribute can be retrieved by calling `git_attr_name()`.
`struct git_attr_check`::
diff --git a/attr.c b/attr.c
index b1d1d6d..bfa1f43 100644
--- a/attr.c
+++ b/attr.c
@@ -36,6 +36,11 @@ static int attr_nr;
static struct git_attr_check *check_all_attr;
static struct git_attr *(git_attr_hash[HASHSIZE]);
+char *git_attr_name(struct git_attr *attr)
+{
+ return attr->name;
+}
+
static unsigned hash_name(const char *name, int namelen)
{
unsigned val = 0, c;
diff --git a/attr.h b/attr.h
index 8b3f19b..d4f875a 100644
--- a/attr.h
+++ b/attr.h
@@ -29,6 +29,13 @@ struct git_attr_check {
const char *value;
};
+/*
+ * Return the name of the attribute represented by the argument. The
+ * return value is a pointer to a null-delimited string that is part
+ * of the internal data structure; it should not be modified or freed.
+ */
+char *git_attr_name(struct git_attr *);
+
int git_checkattr(const char *path, int, struct git_attr_check *);
enum git_attr_direction {
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 04/23] Disallow the empty string as an attribute name
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Previously, it was possible to have a line like "file.txt =foo" in a
.gitattribute file, after which an invocation like "git check-attr ''
-- file.txt" would succeed. This patch disallows both constructs.
Please note that any existing .gitattributes file that tries to set an
empty attribute will now trigger the error message "error: : not a
valid attribute name" whereas previously the nonsense was allowed
through.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
attr.c | 2 +-
t/t0003-attributes.sh | 6 ++++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index 4a1244f..b1d1d6d 100644
--- a/attr.c
+++ b/attr.c
@@ -53,7 +53,7 @@ static int invalid_attr_name(const char *name, int namelen)
* Attribute name cannot begin with '-' and must consist of
* characters from [-A-Za-z0-9_.].
*/
- if (*name == '-')
+ if (namelen <= 0 || *name == '-')
return -1;
while (namelen--) {
char ch = *name++;
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index ebbc755..8c76b79 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -42,6 +42,12 @@ test_expect_success 'setup' '
'
+test_expect_success 'command line checks' '
+
+ test_must_fail git check-attr "" -- f
+
+'
+
test_expect_success 'attribute test' '
attr_check f f &&
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 05/23] git-check-attr: Add missing "&&"
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
t/t0003-attributes.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 8c76b79..dae76b3 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -35,7 +35,7 @@ test_expect_success 'setup' '
echo "h test=a/b/h" &&
echo "d/* test=a/b/d/*"
echo "d/yes notest"
- ) >a/b/.gitattributes
+ ) >a/b/.gitattributes &&
(
echo "global test=global"
) >"$HOME"/global-gitattributes
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 03/23] Remove anachronism from comment
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Setting attributes to arbitrary values ("attribute=value") is now
supported, so it is no longer necessary for this comment to justify
prohibiting '=' in an attribute name.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
attr.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/attr.c b/attr.c
index f6b3f7e..4a1244f 100644
--- a/attr.c
+++ b/attr.c
@@ -50,10 +50,8 @@ static unsigned hash_name(const char *name, int namelen)
static int invalid_attr_name(const char *name, int namelen)
{
/*
- * Attribute name cannot begin with '-' and from
- * [-A-Za-z0-9_.]. We'd specifically exclude '=' for now,
- * as we might later want to allow non-binary value for
- * attributes, e.g. "*.svg merge=special-merge-program-for-svg"
+ * Attribute name cannot begin with '-' and must consist of
+ * characters from [-A-Za-z0-9_.].
*/
if (*name == '-')
return -1;
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 02/23] doc: Correct git_attr() calls in example code
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
In-Reply-To: <1312432593-9841-1-git-send-email-mhagger@alum.mit.edu>
Commit 7fb0eaa2 (2010-01-17) changed git_attr() to take a string
instead of a string and a length. Update the documentation
accordingly.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/technical/api-gitattributes.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt
index 9d97eaa..916720f 100644
--- a/Documentation/technical/api-gitattributes.txt
+++ b/Documentation/technical/api-gitattributes.txt
@@ -11,9 +11,9 @@ Data Structure
`struct git_attr`::
An attribute is an opaque object that is identified by its name.
- Pass the name and its length to `git_attr()` function to obtain
- the object of this type. The internal representation of this
- structure is of no interest to the calling programs.
+ Pass the name to `git_attr()` function to obtain the object of
+ this type. The internal representation of this structure is
+ of no interest to the calling programs.
`struct git_attr_check`::
@@ -72,8 +72,8 @@ static void setup_check(void)
{
if (check[0].attr)
return; /* already done */
- check[0].attr = git_attr("crlf", 4);
- check[1].attr = git_attr("ident", 5);
+ check[0].attr = git_attr("crlf");
+ check[1].attr = git_attr("ident");
}
------------
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH v3 00/23] Add --all option to git-check-attr
From: Michael Haggerty @ 2011-08-04 4:36 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
This re-roll differs in the following ways from v2:
* The following series of refactoring patches were inserted:
Teach prepare_attr_stack() to figure out dirlen itself
Extract a function collect_all_attrs()
Remove redundant call to bootstrap_attr_stack()
Remove redundant check
This change, in turn, simplifies patch
Allow querying all attributes on a file
* The new API function is named git_all_attrs() instead of
git_allattrs().
* Additionally, git_checkattr() is renamed to git_check_attr() at the
suggestion of Junio.
* The renaming of struct git_attr_check to git_attr_value is no longer
part of the patch series.
Thanks to Junio for the great feedback. I believe that I have
addressed all of your comments.
Michael Haggerty (23):
doc: Add a link from gitattributes(5) to git-check-attr(1)
doc: Correct git_attr() calls in example code
Remove anachronism from comment
Disallow the empty string as an attribute name
git-check-attr: Add missing "&&"
git-check-attr: Add tests of command-line parsing
Provide access to the name attribute of git_attr
git-check-attr: Use git_attr_name()
Teach prepare_attr_stack() to figure out dirlen itself
Extract a function collect_all_attrs()
Remove redundant call to bootstrap_attr_stack()
Remove redundant check
Allow querying all attributes on a file
git-check-attr: Extract a function output_attr()
git-check-attr: Introduce a new variable
git-check-attr: Extract a function error_with_usage()
git-check-attr: Handle each error separately
git-check-attr: Process command-line args more systematically
git-check-attr: Error out if no pathnames are specified
git-check-attr: Add an --all option to show all attributes
git-check-attr: Drive two tests using the same raw data
git-check-attr: Fix command-line handling to match docs
Rename git_checkattr() to git_check_attr()
Documentation/git-check-attr.txt | 23 ++++-
Documentation/gitattributes.txt | 3 +
Documentation/technical/api-gitattributes.txt | 63 +++++++++-----
archive.c | 2 +-
attr.c | 79 ++++++++++++----
attr.h | 20 ++++-
builtin/check-attr.c | 121 +++++++++++++++++--------
builtin/pack-objects.c | 2 +-
convert.c | 2 +-
ll-merge.c | 4 +-
t/t0003-attributes.sh | 61 +++++++++----
userdiff.c | 2 +-
ws.c | 2 +-
13 files changed, 272 insertions(+), 112 deletions(-)
--
1.7.6.8.gd2879
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Jeff King @ 2011-08-04 4:06 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4E383132.3040907@elegosoft.com>
On Tue, Aug 02, 2011 at 07:17:38PM +0200, Michael Schubert wrote:
> @@ -297,6 +298,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
> if ((kind & ref_list->kinds) == 0)
> return 0;
>
> + if (cb->remote && strncmp(cb->remote, refname, strlen(cb->remote)))
> + return 0;
> +
This isn't right. You are assuming that a remote called "foo" will have
all of its branches in refs/remotes/foo. That's true under the default
configuration, but technically speaking, the remote tracking branches of
"foo" are defined by the right-hand side of foo's fetch refspecs.
So I think you want something more like this:
int i;
struct remote *remote = remote_get("foo");
for (i = 0; i < remote->fetch_refspec_nr; i++) {
struct refspec *rs = remote->fetch + i;
/* if it's not a wildcard, then take the rhs verbatim */
if (!rs->pattern)
append_ref(rs->dst);
else {
/* it's a wildcard like refs/remotes/foo/*; glob in
* the ref list appropriately. Or we can cheat, noting
* that git's only allowed wildcard is "/*" at the
* end, and do this: */
char *prefix = xstrndup(rs->dst, strlen(rs->dst) - 1);
for_each_ref_in(prefix, append_ref, NULL);
}
}
instead of the call to "for_each_rawref(append_ref, ...)" that would
normally be used. You could even pretty easily allow selecting branches
from multiple remotes, too, though I don't know if that is actually
useful.
-Peff
^ permalink raw reply
* Re: [PATCH 11/18] revert: Save command-line options for continuing operation
From: Christian Couder @ 2011-08-04 4:05 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Junio C Hamano, Git List, Jonathan Nieder, Daniel Barkalow,
Jeff King
In-Reply-To: <1312222025-28453-12-git-send-email-artagnon@gmail.com>
On Monday 01 August 2011 20:06:58 Ramkumar Ramachandra wrote:
> +
> +test_expect_success 'cherry-pick persists opts correctly' '
> + rm -rf .git/sequencer &&
> + pristine_detach initial &&
pristine_detach() does a "rm -rf .git/sequencer" already.
> + test_must_fail git cherry-pick -s -m 1 --strategy=recursive -X patience
> -X ours base..anotherpick && + test_path_is_dir .git/sequencer &&
> + test_path_is_file .git/sequencer/head &&
> + test_path_is_file .git/sequencer/todo &&
> + test_path_is_file .git/sequencer/opts &&
> + echo "true" >expect
"&&" is missing at the end of the line.
> + git config --file=.git/sequencer/opts --get-all options.signoff >actual
> &&
> + test_cmp expect actual &&
> + echo "1" >expect
"&&" is missing at the end of the line.
> + git config --file=.git/sequencer/opts --get-all options.mainline >actual
> &&
> + test_cmp expect actual &&
> + echo "recursive" >expect
"&&" is missing at the end of the line.
> + git config --file=.git/sequencer/opts --get-all options.strategy >actual
> &&
> + test_cmp expect actual &&
> + cat >expect <<-\EOF
"&&" is missing at the end of the line.
> + patience
> + ours
> + EOF
> + git config --file=.git/sequencer/opts --get-all options.strategy-option
> >actual &&
> >+ test_cmp expect actual
> '
Thanks,
Christian.
^ permalink raw reply
* Re: per-ref data storage (was: Storing additional information in commit headers)
From: Jeff King @ 2011-08-04 3:41 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802192727.GB20239@fishbowl.rw.madduck.net>
On Tue, Aug 02, 2011 at 09:27:28PM +0200, martin f krafft wrote:
> [sorry, my previous message was a total reply FAIL]
>
> also sprach martin f krafft <madduck@madduck.net> [2011.08.02.2106 +0200]:
> > It just seems to me that per-ref storage is a lot further away than
> > per-commit storage, and I'd really like to move forward with TopGit…
>
> refs/heads/master is a file, containing its payload in the first
> line by format definition, right?
>
> I mean: the storage is right there, isn't it?
Yes, and I think git will even ignore other stuff in the file. But I
don't think you can count on git not obliterating the other stuff when
it updates the ref. Nor would it be passed over a clone or fetch.
> Of course this opens a whole new can of worms: merging per-ref data.
Yes. That's the tricky part. And that's something you'll have to deal
with no matter how you store it, I expect.
-Peff
^ permalink raw reply
* Re: Storing additional information in commit headers
From: Jeff King @ 2011-08-04 3:39 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802190645.GB17322@fishbowl.rw.madduck.net>
On Tue, Aug 02, 2011 at 09:06:45PM +0200, martin f krafft wrote:
> It just seems to me that per-ref storage is a lot further away than
> per-commit storage, and I'd really like to move forward with TopGit…
I don't think it's that hard. For example:
# our mapping for all refs, and the history of that mapping, will be
# stored under this ref
MAP=refs/topgit/metadata
refmap_set() {
(
# start with a pristine index based on the current map
GIT_INDEX_FILE="$(git rev-parse --git-dir)/tg-meta-index"
export GIT_INDEX_FILE
if git rev-parse -q --verify $MAP >/dev/null; then
git read-tree $MAP
fi
# and then put our new ref and metadata in
blob=`git hash-object --stdin -w`
git update-index --add --cacheinfo 100644 $blob $1
tree=`git write-tree`
parent=$(git rev-parse -q --verify $MAP)
commit=`echo 'updated map' | git commit-tree $tree ${parent:+-p $parent}`
git update-ref $MAP $commit $old
)
}
refmap_get() {
git cat-file blob $MAP:$1
}
# and some examples of use
echo some metadata | refmap_set refs/heads/foo
refmap_get refs/heads/foo |
sed 's/meta/changed &/' |
refmap_set refs/heads/foo
It's a little more clunky than notes, of course, but it's not too bad to
put into a script. The tricky part is how to handle fetching and merging
the metadata ref from other people. But that's not really different from
notes. In either case, you're probably going to want to make a custom
merge program for combining the meta-information.
-Peff
^ permalink raw reply
* [PATCH] Add option hooks.diffopts to customize change summary in post-receive-email
From: Jon Jensen @ 2011-08-04 3:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vr552ba4e.fsf@alter.siamese.dyndns.org>
This makes it easy to customize the git diff-tree options, for example
to include -p to include inline diffs.
It defaults to the current options "--stat --summary --find-copies-harder"
and thus is backward-compatible.
Signed-off-by: Jon Jensen <jon@endpoint.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
---
Thanks for the suggestion, Junio. It makes a lot of sense.
Jon
contrib/hooks/post-receive-email | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 9c678e6..cd5664d 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -60,6 +60,11 @@
# email body. If not specified, there is no limit.
# Lines beyond the limit are suppressed and counted, and a final
# line is added indicating the number of suppressed lines.
+# hooks.diffopts
+# Alternate options for the git diff-tree invocation that shows changes.
+# Default is "--stat --summary --find-copies-harder". Add -p to those
+# options to include a unified diff of changes in addition to the usual
+# summary output.
#
# Notes
# -----
@@ -447,7 +452,7 @@ generate_update_branch_email()
# non-fast-forward updates.
echo ""
echo "Summary of changes:"
- git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
+ git diff-tree $diffopts $oldrev..$newrev
}
#
@@ -724,6 +729,8 @@ envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
custom_showrev=$(git config hooks.showrev)
maxlines=$(git config hooks.emailmaxlines)
+diffopts=$(git config hooks.diffopts)
+: ${diffopts:="--stat --summary --find-copies-harder"}
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.7.6.233.gd79bc
^ permalink raw reply related
* Re: [RFC 0/6] git-check-attr should work for relative paths
From: Michael Haggerty @ 2011-08-04 3:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrevcw12.fsf@alter.siamese.dyndns.org>
On 08/03/2011 12:02 AM, Junio C Hamano wrote:
> A minor compilation fix-up on top, to be squashed when the series is
> re-rolled. [...]
Thanks for catching this. I will include it in the re-roll. (The patch
series needs to be re-rolled anyway, since it depends on
mh/check-attr-listing, which is being improved based on your feedback.)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [RFC 4/6] git-check-attr: Normalize paths
From: Michael Haggerty @ 2011-08-04 3:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4o1zg20r.fsf@alter.siamese.dyndns.org>
On 08/02/2011 07:24 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> 1. I'm not sure whether it is correct to fix this problem at the level
>> of git-check-attr, or whether the fix belongs in the API layer.
>> What is the convention for API functions? Do they typically take
>> path names relative to the CWD or relative to the working tree
>> root, or ...?
>
> I think passing down "prefix" (i.e. where your $(cwd) was relative to the
> root level of the working tree) and the user-supplied "pathspec" (which
> typically is relative to that original $(cwd)) is the canonical approach.
> The very original git worked only at the root level of the working tree,
> with paths specified relative to the root level of the tree, so many code
> do:
>
> - find out the root of the working tree;
> - note where the $(cwd) was in "prefix";
> - chdir to the root of the working tree;
> - prepend the "prefix" to user supplied pathspec;
> - forget all the complexity and work on the whole tree.
>
> Then the "prefix" gets stripped away from the beginning of the paths when
> reporting.
>
> Your patch from a cursory look seems to follow that pattern, which is
> good.
Thanks for the explanation.
Yes, my code follows the pattern, except that in this case it is
unnecessary to chdir to the root of the working tree.
All this chdiring is going to be a nightmare for the libification of
git, since the cwd is a program-wide global variable with implicit
side-effects on almost any code that deals with the filesystem. It is
obviously not permissible for a library to change directories (not even
temporarily, if the library is intended to be used in a multithreaded
application). But that is a topic for another day.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2 19/19] Rename struct git_attr_check to git_attr_value
From: Michael Haggerty @ 2011-08-04 3:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjpjg6k7.fsf@alter.siamese.dyndns.org>
Thanks for the good feedback.
On 08/02/2011 05:46 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> This described its purpose better, especially when used with
>> git_allattrs().
>
> You probably meant s/described/describes/ but more importantly does it
> really? It is a structure used to probe into the attributes system for the
> state of various attributes on a path, and the set of possible states
> includes "there is no value" (aka unset), so it feels actively wrong to
> call it attr_value and that is why I didn't call it in the first place.
I don't think it is so unusual for a "value" object to be able to
reflect the fact that the value is unset, but I can understand your
point of view too. I will omit this renaming in the re-roll.
> I also think git_all_attrs() (i.e. word-break underscore after "all") is
> more in line with the naming throughout the codebase, after looking at
> output from
>
> $ git grep -e _all'[a-z]' --and --not -e alloc -e _all_ -- '*.c'
>
> Other than these, and the earlier comment about the copy&paste done from
> git_checkattr (which by the way should probably be "git_check_attr"), it
> seems that the series mostly consist of good clean-ups and an addition of
> a new and (probably) useful feature that is straightforward. Nice.
I thought the name was awkward, too, but I chose it to be consistent
with git_checkattr(). So in the re-roll I will happily rename both
functions.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2 09/19] Allow querying all attributes on a file
From: Michael Haggerty @ 2011-08-04 3:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrevg73x.fsf@alter.siamese.dyndns.org>
On 08/02/2011 05:34 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> Add a function, git_allattrs(), that reports on all attributes that
>> are set on a path.
>>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
>> Documentation/technical/api-gitattributes.txt | 45 +++++++++++++++++-------
>> attr.c | 43 +++++++++++++++++++++++
>> attr.h | 9 +++++
>> 3 files changed, 84 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt
>> index ab3a84d..640240e 100644
>> --- a/Documentation/technical/api-gitattributes.txt
>> +++ b/Documentation/technical/api-gitattributes.txt
>> @@ -22,19 +22,6 @@ Data Structure
>> ...
>> (JC)
>
> The last line, I think, can now be dropped. This was a marker saying "we
> lack documentation for this API; bug this person for necessary information
> and write one".
OK; I will drop the line in the re-roll.
>> diff --git a/attr.c b/attr.c
>> index bfa1f43..9c2fca8 100644
>> --- a/attr.c
>> +++ b/attr.c
>> @@ -737,6 +737,49 @@ int git_checkattr(const char *path, int num, struct git_attr_check *check)
>> return 0;
>> }
>>
>> +int git_allattrs(const char *path, int *num, struct git_attr_check **check)
>> +{
>> + struct attr_stack *stk;
>> + const char *cp;
>> + int dirlen, pathlen, i, rem, count, j;
>> +
>> + bootstrap_attr_stack();
>> + for (i = 0; i < attr_nr; i++)
>> + check_all_attr[i].value = ATTR__UNKNOWN;
>> +
>> + pathlen = strlen(path);
>> + cp = strrchr(path, '/');
>> + if (!cp)
>> + dirlen = 0;
>> + else
>> + dirlen = cp - path;
>> + prepare_attr_stack(path, dirlen);
>> + rem = attr_nr;
>> + for (stk = attr_stack; 0 < rem && stk; stk = stk->prev)
>> + rem = fill(path, pathlen, stk, rem);
>
> Shouldn't the above part at least should be refactored instead of copied
> and pasted from git_checkattr()?
Quite right. Will be fixed in re-roll.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re* BUG?: git diff with 3 args consults work tree when it shouldn't
From: Junio C Hamano @ 2011-08-04 2:54 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <201108011935.11373.johan@herland.net>
What happens is that the more-than-two-ways combined diff is sometimes
used to show the difference _to_ the working tree files.
In combine-diff.c::show_patch_diff(), we try to detect that case by
checking if sha1 recorded as "the result" is null, because diff-files will
give us 0{40} as the blob object name for files in the working tree.
Unfortunately, that forgets another case where blob object is null, which
is when the merge result tree _deleted_ the path.
This patch is not tested outside your test case. IOW, I know it will get
three-tree case correctly, but I didn't test it with cases where we should
look at the working tree files, so this may introduce regressions.
See 713a11f (combine-diff: diff-files fix., 2006-02-13) if you are
interested. I suspect that we may need to add a bit to the API to tell
this function if the end result is in the working tree.
combine-diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index be67cfc..b4f1050 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -777,7 +777,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
struct sline *sline; /* survived lines */
int mode_differs = 0;
int i, show_hunks;
- int working_tree_file = is_null_sha1(elem->sha1);
+ int working_tree_file = is_null_sha1(elem->sha1) && elem->mode;
mmfile_t result_file;
struct userdiff_driver *userdiff;
struct userdiff_driver *textconv = NULL;
^ permalink raw reply related
* Re: git-archive's wrong documentation: really write pax rather than tar
From: Jeff King @ 2011-08-04 2:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Hin-Tak Leung, git, rene.scharfe
In-Reply-To: <7vwret6hgj.fsf@alter.siamese.dyndns.org>
On Wed, Aug 03, 2011 at 07:25:32PM -0700, Junio C Hamano wrote:
> > Actually, it is relevant for zip, too. The option should really be
> > called "--no-commit-id" or something similar. I don't think it's as big
> > a deal with zip (because there is no compatibility issue), but you may
> > want to omit the header for other reasons (e.g., because you know it
> > doesn't point to a commit that is public).
>
> Hmm, perhaps. It indeed is an implementation detail of the tar backend
> that the commit object name is stored in pax header, so --no-commit-id
> might make sense from "git" point of view, but from the point of view of
> OP that started this thread, he wouldn't care what that extra information
> is --- it can be a commit object name or it can be phase of the moon when
> the archive was made --- he just wants the extra header dropped.
>
> So I dunno.
If the intent of the option is "write plain-vanilla ustar" (I really
hope it doesn't need to be "plain-vanilla 4.3BSD tar"), then I think we
would do better to have a new --format type. Because from the OP's
perspective, it's not "drop this header that I don't like" but "make
something compatible with older versions of tar".
-Peff
^ permalink raw reply
* Re: git-archive's wrong documentation: really write pax rather than tar
From: Junio C Hamano @ 2011-08-04 2:25 UTC (permalink / raw)
To: Jeff King; +Cc: Hin-Tak Leung, git, rene.scharfe
In-Reply-To: <20110804020054.GA1947@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Aug 03, 2011 at 06:56:41PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > It might be a bit more obvious to find if we actually had a
>> > --no-pax-header option, though.
>>
>> Yeah, we would need to make sure that --no-pack-header causes a barf
>> for other backends, though. "struct archiver_args" right now seems to have
>> compression_level but I think it should just have "const char **" that is
>> interpreted by backends.
>
> Actually, it is relevant for zip, too. The option should really be
> called "--no-commit-id" or something similar. I don't think it's as big
> a deal with zip (because there is no compatibility issue), but you may
> want to omit the header for other reasons (e.g., because you know it
> doesn't point to a commit that is public).
Hmm, perhaps. It indeed is an implementation detail of the tar backend
that the commit object name is stored in pax header, so --no-commit-id
might make sense from "git" point of view, but from the point of view of
OP that started this thread, he wouldn't care what that extra information
is --- it can be a commit object name or it can be phase of the moon when
the archive was made --- he just wants the extra header dropped.
So I dunno.
^ permalink raw reply
* Re: git-archive's wrong documentation: really write pax rather than tar
From: Jeff King @ 2011-08-04 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Hin-Tak Leung, git, rene.scharfe
In-Reply-To: <20110804014143.GA32579@sigill.intra.peff.net>
On Wed, Aug 03, 2011 at 07:41:43PM -0600, Jeff King wrote:
> Look for the example mentioning "pax header" here:
>
> http://www.kernel.org/pub/software/scm/git/docs/git-archive.html
BTW, I noticed while looking at this that the HTML versions of the
examples are quite hard to read, as they are formatted in a
proportional-width font. I never noticed because I always just read the
roff-formatted manpages in a monospaced-terminal. We should probably do
this:
-- >8 --
Subject: docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
---
I found all of these with:
git grep :: Documentation/*.txt | grep 'git '
and then marked up only the examples by hand. Most of the other matches
were fine as-is (i.e., they weren't meant to be code examples). There
was one common type of hit that I didn't convert, but maybe could be,
though. Some of the commands with multiple modes of operation (e.g.,
checkout, diff) use lists like:
'git diff' [--options] -- [<path>]::
...
'git diff' [--options] --cached [<commit>] [--] [<path>...]::
etc. Those could arguably be monospaced, as well.
I suspect we could replace some invocations of {carat} and other
punctuation inside the newly-backticked text, but it doesn't hurt to
leave it as-is. And I'm paranoid that even if it works on my setup, some
other version of asciidoc will mangle it.
Documentation/git-archive.txt | 16 ++++++++--------
Documentation/git-cherry-pick.txt | 14 +++++++-------
Documentation/git-grep.txt | 6 +++---
Documentation/git-gui.txt | 16 ++++++++--------
Documentation/git-log.txt | 16 ++++++++--------
Documentation/git-merge-file.txt | 4 ++--
Documentation/git-push.txt | 20 ++++++++++----------
Documentation/git-remote-fd.txt | 8 ++++----
Documentation/git-revert.txt | 4 ++--
Documentation/git-rm.txt | 4 ++--
Documentation/git-show.txt | 10 +++++-----
Documentation/git-tar-tree.txt | 10 +++++-----
Documentation/git-whatchanged.txt | 4 ++--
13 files changed, 66 insertions(+), 66 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 1320c87..ac7006e 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -142,41 +142,41 @@ while archiving any tree in your `$GIT_DIR/info/attributes` file.
EXAMPLES
--------
-git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
+`git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)`::
Create a tar archive that contains the contents of the
latest commit on the current branch, and extract it in the
`/var/tmp/junk` directory.
-git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz::
+`git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz`::
Create a compressed tarball for v1.4.0 release.
-git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz::
+`git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz`::
Same as above, but using the builtin tar.gz handling.
-git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0::
+`git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0`::
Same as above, but the format is inferred from the output file.
-git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz::
+`git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz`::
Create a compressed tarball for v1.4.0 release, but without a
global extended pax header.
-git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip::
+`git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip`::
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
-git archive -o latest.zip HEAD::
+`git archive -o latest.zip HEAD`::
Create a Zip archive that contains the contents of the latest
commit on the current branch. Note that the output format is
inferred by the extension of the output file.
-git config tar.tar.xz.command "xz -c"::
+`git config tar.tar.xz.command "xz -c"`::
Configure a "tar.xz" format for making LZMA-compressed tarfiles.
You can use it specifying `--format=tar.xz`, or by creating an
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 6c9c2cb..7cfa3d9 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -112,31 +112,31 @@ effect to your index in a row.
EXAMPLES
--------
-git cherry-pick master::
+`git cherry-pick master`::
Apply the change introduced by the commit at the tip of the
master branch and create a new commit with this change.
-git cherry-pick ..master::
-git cherry-pick ^HEAD master::
+`git cherry-pick ..master`::
+`git cherry-pick ^HEAD master`::
Apply the changes introduced by all commits that are ancestors
of master but not of HEAD to produce new commits.
-git cherry-pick master{tilde}4 master{tilde}2::
+`git cherry-pick master{tilde}4 master{tilde}2`::
Apply the changes introduced by the fifth and third last
commits pointed to by master and create 2 new commits with
these changes.
-git cherry-pick -n master~1 next::
+`git cherry-pick -n master~1 next`::
Apply to the working tree and the index the changes introduced
by the second last commit pointed to by master and by the last
commit pointed to by next, but do not create any commit with
these changes.
-git cherry-pick --ff ..next::
+`git cherry-pick --ff ..next`::
If history is linear and HEAD is an ancestor of next, update
the working tree and advance the HEAD pointer to match next.
@@ -144,7 +144,7 @@ git cherry-pick --ff ..next::
are in next but not HEAD to the current branch, creating a new
commit for each new change.
-git rev-list --reverse master \-- README | git cherry-pick -n --stdin::
+`git rev-list --reverse master \-- README | git cherry-pick -n --stdin`::
Apply the changes introduced by all commits on the master
branch that touched README to the working tree and index,
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 07b3c6a..0627111 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -215,15 +215,15 @@ OPTIONS
Examples
--------
-git grep {apostrophe}time_t{apostrophe} \-- {apostrophe}*.[ch]{apostrophe}::
+`git grep {apostrophe}time_t{apostrophe} \-- {apostrophe}*.[ch]{apostrophe}`::
Looks for `time_t` in all tracked .c and .h files in the working
directory and its subdirectories.
-git grep -e {apostrophe}#define{apostrophe} --and \( -e MAX_PATH -e PATH_MAX \)::
+`git grep -e {apostrophe}#define{apostrophe} --and \( -e MAX_PATH -e PATH_MAX \)`::
Looks for a line that has `#define` and either `MAX_PATH` or
`PATH_MAX`.
-git grep --all-match -e NODE -e Unexpected::
+`git grep --all-match -e NODE -e Unexpected`::
Looks for a line that has `NODE` or `Unexpected` in
files that have lines that match both.
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index 18f713b..0041994 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
@@ -50,7 +50,7 @@ version::
Examples
--------
-git gui blame Makefile::
+`git gui blame Makefile`::
Show the contents of the file 'Makefile' in the current
working directory, and provide annotations for both the
@@ -59,41 +59,41 @@ git gui blame Makefile::
uncommitted changes (if any) are explicitly attributed to
'Not Yet Committed'.
-git gui blame v0.99.8 Makefile::
+`git gui blame v0.99.8 Makefile`::
Show the contents of 'Makefile' in revision 'v0.99.8'
and provide annotations for each line. Unlike the above
example the file is read from the object database and not
the working directory.
-git gui blame --line=100 Makefile::
+`git gui blame --line=100 Makefile`::
Loads annotations as described above and automatically
scrolls the view to center on line '100'.
-git gui citool::
+`git gui citool`::
Make one commit and return to the shell when it is complete.
This command returns a non-zero exit code if the window was
closed in any way other than by making a commit.
-git gui citool --amend::
+`git gui citool --amend`::
Automatically enter the 'Amend Last Commit' mode of
the interface.
-git gui citool --nocommit::
+`git gui citool --nocommit`::
Behave as normal citool, but instead of making a commit
simply terminate with a zero exit code. It still checks
that the index does not contain any unmerged entries, so
you can use it as a GUI version of linkgit:git-mergetool[1]
-git citool::
+`git citool`::
Same as `git gui citool` (above).
-git gui browser maint::
+`git gui browser maint`::
Show a browser for the tree of the 'maint' branch. Files
selected in the browser can be viewed with the internal
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 59f8be0..6c93466 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -88,45 +88,45 @@ include::diff-generate-patch.txt[]
Examples
--------
-git log --no-merges::
+`git log --no-merges`::
Show the whole commit history, but skip any merges
-git log v2.6.12.. include/scsi drivers/scsi::
+`git log v2.6.12.. include/scsi drivers/scsi`::
Show all commits since version 'v2.6.12' that changed any file
in the include/scsi or drivers/scsi subdirectories
-git log --since="2 weeks ago" \-- gitk::
+`git log --since="2 weeks ago" \-- gitk`::
Show the changes during the last two weeks to the file 'gitk'.
The "--" is necessary to avoid confusion with the *branch* named
'gitk'
-git log --name-status release..test::
+`git log --name-status release..test`::
Show the commits that are in the "test" branch but not yet
in the "release" branch, along with the list of paths
each commit modifies.
-git log --follow builtin-rev-list.c::
+`git log --follow builtin-rev-list.c`::
Shows the commits that changed builtin-rev-list.c, including
those commits that occurred before the file was given its
present name.
-git log --branches --not --remotes=origin::
+`git log --branches --not --remotes=origin`::
Shows all commits that are in any of local branches but not in
any of remote-tracking branches for 'origin' (what you have that
origin doesn't).
-git log master --not --remotes=*/master::
+`git log master --not --remotes=*/master`::
Shows all commits that are in local master but not in any remote
repository master branches.
-git log -p -m --first-parent::
+`git log -p -m --first-parent`::
Shows the history including change diffs, but only from the
"main branch" perspective, skipping commits that come from merged
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
index 635c669..d7db2a3 100644
--- a/Documentation/git-merge-file.txt
+++ b/Documentation/git-merge-file.txt
@@ -76,12 +76,12 @@ OPTIONS
EXAMPLES
--------
-git merge-file README.my README README.upstream::
+`git merge-file README.my README README.upstream`::
combines the changes of README.my and README.upstream since README,
tries to merge them and writes the result into README.my.
-git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345::
+`git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345`::
merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
`a` and `c` instead of `tmp/a123` and `tmp/c345`.
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 88acfcd..49c6e9f 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -327,12 +327,12 @@ a case where you do mean to lose history.
Examples
--------
-git push::
+`git push`::
Works like `git push <remote>`, where <remote> is the
current branch's remote (or `origin`, if no remote is
configured for the current branch).
-git push origin::
+`git push origin`::
Without additional configuration, works like
`git push origin :`.
+
@@ -344,45 +344,45 @@ use `git config remote.origin.push HEAD`. Any valid <refspec> (like
the ones in the examples below) can be configured as the default for
`git push origin`.
-git push origin :::
+`git push origin :`::
Push "matching" branches to `origin`. See
<refspec> in the <<OPTIONS,OPTIONS>> section above for a
description of "matching" branches.
-git push origin master::
+`git push origin master`::
Find a ref that matches `master` in the source repository
(most likely, it would find `refs/heads/master`), and update
the same ref (e.g. `refs/heads/master`) in `origin` repository
with it. If `master` did not exist remotely, it would be
created.
-git push origin HEAD::
+`git push origin HEAD`::
A handy way to push the current branch to the same name on the
remote.
-git push origin master:satellite/master dev:satellite/dev::
+`git push origin master:satellite/master dev:satellite/dev`::
Use the source ref that matches `master` (e.g. `refs/heads/master`)
to update the ref that matches `satellite/master` (most probably
`refs/remotes/satellite/master`) in the `origin` repository, then
do the same for `dev` and `satellite/dev`.
-git push origin HEAD:master::
+`git push origin HEAD:master`::
Push the current branch to the remote ref matching `master` in the
`origin` repository. This form is convenient to push the current
branch without thinking about its local name.
-git push origin master:refs/heads/experimental::
+`git push origin master:refs/heads/experimental`::
Create the branch `experimental` in the `origin` repository
by copying the current `master` branch. This form is only
needed to create a new branch or tag in the remote repository when
the local name and the remote name are different; otherwise,
the ref name on its own will work.
-git push origin :experimental::
+`git push origin :experimental`::
Find a ref that matches `experimental` in the `origin` repository
(e.g. `refs/heads/experimental`), and delete it.
-git push origin {plus}dev:master::
+`git push origin {plus}dev:master`::
Update the origin repository's master branch with the dev branch,
allowing non-fast-forward updates. *This can leave unreferenced
commits dangling in the origin repository.* Consider the
diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt
index 4aecd4d..f095d57 100644
--- a/Documentation/git-remote-fd.txt
+++ b/Documentation/git-remote-fd.txt
@@ -35,19 +35,19 @@ GIT_TRANSLOOP_DEBUG::
EXAMPLES
--------
-git fetch fd::17 master::
+`git fetch fd::17 master`::
Fetch master, using file descriptor #17 to communicate with
git-upload-pack.
-git fetch fd::17/foo master::
+`git fetch fd::17/foo master`::
Same as above.
-git push fd::7,8 master (as URL)::
+`git push fd::7,8 master (as URL)`::
Push master, using file descriptor #7 to read data from
git-receive-pack and file descriptor #8 to write data to
same service.
-git push fd::7,8/bar master::
+`git push fd::7,8/bar master`::
Same as above.
Documentation
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 3d0a7d1..b311d59 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -93,12 +93,12 @@ effect to your index in a row.
EXAMPLES
--------
-git revert HEAD~3::
+`git revert HEAD~3`::
Revert the changes specified by the fourth last commit in HEAD
and create a new commit with the reverted changes.
-git revert -n master{tilde}5..master{tilde}2::
+`git revert -n master{tilde}5..master{tilde}2`::
Revert the changes done by commits from the fifth last commit
in master (included) to the third last commit in master
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index da0215d..665ad4d 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -137,7 +137,7 @@ git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
EXAMPLES
--------
-git rm Documentation/\*.txt::
+`git rm Documentation/\*.txt`::
Removes all `*.txt` files from the index that are under the
`Documentation` directory and any of its subdirectories.
+
@@ -145,7 +145,7 @@ Note that the asterisk `*` is quoted from the shell in this
example; this lets git, and not the shell, expand the pathnames
of files and subdirectories under the `Documentation/` directory.
-git rm -f git-*.sh::
+`git rm -f git-*.sh`::
Because this example lets the shell expand the asterisk
(i.e. you are listing the files explicitly), it
does not remove `subdir/git-foo.sh`.
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 1f0e30b..1e38819 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -48,23 +48,23 @@ include::pretty-formats.txt[]
EXAMPLES
--------
-git show v1.0.0::
+`git show v1.0.0`::
Shows the tag `v1.0.0`, along with the object the tags
points at.
-git show v1.0.0^\{tree\}::
+`git show v1.0.0^\{tree\}`::
Shows the tree pointed to by the tag `v1.0.0`.
-git show -s --format=%s v1.0.0^\{commit\}::
+`git show -s --format=%s v1.0.0^\{commit\}`::
Shows the subject of the commit pointed to by the
tag `v1.0.0`.
-git show next~10:Documentation/README::
+`git show next~10:Documentation/README`::
Shows the contents of the file `Documentation/README` as
they were current in the 10th last commit of the branch
`next`.
-git show master:Makefile master:t/Makefile::
+`git show master:Makefile master:t/Makefile`::
Concatenates the contents of said Makefiles in the head
of the branch `master`.
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 95b135d..346e7a2 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -53,26 +53,26 @@ tar.umask::
EXAMPLES
--------
-git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)::
+`git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)`::
Create a tar archive that contains the contents of the
latest commit on the current branch, and extracts it in
`/var/tmp/junk` directory.
-git tar-tree v1.4.0 git-1.4.0 | gzip >git-1.4.0.tar.gz::
+`git tar-tree v1.4.0 git-1.4.0 | gzip >git-1.4.0.tar.gz`::
Create a tarball for v1.4.0 release.
-git tar-tree v1.4.0{caret}\{tree\} git-1.4.0 | gzip >git-1.4.0.tar.gz::
+`git tar-tree v1.4.0{caret}\{tree\} git-1.4.0 | gzip >git-1.4.0.tar.gz`::
Create a tarball for v1.4.0 release, but without a
global extended pax header.
-git tar-tree --remote=example.com:git.git v1.4.0 >git-1.4.0.tar::
+`git tar-tree --remote=example.com:git.git v1.4.0 >git-1.4.0.tar`::
Get a tarball v1.4.0 from example.com.
-git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar::
+`git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar`::
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.tar', with the prefix 'git-docs/'.
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
index 99388bd..76c7f7e 100644
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -53,12 +53,12 @@ include::pretty-formats.txt[]
Examples
--------
-git whatchanged -p v2.6.12.. include/scsi drivers/scsi::
+`git whatchanged -p v2.6.12.. include/scsi drivers/scsi`::
Show as patches the commits since version 'v2.6.12' that changed
any file in the include/scsi or drivers/scsi subdirectories
-git whatchanged --since="2 weeks ago" \-- gitk::
+`git whatchanged --since="2 weeks ago" \-- gitk`::
Show the changes during the last two weeks to the file 'gitk'.
The "--" is necessary to avoid confusion with the *branch* named
^ permalink raw reply related
* Re: [PATCH 00/48] Handling more corner cases in merge-recursive.c
From: Elijah Newren @ 2011-08-04 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jgfouca
In-Reply-To: <7vaabq6j6g.fsf@alter.siamese.dyndns.org>
On Wed, Aug 3, 2011 at 7:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> A very simple reproduction recipe.
Thanks, I'll take a look this weekend. I'm a little surprised that
you mentioned merging this to next already; I was assuming you wanted
me to address the various things you pointed out in your reviews first
(as well as the comments from Johannes). I've been swamped at work,
particularly after trying to catch up on the pile of work accumulated
during my vacation, but should have time again this weekend...finally.
Elijah
^ permalink raw reply
* Re: Why isn't there a hook for all operations that update the working tree?
From: Junio C Hamano @ 2011-08-04 2:06 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
In-Reply-To: <CACBZZX7dJhGT0H8JZRbQ_t9mNnJocaktYAXgMSihfLBuFmL3nw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> ... Is there any
> reason beside omission that there isn't a post-reset hook?
> Or hooks for any other thing ...
In principle, we historically tended to avoid hooks unless absolutely
necessary. Even having to check to find out no hook needs to be run is
considered wasted cycles.
http://thread.gmane.org/gmane.comp.version-control.git/79314/focus=79321
I'd especially rather not to see a hook on something as low level as
"reset". It would be too tempting to use "reset" itself inside a hook that
is run from the post-reset hook, and I do not want to complicate the code
even further to give callers to ask disabling the hook.
^ 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