* [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 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 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 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
* 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
* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-22 20:58 UTC (permalink / raw)
To: Jay Soffian; +Cc: Michael Haggerty, Junio C Hamano, git discussion list
In-Reply-To: <CAG+J_DxdP2qHhttJOtWQTKeiDV2YbC_A_F+b9sDOZsWhWxjcjw@mail.gmail.com>
On Thu, Sep 22, 2011 at 02:41:42PM -0400, Jay Soffian wrote:
> attr.c says:
>
> a. built-in attributes
> b. $(prefix)/etc/gitattributes unless GIT_ATTR_NOSYSTEM is set
> c. core.attributesfile
> d. per-directory .gitattributes
> e. $GIT_DIR/info/attributes
>
> The mechanics of (d) are established by git_attr_direction:
>
> GIT_ATTR_CHECKIN: working-copy, then index
> GIT_ATTR_CHECKOUT: index, then working-copy
> GIT_ATTR_INDEX: index-only
Thanks for hunting it down. I had been thinking that "attributes from
tree" would come either before or after (d) above, but the concept
really fits better into the second list (i.e., they're per-directory
attributes, it's just a matter of which set of directories).
> Where GIT_ATTR_CHECKIN is the default direction and GIT_ATTR_CHECKOUT
> is used while checking-out files from the index. (GIT_ATTR_INDEX is
> used only by git-archive.)
Hrm. But git archive works correctly in a bare repo with no index at
all. It looks like we just populate an in-core index and feed that to
git_attr_set_direction. Which is a bit suboptimal for something like
diff, which might not need to look at all parts of the tree (I guess it
is similarly suboptimal for archive with pathspecs).
But still, those are just performance considerations. We could use the
same trick for diff/log in a bare repo. I guess we'd end up refreshing
the index from each commit in a multi-commit log, which might be
noticeably slow.
> Consistent with that, when comparing two commits (diff-tree), I think
> you look at the .gitattributes in the second commit.
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".
However, I think this is skirting around a somewhat larger issue, which
is that gitattributes are sometimes about "this is what the file is like
at the current state of history", and sometimes about "this is what this
file is like throughout history".
For example, imagine I've got a repository of binary files. At some
point, I decide to use gitattributes to configure a textconv filter. In
my non-bare repo, when I do "git log" I get nice textconv'd diffs going
back through all of history. But if I push to a bare repo and try to do
a "git log" there, my attributes are ignored. So in this case, I like
that the working tree's attributes are applied retroactively, and I'd
like the bare repo to do the same.
Now consider a different example. I have a repo with a script "foo" that
contains perl code, and I add .gitattributes marking it as such (for
func headers, or maybe I have a magic external diff, or whatever[1]).
Later, I decide that I hate perl and rewrite it in python, updating
gitattributes. Now I _don't_ want the retroactive behavior. When I do a
"git log -p", I want to see the old commits with the perl script shown
using the perl attribute, not the python. But what the heck would it
mean to diff a recent python commit against an old perl one?
Even though we think of the diff attributes as "here's how you diff",
they are really "here are some annotations about the end points". So for
something like a textconv, you care about the attributes of _both_
sides of a diff, applying the attributes of the "from" tree to the paths
in that tree. Something like funcname is harder. I guess you'd probably
want to use the attributes from the "from" tree, since it is about
reporting context from the "from" side.
So the semantics really end up depending on the particular attribute.
Something like "-delta" exists more outside the history or the state of
a particular commit.
So I think doing it "right" would be a lot more complicated than just
reading the commits from a particular tree. I think it would mean adding
more context to all attribute lookups, and having each caller decide how
the results should be used.
However, retroactively applying attributes from the working tree, even
though it is sometimes wrong (e.g., we get the perl/python thing wrong
_now_ if you have a working tree), is often convenient in practice
(because otherwise you end up duplicating your per-directory
gitattributes in your info/attributes file), and rarely is it actually
wrong (because changing the type of a file without changing its path
isn't all that common).
So if the status quo with working trees (i.e., retroactively applying
the current gitattributes to past commits) is good enough, perhaps the
bare-repository solution should be modeled the same way? In other words,
should "git log -p" in a bare repo be looking for attributes not in the
commits being diffed, but rather in HEAD[2]?
That at least would make it consistent with the non-bare behavior. And
then if we want to move forward with making particular attributes more
aware of their context, we can do it in _both_ the bare and non-bare
cases.
-Peff
[1] The perl/python thing is probably not a huge deal, as funcnames are
the most likely thing to configure. But you can imagine it would be
much worse if some binary file changes formats, and you were using
textconv. Or something with word-diff, perhaps.
[2] You can almost do this with:
git show HEAD:.gitattributes >info/attributes
git show commit-you-care-about
rm info/attributes
except that it won't handle any per-directory attributes files from
subdirectories. So I think you'd want a "--attributes-from=HEAD"
diff option or something similar.
^ permalink raw reply
* Re: [PATCH v2 1/2] sparse checkout: show error messages when worktree shaping fails
From: Joshua Jensen @ 2011-09-22 19:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Michael J Gruber
In-Reply-To: <1316690663-29382-1-git-send-email-pclouds@gmail.com>
----- Original Message -----
From: Nguyễn Thái Ngọc Duy
Date: 9/22/2011 5:24 AM
> diff --git a/unpack-trees.c b/unpack-trees.c
> index cc616c3..fcf40a0 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1089,6 +1089,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
> */
> mark_new_skip_worktree(o->el,&o->result, CE_ADDED, CE_SKIP_WORKTREE | CE_NEW_SKIP_WORKTREE);
>
> + ret = 0;
> for (i = 0; i< o->result.cache_nr; i++) {
> struct cache_entry *ce = o->result.cache[i];
>
> @@ -1101,17 +1102,23 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
> * correct CE_NEW_SKIP_WORKTREE
> */
> if (ce->ce_flags& CE_ADDED&&
> - verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o))
> - return -1;
> + verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o)) {
> + if (!o->show_all_errors)
> + goto return_failed;
> + ret = -1;
> + }
>
> if (apply_sparse_checkout(ce, o)) {
> + if (!o->show_all_errors)
> + goto return_failed;
> ret = -1;
> - goto done;
> }
> if (!ce_skip_worktree(ce))
> empty_worktree = 0;
>
> }
> + if (ret< 0)
> + goto return_failed;
> if (o->result.cache_nr&& empty_worktree) {
> /* dubious---why should this fail??? */
> ret = unpack_failed(o, "Sparse checkout leaves no entry on working directory");
I can confirm that this version of the patch works for me with multiple
untracked files in a sparse checkout.
-Josh
^ permalink raw reply
* [PATCH 2/2] fast-import: don't allow to note on empty branch
From: Dmitry Ivankov @ 2011-09-22 19:47 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316720825-32552-1-git-send-email-divanorama@gmail.com>
'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.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 2 ++
t/t9300-fast-import.sh | 17 +++++++++++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index c44cc11..a8a3ad1 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2416,6 +2416,8 @@ static void note_change_n(struct branch *b, unsigned char old_fanout)
/* <committish> */
s = lookup_branch(p);
if (s) {
+ if (is_null_sha1(s->sha1))
+ die("Can't add a note on empty branch.");
hashcpy(commit_sha1, s->sha1);
} else if (*p == ':') {
uintmax_t commit_mark = strtoumax(p + 1, NULL, 10);
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 0b97d7a..bd32b91 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1987,6 +1987,23 @@ test_expect_success \
'Q: verify second note for second commit' \
'git cat-file blob refs/notes/foobar:$commit2 >actual && test_cmp expect actual'
+cat >input <<EOF
+reset refs/heads/Q0
+
+commit refs/heads/note-Q0
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+Note for an empty branch.
+COMMIT
+
+N inline refs/heads/Q0
+data <<NOTE
+some note
+NOTE
+EOF
+test_expect_success \
+ 'Q: deny note on empty branch' \
+ 'test_must_fail git fast-import <input'
###
### series R (feature and option)
###
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] fast-import: don't allow to tag empty branch
From: Dmitry Ivankov @ 2011-09-22 19:47 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
In-Reply-To: <1316720825-32552-1-git-send-email-divanorama@gmail.com>
'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.
Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
---
fast-import.c | 2 ++
t/t9300-fast-import.sh | 12 ++++++++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 742e7da..c44cc11 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2717,6 +2717,8 @@ static void parse_new_tag(void)
from = strchr(command_buf.buf, ' ') + 1;
s = lookup_branch(from);
if (s) {
+ if (is_null_sha1(s->sha1))
+ die("Can't tag an empty branch.");
hashcpy(sha1, s->sha1);
type = OBJ_COMMIT;
} else if (*from == ':') {
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 1a6c066..0b97d7a 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -820,6 +820,18 @@ test_expect_success \
'test 1 = `git rev-list J | wc -l` &&
test 0 = `git ls-tree J | wc -l`'
+cat >input <<INPUT_END
+reset refs/heads/J2
+
+tag wrong_tag
+from refs/heads/J2
+data <<EOF
+Tag branch that was reset.
+EOF
+INPUT_END
+test_expect_success \
+ 'J: tag must fail on empty branch' \
+ 'test_must_fail git fast-import <input'
###
### series K
###
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/2] fast-import: empty/reset branch bugs
From: Dmitry Ivankov @ 2011-09-22 19:47 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Shawn O. Pearce, David Barr, Sverre Rabbelier,
Dmitry Ivankov
fast-import uses null_sha1 for empty branches. It doesn't make a
null_sha1 parent nor writes out a branch with null_sha1 head. But
for notemodify and tag commands there is no check for null_sha1
and so bad tag/notes are produced instead of a error message.
Dmitry Ivankov (2):
fast-import: don't allow to tag empty branch
fast-import: don't allow to note on empty branch
fast-import.c | 4 ++++
t/t9300-fast-import.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 0 deletions(-)
--
1.7.3.4
^ permalink raw reply
* Re: any way to "re-sync" a bare repository against another bare repository?
From: Chris Friesen @ 2011-09-22 19:23 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <7142366f54c44cea82542adf8aea5bb9-mfwitten@gmail.com>
Thanks for that very thorough response.
The rationale for this is somewhat convoluted...I have a vendor-supplied
build system that expects to be pointed at a bare repository. For
performance reasons I want to have a local bare repo on each build
machine that can be kept in sync with a master repo on a main server.
Chris
On 09/22/2011 12:50 PM, Michael Witten wrote:
> On Thu, 22 Sep 2011 11:22:37 -0600, Chris Friesen wrote:
>
>> Suppose I have a parent bare repository. I do a "git clone --bare" to
>> create a child repository, and then clone the child to create a
>> grandchild repository.
>
> Firstly, what exactly is the scenario you are trying to achieve? Perhaps
> there is a better way to do what you are trying to do.
>
>> If changes get pushed into the parent repository, is there any way to
>> cause the child to be updated?
>
> The documentation answers your question (but badly, as with much of the
> documentation); from `git help clone':
>
> --bare
> Make a bare GIT repository. That is, instead of creating
> <directory> and placing the administrative files in
> <directory>/.git, make the<directory> itself the $GIT_DIR.
> This obviously implies the -n because there is nowhere to
> check out the working tree. Also the branch heads at the
> remote are copied directly to corresponding local branch
> heads, without mapping them to refs/remotes/origin/. When
> this option is used, neither remote-tracking branches nor
> the related configuration variables are created.
>
> In particular:
>
> Also the branch heads at the
> remote are copied directly to corresponding local branch
> heads, without mapping them to refs/remotes/origin/. When
> this option is used, neither remote-tracking branches nor
> the related configuration variables are created.
>
> In particular:
>
> When
> this option is used, neither remote-tracking branches nor
> the related configuration variables are created.
>
> Thus, you have to explicitly tell git what you fetched and which
> branch heads should be updated.
>
> Consider this:
>
> $ git init parent
> $ git clone parent child0
> $ git clone --bare parent child1
>
> Now, look at the config file for the child0 repository:
>
> $ cat child0/.git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = /path/to/parent
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> In particular:
>
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> That is the default `refspec'; when `git fetch' is not explicitly
> told on the command line what to fetch and which branch head[s] to
> update, then this refspec is used as a default.
>
> Now, look at the config file for the child1 repository:
>
> $ cat child1/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = true
> [remote "origin"]
> url = /path/to/parent
>
> In particular, note that a bare repository doesn't include any
> such default information for `git fetch'. However, you could be
> explicit about it; from within the chidl1 repo:
>
> $ git fetch origin '+refs/heads/*:refs/remotes/origin/*'
>
>> Just a "git fetch<parent>" doesn't seem to help. If I set up parent as
>> a remote branch I can fetch it,
>
> Firstly, it doesn't make any sense to say "set up parent as a remote
> branch"; what you mean is "set up `<parent>' as a remote with a default
> refspec that creates any associated remote-tracking branch heads".
>
> Secondly, by setting up `<parent>' as a remote, you are creating the
> missing refspec in your config file:
>
> [remote "<parent>"]
> url = /path/to/parent
> fetch = +refs/heads/*:refs/remotes/<parent>/*
>
> which is why you get this:
>
>> but then it shows all the branches as "<parent>/<branch>" rather
>> than updating the child.
>
> You need a different refspec, namely:
>
> +refs/heads/*:refs/heads/*
>
> So, either be explicit:
>
> git fetch '<parent>' '+refs/heads/*:refs/heads/*'
>
> or update your config:
>
> git config 'remote.<parent>.fetch' '+refs/heads/*:refs/heads/*'
>
> Of course, there is an easier way that does all of this [and more]
> for you:
>
>> I just tried a "git clone --mirror" to create the child and it seems to
>> allow me to pick up changes in the parent via "git fetch". Is that the
>> proper way to handle this?
>
> The documentation answers your question (but badly, as with much of the
> documentation); from `git help clone':
>
> --mirror
> Set up a mirror of the source repository. This implies
> --bare. Compared to --bare, --mirror not only maps local
> branches of the source to local branches of the target, it
> maps all refs (including remote-tracking branches, notes
> etc.) and sets up a refspec configuration such that all
> these refs are overwritten by a git remote update in the
> target repository.
>
> In particular:
>
> sets up a refspec configuration such that all
> these refs are overwritten by a git remote update in the
> target repository.
>
> Consider this:
>
> $ git clone --mirror parent child2
> $ cat child2/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = true
> [remote "origin"]
> fetch = +refs/*:refs/*
> mirror = true
> url = /path/to/parent
>
> In particular:
>
> fetch = +refs/*:refs/*
>
> That's a very liberal refspec! It basically says that fetch
> should mirror everything by default.
>
> Sincerely,
> Michael Witten
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Junio C Hamano @ 2011-09-22 19:22 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Michael Haggerty, git discussion list
In-Reply-To: <CAG+J_DxdP2qHhttJOtWQTKeiDV2YbC_A_F+b9sDOZsWhWxjcjw@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Consistent with that, when comparing two commits (diff-tree), I think
> you look at the .gitattributes in the second commit.
That would make "diff A B" and "diff -R B A" behave differently.
^ permalink raw reply
* Re: any way to "re-sync" a bare repository against another bare repository?
From: Michael Witten @ 2011-09-22 18:50 UTC (permalink / raw)
To: Chris Friesen; +Cc: git
In-Reply-To: <4E7B6EDD.1040106@genband.com>
On Thu, 22 Sep 2011 11:22:37 -0600, Chris Friesen wrote:
> Suppose I have a parent bare repository. I do a "git clone --bare" to
> create a child repository, and then clone the child to create a
> grandchild repository.
Firstly, what exactly is the scenario you are trying to achieve? Perhaps
there is a better way to do what you are trying to do.
> If changes get pushed into the parent repository, is there any way to
> cause the child to be updated?
The documentation answers your question (but badly, as with much of the
documentation); from `git help clone':
--bare
Make a bare GIT repository. That is, instead of creating
<directory> and placing the administrative files in
<directory>/.git, make the <directory> itself the $GIT_DIR.
This obviously implies the -n because there is nowhere to
check out the working tree. Also the branch heads at the
remote are copied directly to corresponding local branch
heads, without mapping them to refs/remotes/origin/. When
this option is used, neither remote-tracking branches nor
the related configuration variables are created.
In particular:
Also the branch heads at the
remote are copied directly to corresponding local branch
heads, without mapping them to refs/remotes/origin/. When
this option is used, neither remote-tracking branches nor
the related configuration variables are created.
In particular:
When
this option is used, neither remote-tracking branches nor
the related configuration variables are created.
Thus, you have to explicitly tell git what you fetched and which
branch heads should be updated.
Consider this:
$ git init parent
$ git clone parent child0
$ git clone --bare parent child1
Now, look at the config file for the child0 repository:
$ cat child0/.git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /path/to/parent
[branch "master"]
remote = origin
merge = refs/heads/master
In particular:
fetch = +refs/heads/*:refs/remotes/origin/*
That is the default `refspec'; when `git fetch' is not explicitly
told on the command line what to fetch and which branch head[s] to
update, then this refspec is used as a default.
Now, look at the config file for the child1 repository:
$ cat child1/config
[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
url = /path/to/parent
In particular, note that a bare repository doesn't include any
such default information for `git fetch'. However, you could be
explicit about it; from within the chidl1 repo:
$ git fetch origin '+refs/heads/*:refs/remotes/origin/*'
> Just a "git fetch <parent>" doesn't seem to help. If I set up parent as
> a remote branch I can fetch it,
Firstly, it doesn't make any sense to say "set up parent as a remote
branch"; what you mean is "set up `<parent>' as a remote with a default
refspec that creates any associated remote-tracking branch heads".
Secondly, by setting up `<parent>' as a remote, you are creating the
missing refspec in your config file:
[remote "<parent>"]
url = /path/to/parent
fetch = +refs/heads/*:refs/remotes/<parent>/*
which is why you get this:
> but then it shows all the branches as "<parent>/<branch>" rather
> than updating the child.
You need a different refspec, namely:
+refs/heads/*:refs/heads/*
So, either be explicit:
git fetch '<parent>' '+refs/heads/*:refs/heads/*'
or update your config:
git config 'remote.<parent>.fetch' '+refs/heads/*:refs/heads/*'
Of course, there is an easier way that does all of this [and more]
for you:
> I just tried a "git clone --mirror" to create the child and it seems to
> allow me to pick up changes in the parent via "git fetch". Is that the
> proper way to handle this?
The documentation answers your question (but badly, as with much of the
documentation); from `git help clone':
--mirror
Set up a mirror of the source repository. This implies
--bare. Compared to --bare, --mirror not only maps local
branches of the source to local branches of the target, it
maps all refs (including remote-tracking branches, notes
etc.) and sets up a refspec configuration such that all
these refs are overwritten by a git remote update in the
target repository.
In particular:
sets up a refspec configuration such that all
these refs are overwritten by a git remote update in the
target repository.
Consider this:
$ git clone --mirror parent child2
$ cat child2/config
[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
fetch = +refs/*:refs/*
mirror = true
url = /path/to/parent
In particular:
fetch = +refs/*:refs/*
That's a very liberal refspec! It basically says that fetch
should mirror everything by default.
Sincerely,
Michael Witten
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jay Soffian @ 2011-09-22 18:41 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, Junio C Hamano, git discussion list
In-Reply-To: <20110922171340.GA2934@sigill.intra.peff.net>
On Thu, Sep 22, 2011 at 1:13 PM, Jeff King <peff@peff.net> wrote:
>
> No, we definitely don't use in-tree gitattributes. IIRC, there are some
> precedence and ordering questions. I think the ordering now is:
>
> 1. Look in $GIT_DIR/info/attributes
>
> 2. If not found, look in per-directory .gitattributes
>
> 3. If not found, look in core.gitattributesfile
>
> Where do in-tree attributes fit in? Between 1 and 2? Or 2 and 3? And
> which tree do we look at?
attr.c says:
a. built-in attributes
b. $(prefix)/etc/gitattributes unless GIT_ATTR_NOSYSTEM is set
c. core.attributesfile
d. per-directory .gitattributes
e. $GIT_DIR/info/attributes
The mechanics of (d) are established by git_attr_direction:
GIT_ATTR_CHECKIN: working-copy, then index
GIT_ATTR_CHECKOUT: index, then working-copy
GIT_ATTR_INDEX: index-only
Where GIT_ATTR_CHECKIN is the default direction and GIT_ATTR_CHECKOUT
is used while checking-out files from the index. (GIT_ATTR_INDEX is
used only by git-archive.)
Note that (d) only occurs in non-bare repos or if direction is GIT_ATTR_INDEX.
> Here are some examples:
>
> a. If I do "git checkout branch-foo", we should look at branch-foo's
> tree for things like crlf, right? Do we still fall back to
> per-directory .gitattributes in the working tree? On the one hand,
> they're not really relevant to the commit we're moving to. But they
> are respected in the current code, and can be useful when moving to
> old commits which lack attributes.
>
> I think this is where the index magic comes in in the current code
> (we do something like "load the index, then respect gitattributes
> from the index").
>
> So maybe this is solved already.
>
> b. You're diffing commit $a against commit $b. Whose gitattributes
> have precedence? Is order important? Are gitattributes in the
> working tree and index relevant?
>
> c. You're diffing commit $a against HEAD. Which gitattributes have
> precedence? Again, is order important (i.e., does "diff -R" look at
> different attributes than "diff")?
>
> I'm sure there are others, too. And I don't think any of these is
> insurmountable. But somebody needs to think through a lot of cases and
> come up with consistent, sane behavior that does the right thing in each
> case (considering both bare repositories and ones with working trees).
I think that diff-index --cached or when there is no working tree,
should set the direction to GIT_ATTR_INDEX so that it may be used with
a bare repo. In such case, the .gitattributes would come from the
index.
Consistent with that, when comparing two commits (diff-tree), I think
you look at the .gitattributes in the second commit.
j.
^ permalink raw reply
* --simplify-by-decoration, but include branch points
From: Andrew Pimlott @ 2011-09-22 18:24 UTC (permalink / raw)
To: git
The --simplify-by-decoration option to git log is a great way to view
branch topology. However, it is a bit misleading because it does not
necessarily show branch points. For example, I have a repository that
looks like:
* 6045d25 (HEAD, master) 3
| * 8daa592 (branch) 2.1
|/
* a4da73a 2
* 014106d (tag: v1) 1
This is from "git log --decorate --all --graph --oneline". If I add
--simplify-by-decoration, I get
* 6045d25 (HEAD, master) 3
| * 8daa592 (branch) 2.1
|/
* 014106d (tag: v1) 1
Note it appears as though the branch point is 014106d, when it's really
014106d. I would love to see an option like --simplify-by-decoration
that also selects branch points for display, maybe
--simplify-by-branch-point. (It should be possible to combine it with
--simplify-by-decoration.)
Is there anything like this?
Andrew
^ permalink raw reply
* Re: Bug: git log --numstat counts wrong
From: Junio C Hamano @ 2011-09-22 17:51 UTC (permalink / raw)
To: Alexander Pepper; +Cc: git, Tay Ray Chuan
In-Reply-To: <7vobyd1vmo.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Alexander Pepper <pepper@inf.fu-berlin.de> writes:
>
>> Am 21.09.2011 um 14:24 schrieb Junio C Hamano:
>>>> $ git log --numstat 48a07e7e533f507228e8d1c99d4d48e175e14260
>>>> [...]
>>>> 11 10 src/java/voldemort/server/storage/StorageService.java
>>>
>>> Didn't we update it this already? I seem to get 10/9 here not 11/10.
>>
>> Current 'maint' (cd2b8ae9), 'master' (4b5eac7f)...
>
> That's a tad old master you seem to have.
>
> Strangely, bisection points at 27af01d5523, which was supposed to be only
> about performance and never about correctness. There is something fishy
> going on....
In any case, I think the real issue is that depending on how much context
you ask, the resulting diff is different (and both are valid diffs). If
you ask "log -p" (or "diff" or "show") to produce a patch, then we use the
default 3-line context. And then you feed that to an external diffstat to
count the number of deleted and added lines to get one set of numbers.
The --numstat (and --diffstat) code seems to be running the internal diff
machinery with 0-line context and counting the resulting diff internally.
And of course the results between the above two would be different because
diff can match lines differently when given different number of context
lines to include in the result.
So perhaps a good sanity-check for you to try (note: not checking your
sanity, but checking the sanity of the above analysis) would be to do:
$ git show 48a07e7e53 -- $that_path | diffstat
$ git show -U0 48a07e7e53 -- $that_path | diffstat
$ git show --numstat 48a07e7e53 -- $that_path
$ git show --stat 48a07e7e53 -- $that_path
and see how they compare (make sure to use the same version of git for
these experiments). The first one uses the default 3-lines context, the
second one forces 0-line context, and the last two uses 0-line context
hardwired in the code.
Applying the following patch should make the last two use the default
context or -U$num given from the command line to be consistent with the
codepath where we generate textual patches.
diff.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 9038f19..302ef33 100644
--- a/diff.c
+++ b/diff.c
@@ -2251,6 +2251,8 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
memset(&xpp, 0, sizeof(xpp));
memset(&xecfg, 0, sizeof(xecfg));
xpp.flags = o->xdl_opts;
+ xecfg.ctxlen = o->context;
+ xecfg.interhunkctxlen = o->interhunkcontext;
xdi_diff_outf(&mf1, &mf2, diffstat_consume, diffstat,
&xpp, &xecfg);
}
^ permalink raw reply related
* Re: [PATCH v3] Docs: Clarify the --tags option of `git fetch'
From: Michael Witten @ 2011-09-22 17:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anatol Pomozov, Drew Northup, Andrew Ardill, Daniel Johnson, git
In-Reply-To: <CAMOZ1BtBEHae7x-cn=DtnzwoyC_sYedgFmyNwrDuju+kcJU4hg@mail.gmail.com>
On Thu, Sep 22, 2011 at 17:35, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Sep 22, 2011 at 17:10, Junio C Hamano <gitster@pobox.com> wrote:
>> Michael Witten <mfwitten@gmail.com> writes:
>>
>>> 8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------
>>>
>>> See the discussion starting here:
>>>
>>> [PATCH] Clarify that '--tags' fetches tags only
>>> Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>
>>> http://thread.gmane.org/gmane.comp.version-control.git/180636
>>
>> It is a good practice to point to earlier discussions while polishing
>> patch, and it also is good to include pointers in the commit log message
>> as a supporting material (additional reading), but that is _NOT_ a
>> substitute for a properly written commit log message. You need to state
>> what problem you are trying to fix and how the proposed patch fixes it.
>>
>>> Documentation/fetch-options.txt | 31 +++++++++++++++++++++++--------
>>> 1 files changed, 23 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
>>> index 39d326a..4cc5a80 100644
>>> --- a/Documentation/fetch-options.txt
>>> +++ b/Documentation/fetch-options.txt
>>> @@ -56,14 +56,29 @@ endif::git-pull[]
>>> ifndef::git-pull[]
>>> -t::
>>> --tags::
>>> - Most of the tags are fetched automatically as branch
>>> - heads are downloaded, but tags that do not point at
>>> - objects reachable from the branch heads that are being
>>> - tracked will not be fetched by this mechanism. This
>>> - flag lets all tags and their associated objects be
>>> - downloaded. The default behavior for a remote may be
>>> - specified with the remote.<name>.tagopt setting. See
>>> - linkgit:git-config[1].
>>> + Most of a remote's tags are fetched automatically as branches are
>>> + downloaded. However, git does not automatically fetch any tag that,
>>> + when 'git fetch' completes, would not be reachable from any local
>>> + branch head. This option tells git to fetch all tags (and their
>>> + associated objects).
>>
>> I would suggest clarifying the beginning of "git fetch --help" like the
>> attached patch. With that knowledge at hand, the readers do not need the
>> fuzzy "Most of ... are fetched" (leaving them wondering "what about the
>> rest, and how that Most is determined?"); we only need to say something
>> like "fetch all the tags from the remote and store them locally".
>>
>> Documentation/git-fetch.txt | 21 ++++++++++-----------
>> 1 files changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
>> index 60ac8d2..c6c7236 100644
>> --- a/Documentation/git-fetch.txt
>> +++ b/Documentation/git-fetch.txt
>> @@ -19,20 +19,19 @@ SYNOPSIS
>>
>> DESCRIPTION
>> -----------
>> -Fetches named heads or tags from one or more other repositories,
>> -along with the objects necessary to complete them.
>> +Fetches branches and tags (collectively known as 'refs') from one or more
>> +other repositories, along with the objects necessary to complete them.
>> +Which refs are fetched are determined by the <refspec> arguments, if
>> +given. Otherwise the default <refspec> configured for the <repository>
>> +are used (see "REMOTES" section below for how <refspec> works).
>>
>> -The ref names and their object names of fetched refs are stored
>> -in `.git/FETCH_HEAD`. This information is left for a later merge
>> -operation done by 'git merge'.
>> +The ref names and their object names are also stored in `.git/FETCH_HEAD`.
>> +This information is used by 'git pull' that invokes this command.
>>
>> When <refspec> stores the fetched result in remote-tracking branches,
>> -the tags that point at these branches are automatically
>> -followed. This is done by first fetching from the remote using
>> -the given <refspec>s, and if the repository has objects that are
>> -pointed by remote tags that it does not yet have, then fetch
>> -those missing tags. If the other end has tags that point at
>> -branches you are not interested in, you will not get them.
>> +the tags that point at commits on these branches are also fetched. Tags
>> +at the remote that point at commits that are not on these remote-tracking
>> +branches are not fetched by this mechanism (use `--tags` option to fetch them).
>>
>> 'git fetch' can fetch from either a single named repository,
>> or from several repositories at once if <group> is given and
>>
>
> The only problem is that none of what you say seems to be true.
>
> * The glossary very distinctly differentiates the
> term `branch' from `branch head'.
>
> * From skimming the code, it would seem that remote-tracking
> branch [*heads*] are not at all the determining factor for
> whether tags are automatically fetched. Rather, the
> determining factor is much more relaxed: Tags are fetched
> when a refspec's <dst> field is non-empty; it just so
> happens that a <dst> is usually non-empty because at least
> one remote-tracking branch [*head*] is being updated, but
> keep in mind that the branch being updated need not be
> considered a remote-tracking branch.
DAMNIT
That last bit should use the world `head':
but keep in mind that the branch *head* being updated
need not be considered a remote-tracking branch [*head*].
^ permalink raw reply
* Re: [PATCH v3] Docs: Clarify the --tags option of `git fetch'
From: Michael Witten @ 2011-09-22 17:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anatol Pomozov, Drew Northup, Andrew Ardill, Daniel Johnson, git
In-Reply-To: <7v1uv8zen5.fsf@alter.siamese.dyndns.org>
On Thu, Sep 22, 2011 at 17:10, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> 8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------
>>
>> See the discussion starting here:
>>
>> [PATCH] Clarify that '--tags' fetches tags only
>> Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>
>> http://thread.gmane.org/gmane.comp.version-control.git/180636
>
> It is a good practice to point to earlier discussions while polishing
> patch, and it also is good to include pointers in the commit log message
> as a supporting material (additional reading), but that is _NOT_ a
> substitute for a properly written commit log message. You need to state
> what problem you are trying to fix and how the proposed patch fixes it.
>
>> Documentation/fetch-options.txt | 31 +++++++++++++++++++++++--------
>> 1 files changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
>> index 39d326a..4cc5a80 100644
>> --- a/Documentation/fetch-options.txt
>> +++ b/Documentation/fetch-options.txt
>> @@ -56,14 +56,29 @@ endif::git-pull[]
>> ifndef::git-pull[]
>> -t::
>> --tags::
>> - Most of the tags are fetched automatically as branch
>> - heads are downloaded, but tags that do not point at
>> - objects reachable from the branch heads that are being
>> - tracked will not be fetched by this mechanism. This
>> - flag lets all tags and their associated objects be
>> - downloaded. The default behavior for a remote may be
>> - specified with the remote.<name>.tagopt setting. See
>> - linkgit:git-config[1].
>> + Most of a remote's tags are fetched automatically as branches are
>> + downloaded. However, git does not automatically fetch any tag that,
>> + when 'git fetch' completes, would not be reachable from any local
>> + branch head. This option tells git to fetch all tags (and their
>> + associated objects).
>
> I would suggest clarifying the beginning of "git fetch --help" like the
> attached patch. With that knowledge at hand, the readers do not need the
> fuzzy "Most of ... are fetched" (leaving them wondering "what about the
> rest, and how that Most is determined?"); we only need to say something
> like "fetch all the tags from the remote and store them locally".
>
> Documentation/git-fetch.txt | 21 ++++++++++-----------
> 1 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index 60ac8d2..c6c7236 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -19,20 +19,19 @@ SYNOPSIS
>
> DESCRIPTION
> -----------
> -Fetches named heads or tags from one or more other repositories,
> -along with the objects necessary to complete them.
> +Fetches branches and tags (collectively known as 'refs') from one or more
> +other repositories, along with the objects necessary to complete them.
> +Which refs are fetched are determined by the <refspec> arguments, if
> +given. Otherwise the default <refspec> configured for the <repository>
> +are used (see "REMOTES" section below for how <refspec> works).
>
> -The ref names and their object names of fetched refs are stored
> -in `.git/FETCH_HEAD`. This information is left for a later merge
> -operation done by 'git merge'.
> +The ref names and their object names are also stored in `.git/FETCH_HEAD`.
> +This information is used by 'git pull' that invokes this command.
>
> When <refspec> stores the fetched result in remote-tracking branches,
> -the tags that point at these branches are automatically
> -followed. This is done by first fetching from the remote using
> -the given <refspec>s, and if the repository has objects that are
> -pointed by remote tags that it does not yet have, then fetch
> -those missing tags. If the other end has tags that point at
> -branches you are not interested in, you will not get them.
> +the tags that point at commits on these branches are also fetched. Tags
> +at the remote that point at commits that are not on these remote-tracking
> +branches are not fetched by this mechanism (use `--tags` option to fetch them).
>
> 'git fetch' can fetch from either a single named repository,
> or from several repositories at once if <group> is given and
>
The only problem is that none of what you say seems to be true.
* The glossary very distinctly differentiates the
term `branch' from `branch head'.
* From skimming the code, it would seem that remote-tracking
branch [*heads*] are not at all the determining factor for
whether tags are automatically fetched. Rather, the
determining factor is much more relaxed: Tags are fetched
when a refspec's <dst> field is non-empty; it just so
happens that a <dst> is usually non-empty because at least
one remote-tracking branch [*head*] is being updated, but
keep in mind that the branch being updated need not be
considered a remote-tracking branch.
^ permalink raw reply
* any way to "re-sync" a bare repository against another bare repository?
From: Chris Friesen @ 2011-09-22 17:22 UTC (permalink / raw)
To: git
Suppose I have a parent bare repository. I do a "git clone --bare" to
create a child repository, and then clone the child to create a
grandchild repository.
If changes get pushed into the parent repository, is there any way to
cause the child to be updated?
Just a "git fetch <parent>" doesn't seem to help. If I set up parent as
a remote branch I can fetch it, but then it shows all the branches as
"parent/<branch>" rather than updating the child.
I just tried a "git clone --mirror" to create the child and it seems to
allow me to pick up changes in the parent via "git fetch". Is that the
proper way to handle this?
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: Bug: git log --numstat counts wrong
From: Junio C Hamano @ 2011-09-22 17:32 UTC (permalink / raw)
To: Alexander Pepper; +Cc: git, Tay Ray Chuan
In-Reply-To: <FAB0B05E-6BAD-488C-8478-F4B80493FB96@inf.fu-berlin.de>
Alexander Pepper <pepper@inf.fu-berlin.de> writes:
> When used git version 1.7.7.rc1 I didn't observed any case where git
> show and git log --numstat mismatch. I'm only a little confused, that
> 'git show' yields different results, depending on the git version.
In general it is not surprising nor unexpected--as long as both patches
describe the change correctly, they are both valid.
What was unexpected to me was that 27af01d (xdiff/xprepare: improve O(n*m)
performance in xdl_cleanup_records(), 2011-08-17) which was supposed to be
only about performance and not about logic made that difference.
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Junio C Hamano @ 2011-09-22 17:26 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git discussion list, Jay Soffian
In-Reply-To: <4E7AF1AE.5030005@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I would like the checking configuration to be *versioned* along with the
> code. For example, suppose my project decides to enforce a rule that
> all Python code needs to be indented with spaces. It might be that not
> all of our old code adheres to this rule, and that we only want to clean
> up the code in master.
You want to sneak in a badly formatted code? Add an entry to the in-tree
attributes file to disable whitespace checking to cover that file!
So even though I agree with you that the check mechanism may need to be
aware of what revision it is checking and adjust which rules are applied
when checking the revision, I do not think using in-tree attribute file is
the right solution to that problem.
^ permalink raw reply
* Re: [PATCH] patch-id.c: use strbuf instead of a fixed buffer
From: Jeff King @ 2011-09-22 17:17 UTC (permalink / raw)
To: Michael Schubert; +Cc: Junio C Hamano, Andrew Pimlott, git
In-Reply-To: <4E79DBAE.5090505@elegosoft.com>
On Wed, Sep 21, 2011 at 02:42:22PM +0200, Michael Schubert wrote:
> get_one_patchid() uses a rather dumb heuristic to determine if the
> passed buffer is part of the next commit. Whenever the first 40 bytes
> are a valid hexadecimal sha1 representation, get_one_patchid() returns
> next_sha1.
> Once the current line is longer than the fixed buffer, this will break
> (provided the additional bytes make a valid hexadecimal sha1). As a result
> patch-id returns incorrect results. Instead, user strbuf and read one
> line at a time.
A minor nit, but I think this is probably broken even if the additional
bytes don't look like a valid sha1. It would look like cruft after the
diff (since the lien doesn't start with plus, minus, or space), which
means it would not be stirred into the sha1 mix.
> builtin/patch-id.c | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
The patch itself looks good to me, though. Thanks.
-Peff
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-22 17:13 UTC (permalink / raw)
To: Jay Soffian; +Cc: Michael Haggerty, Junio C Hamano, git discussion list
In-Reply-To: <CAG+J_DxtCx6-RKWLKFy+V7tOtu7UnUrke7iN8gNdGiY-sC52sQ@mail.gmail.com>
On Thu, Sep 22, 2011 at 11:41:34AM -0400, Jay Soffian wrote:
> Thank you for this thread. I was under the illusion that diff-tree
> --check considered in-tree .gitattributes, but the code seems to
> indicate otherwise. :-(
No, we definitely don't use in-tree gitattributes. IIRC, there are some
precedence and ordering questions. I think the ordering now is:
1. Look in $GIT_DIR/info/attributes
2. If not found, look in per-directory .gitattributes
3. If not found, look in core.gitattributesfile
Where do in-tree attributes fit in? Between 1 and 2? Or 2 and 3? And
which tree do we look at?
Here are some examples:
a. If I do "git checkout branch-foo", we should look at branch-foo's
tree for things like crlf, right? Do we still fall back to
per-directory .gitattributes in the working tree? On the one hand,
they're not really relevant to the commit we're moving to. But they
are respected in the current code, and can be useful when moving to
old commits which lack attributes.
I think this is where the index magic comes in in the current code
(we do something like "load the index, then respect gitattributes
from the index").
So maybe this is solved already.
b. You're diffing commit $a against commit $b. Whose gitattributes
have precedence? Is order important? Are gitattributes in the
working tree and index relevant?
c. You're diffing commit $a against HEAD. Which gitattributes have
precedence? Again, is order important (i.e., does "diff -R" look at
different attributes than "diff")?
I'm sure there are others, too. And I don't think any of these is
insurmountable. But somebody needs to think through a lot of cases and
come up with consistent, sane behavior that does the right thing in each
case (considering both bare repositories and ones with working trees).
-Peff
^ permalink raw reply
* Re: [PATCH v3] Docs: Clarify the --tags option of `git fetch'
From: Junio C Hamano @ 2011-09-22 17:10 UTC (permalink / raw)
To: Michael Witten
Cc: Anatol Pomozov, Drew Northup, Andrew Ardill, Daniel Johnson, git
In-Reply-To: <686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> 8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------
>
> See the discussion starting here:
>
> [PATCH] Clarify that '--tags' fetches tags only
> Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>
> http://thread.gmane.org/gmane.comp.version-control.git/180636
It is a good practice to point to earlier discussions while polishing
patch, and it also is good to include pointers in the commit log message
as a supporting material (additional reading), but that is _NOT_ a
substitute for a properly written commit log message. You need to state
what problem you are trying to fix and how the proposed patch fixes it.
> Documentation/fetch-options.txt | 31 +++++++++++++++++++++++--------
> 1 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index 39d326a..4cc5a80 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -56,14 +56,29 @@ endif::git-pull[]
> ifndef::git-pull[]
> -t::
> --tags::
> - Most of the tags are fetched automatically as branch
> - heads are downloaded, but tags that do not point at
> - objects reachable from the branch heads that are being
> - tracked will not be fetched by this mechanism. This
> - flag lets all tags and their associated objects be
> - downloaded. The default behavior for a remote may be
> - specified with the remote.<name>.tagopt setting. See
> - linkgit:git-config[1].
> + Most of a remote's tags are fetched automatically as branches are
> + downloaded. However, git does not automatically fetch any tag that,
> + when 'git fetch' completes, would not be reachable from any local
> + branch head. This option tells git to fetch all tags (and their
> + associated objects).
I would suggest clarifying the beginning of "git fetch --help" like the
attached patch. With that knowledge at hand, the readers do not need the
fuzzy "Most of ... are fetched" (leaving them wondering "what about the
rest, and how that Most is determined?"); we only need to say something
like "fetch all the tags from the remote and store them locally".
Documentation/git-fetch.txt | 21 ++++++++++-----------
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 60ac8d2..c6c7236 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -19,20 +19,19 @@ SYNOPSIS
DESCRIPTION
-----------
-Fetches named heads or tags from one or more other repositories,
-along with the objects necessary to complete them.
+Fetches branches and tags (collectively known as 'refs') from one or more
+other repositories, along with the objects necessary to complete them.
+Which refs are fetched are determined by the <refspec> arguments, if
+given. Otherwise the default <refspec> configured for the <repository>
+are used (see "REMOTES" section below for how <refspec> works).
-The ref names and their object names of fetched refs are stored
-in `.git/FETCH_HEAD`. This information is left for a later merge
-operation done by 'git merge'.
+The ref names and their object names are also stored in `.git/FETCH_HEAD`.
+This information is used by 'git pull' that invokes this command.
When <refspec> stores the fetched result in remote-tracking branches,
-the tags that point at these branches are automatically
-followed. This is done by first fetching from the remote using
-the given <refspec>s, and if the repository has objects that are
-pointed by remote tags that it does not yet have, then fetch
-those missing tags. If the other end has tags that point at
-branches you are not interested in, you will not get them.
+the tags that point at commits on these branches are also fetched. Tags
+at the remote that point at commits that are not on these remote-tracking
+branches are not fetched by this mechanism (use `--tags` option to fetch them).
'git fetch' can fetch from either a single named repository,
or from several repositories at once if <group> is given and
^ permalink raw reply related
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-22 16:39 UTC (permalink / raw)
To: Michael Schubert; +Cc: Carlos Martín Nieto, git
In-Reply-To: <4E7AFC6C.7080603@elegosoft.com>
Michael Schubert <mschub@elegosoft.com> writes:
> On 09/22/2011 10:37 AM, Carlos Martín Nieto wrote:
>> On Wed, 2011-09-21 at 22:04 -0700, Junio C Hamano wrote:
>>> * cn/eradicate-working-copy (2011-09-21) 2 commits
>>> - patch-id.c: use strbuf instead of a fixed buffer
>>> - Remove 'working copy' from the documentation and C code
>>
>> It looks like that first commit sneaked in there. Shouldn't that be its
>> own topic?
>
> It's in pu twice:
Thansk for noticing. Will remove.
> On 09/22/2011 07:04 AM, Junio C Hamano wrote:
>> * cn/eradicate-working-copy (2011-09-21) 2 commits
>> - patch-id.c: use strbuf instead of a fixed buffer
>> - Remove 'working copy' from the documentation and C code
>
>> * ms/patch-id-with-overlong-line (2011-09-21) 1 commit
>> - patch-id.c: use strbuf instead of a fixed buffer
>
> 64128da and a6c5c60
>
> There's also a minor typo in the last sentence of the commit message.
> Should I resend?
If that is s/user/use/ and nothing else, I can amend locally; otherwise
please do.
The last part of the "rather dumb heiristic" you talk about is designed to
parse "cmd | diff-tree -p --stdin" output. I agree with you that it can
safely tightened a bit by checking that 41st byte is the EOL, but it
probably is not worth 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