Re: [PATCH] t/t5800-remote-testpy: skip all tests if not built
Jeff King wrote: So I do not see any problem with the current Makefile. Running make or make test should let t5800 pass. Can you describe how you are triggering the issue in more detail? master, at the time of reporting the issue: artagnon|master=:~/src/git$ make -j 8 artagnon|master=:~/src/git$ rm git-remote-testpy artagnon|master=:~/src/git$ make -j 8 artagnon|master=:~/src/git$ cd t artagnon|master=:~/src/git$ sh t5800-remote-testpy.sh # failure Yesterday's jc publish fixed it: 6c473a5 (build: generate and clean test scripts, 2013-06-07) graduated to master; it adds $NO_INSTALL to the target all, among other things. [...] Yes, I agree that it is convoluted and can be cleaned up. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t/t5800-remote-testpy: skip all tests if not built
On Fri, Jun 21, 2013 at 12:07:50PM +0530, Ramkumar Ramachandra wrote: Yesterday's jc publish fixed it: 6c473a5 (build: generate and clean test scripts, 2013-06-07) graduated to master; it adds $NO_INSTALL to the target all, among other things. Ah, makes sense. Sorry to be slow. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] clone: regression in error messages in master
Jeff King wrote:
So I'm not sure if there is a better option than reverting 81d340d4 and
living with the lesser of two evils (no good message when the helper
dies silently).
I dug around, but I still can't justify that there is no better
option. Could you write a commit message for this?
-- 8 --
diff --git a/transport-helper.c b/transport-helper.c
index 06c08a1..db9bd18 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -56,7 +56,7 @@ static int recvline_fh(FILE *helper, struct strbuf
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, Debug: Remote helper quit.\n);
- die(Reading from helper 'git-remote-%s' failed, name);
+ exit(128);
}
if (debug)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] clone: regression in error messages in master
Ramkumar Ramachandra wrote: diff --git a/transport-helper.c b/transport-helper.c index 06c08a1..db9bd18 100644 --- a/transport-helper.c +++ b/transport-helper.c Oh, and we have to remove test 23 - proper failure checks for pushing from t5801-remote-helpers.sh. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] clone: regression in error messages in master
On Fri, Jun 21, 2013 at 12:14:33PM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
So I'm not sure if there is a better option than reverting 81d340d4 and
living with the lesser of two evils (no good message when the helper
dies silently).
I dug around, but I still can't justify that there is no better
option. Could you write a commit message for this?
I think it is something like this:
-- 8 --
Subject: [PATCH] transport-helper: be quiet on read errors from helpers
Prior to commit 81d340d4, we did not print any error message
if a remote transport helper died unexpectedly. If a helper
did not print any error message (e.g., because it crashed),
the user could be left confused. That commit tried to
rectify the situation by printing a note that the helper
exited unexpectedly.
However, this makes a much more common case worse: when a
helper does die with a useful message, we print the extra
Reading from 'git-remote-foo failed message. This can also
end up confusing users, as they may not even know what
remote helpers are (e.g., the fact that http support comes
through git-remote-https is purely an implementation detail
that most users do not know or care about).
Since we do not have a good way of knowing whether the
helper printed a useful error, and since the common failure
mode is for it to do so, let's default to remaining quiet.
Debuggers can dig further by setting GIT_TRANSPORT_HELPER_DEBUG.
Signed-off-by: Jeff King p...@peff.net
---
Note that I haven't thought too hard about this; there may be a way to
detect for specific operations that we were expecting more data from the
helper and didn't get it. But even if we do want to go that route, I
think reverting the change to recvline_fh is probably going to be the
first step.
t/t5801-remote-helpers.sh | 4 +---
transport-helper.c| 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 4899af3..8c4c539 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -210,9 +210,7 @@ test_expect_success 'proper failure checks for pushing' '
(GIT_REMOTE_TESTGIT_FAILURE=1
export GIT_REMOTE_TESTGIT_FAILURE
cd local
- test_must_fail git push --all 2 error
- cat error
- grep -q Reading from helper .git-remote-testgit. failed error
+ test_must_fail git push --all
)
'
diff --git a/transport-helper.c b/transport-helper.c
index 06c08a1..db9bd18 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -56,7 +56,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer,
const char *name)
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, Debug: Remote helper quit.\n);
- die(Reading from helper 'git-remote-%s' failed, name);
+ exit(128);
}
if (debug)
--
1.8.3.rc2.14.g7eee6b3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Splitting a rev list into 2 sets
Hi, On Thu, Jun 20, 2013 at 3:47 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Francis Moreau wrote: Basically I have an initial set (or can be several different sets) expressed as a revision specification described by git-rev-list man page. I just want to find the common set of commit which are part of the initial sets *and* is reachable by master. That's just a generic list intersection between [a, b, c] and [d, e, f] no? [a, b, c] is a list you built up somehow, and [d, e, f] comes from $(git rev-list master), right? yes. You could go about determining the revision walk boundaries and combine them to set up a revision walk to splice the master line, but what is the point of that? Well, that seems to me a more elegant solution and I was curious about doing this with git-rev-list only if possible. You'll only be painting yourself into a design-corner (you won't be able to do other kinds of filtering), and going around your head to touch your nose. I think what Thomas proposed is fine. You precisely want list intersection: so write an efficient list intersection in the language of your choice. Why is it a poor man's solution? Sorry my wording was poor. I just meant that it was the obvious solution that I don't find nice. But your implementation was good. If anything, your convoluted rev-list solution will probably be more complicated, slower, and bug-ridden. Slower ? why do you think Thomas' solution is slower than the obvious one ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Splitting a rev list into 2 sets
Francis Moreau wrote: Slower ? why do you think Thomas' solution is slower than the obvious one ? There's really only one way to find out: try it and see. YMMV depending on your data. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] web--browse: support /usr/bin/cygstart on Cygwin
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
While both GUI and console Cygwin browsers do exist, anecdotal evidence
suggests most users rely on their native Windows browser. cygstart,
which is a long-standing part of the base Cygwin installation, will
cause the page to be opened in the default Windows browser (the one
registered to open .html files).
Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
---
Documentation/git-web--browse.txt | 1 +
git-web--browse.sh| 9 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-web--browse.txt
b/Documentation/git-web--browse.txt
index ba79cb4..5aec4ec 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -34,6 +34,7 @@ The following browsers (or commands) are currently supported:
* dillo
* open (this is the default under Mac OS X GUI)
* start (this is the default under MinGW)
+* cygstart (this is the default under Cygwin)
Custom commands may also be specified.
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 9f44679..9fc1dba 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -33,7 +33,8 @@ valid_tool() {
case $1 in
firefox | iceweasel | seamonkey | iceape | \
chrome | google-chrome | chromium | chromium-browser |\
- konqueror | opera | w3m | elinks | links | lynx | dillo | open | start)
+ konqueror | opera | w3m | elinks | links | lynx | dillo | open |\
+ start | cygstart)
;; # happy
*)
valid_custom_tool $1 || return 1
@@ -127,6 +128,10 @@ if test -z $browser ; then
if test -x /bin/start; then
browser_candidates=start $browser_candidates
fi
+ # /usr/bin/cygstart indicates Cygwin
+ if test -x /usr/bin/cygstart; then
+ browser_candidates=cygstart $browser_candidates
+ fi
for i in $browser_candidates; do
init_browser_path $i
@@ -174,7 +179,7 @@ konqueror)
;;
esac
;;
-w3m|elinks|links|lynx|open)
+w3m|elinks|links|lynx|open|cygstart)
$browser_path $@
;;
start)
--
1.8.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
fast-import bug?
The docs for fast-import seem to imply that I can use ls to get the
SHA1 of a commit for which I have a mark:
Reading from a named tree
The dataref can be a mark reference (:idnum) or the full 40-byte
SHA-1 of a Git tag, commit, or tree object, preexisting or waiting to
be written. The path is relative to the top level of the tree named
by
dataref.
'ls' SP dataref SP path LF
See filemodify above for a detailed description of path.
Output uses the same format as git ls-tree tree -- path:
mode SP ('blob' | 'tree' | 'commit') SP dataref HT path LF
The dataref represents the blob, tree, or commit object at path and
^^
can be used in later cat-blob, filemodify, or ls commands.
but I can't get it to work. It's not entirely clear it's supposed to
work. What path would I pass? Passing an empty path simply causes git
to report missing .
TIA,
Dave
--
Dave Abrahams
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Handling overlapping refspecs slightly smarter
1/3 should be pretty sane, just adding a warning in documentation and 'git remote add' about overlapping refspecs. 2/3 only makes sense if 3/3 is accepted, as it's a test for that change. 3/3 I'm not 100% sure about, though the approach feels reasonably ok. It changes get_stale_heads to also detect overlapping refspecs and abort any prune action if it finds them. What I'm not sure about is whether this is the right place to do it, or to do it in the callers of get_stale_heads and exit(1) in this situation. Both 1/3 and 3/3 ignore exactly matching refspecs, as that's a supported thing already, another test in t5505 broke before I made both ignore exactly matching refspecs. Dennis Kaarsemaker (3): remote: Add warnings about mixin --mirror and other remotes remote: Add test for prune and mixed --mirror and normal remotes remote: don't prune when detecting overlapping refspecs Documentation/git-remote.txt | 6 +- builtin/remote.c | 17 + remote.c | 23 +++ t/t5505-remote.sh| 9 + 4 files changed, 54 insertions(+), 1 deletion(-) -- 1.8.3.1-619-gbec0aa7 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] remote: don't prune when detecting overlapping refspecs
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as
stale. There's no good way to solve, this so the best thing we can do
is refusing to prune if we detect this and warning the user.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
remote.c | 23 +++
t/t5505-remote.sh | 2 +-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index e71f66d..39a9405 100644
--- a/remote.c
+++ b/remote.c
@@ -1912,11 +1912,34 @@ static int get_stale_heads_cb(const char *refname,
return 0;
}
+static int check_overlapping_remotes(struct remote *first, void *priv) {
+ struct remote *second = priv;
+ int i, j;
+ if(!second)
+ return for_each_remote(check_overlapping_remotes, first);
+ if(first == second)
+ return 0;
+ for (i = 0; i first-fetch_refspec_nr; i++) {
+ for (j = 0; j second-fetch_refspec_nr; j++) {
+ if(strcmp(first-fetch[i].dst, second-fetch[j].dst)
+ (!fnmatch(first-fetch[i].dst, second-fetch[j].dst,
0) ||
+ !fnmatch(second-fetch[j].dst, first-fetch[i].dst,
0))) {
+ warning(_(Overlapping refspecs detected: '%s'
and '%s', not pruning.),
+ first-fetch[i].dst,
second-fetch[j].dst);
+ return 1;
+ }
+ }
+ }
+ return 0;
+}
+
struct ref *get_stale_heads(struct refspec *refs, int ref_count, struct ref
*fetch_map)
{
struct ref *ref, *stale_refs = NULL;
struct string_list ref_names = STRING_LIST_INIT_NODUP;
struct stale_heads_info info;
+ if(for_each_remote(check_overlapping_remotes, NULL))
+ return NULL;
info.ref_names = ref_names;
info.stale_refs_tail = stale_refs;
info.refs = refs;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 439e996..d4ac6ce 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -428,7 +428,7 @@ test_expect_success 'add alt prune' '
git rev-parse --verify refs/remotes/origin/side2)
'
-test_expect_failure 'prune and overlapping refspecs' '
+test_expect_success 'prune and overlapping refspecs' '
(git clone --mirror one prunetst
cd prunetst
git remote add two ../two
--
1.8.3.1-619-gbec0aa7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] remote: Add test for prune and mixed --mirror and normal remotes
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net --- t/t5505-remote.sh | 9 + 1 file changed, 9 insertions(+) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index dd10ff0..439e996 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -428,6 +428,15 @@ test_expect_success 'add alt prune' ' git rev-parse --verify refs/remotes/origin/side2) ' +test_expect_failure 'prune and overlapping refspecs' ' + (git clone --mirror one prunetst +cd prunetst +git remote add two ../two + git fetch two +git remote prune origin + git rev-parse --verify refs/remotes/two/another) +' + cat test/expect \EOF some-tag EOF -- 1.8.3.1-619-gbec0aa7 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] remote: Add warnings about mixin --mirror and other remotes
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin will mark all refs from other repos as stale.
Add a warning to the documentation, and warn the user when we detect
such things during git remote add.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
Documentation/git-remote.txt | 6 +-
builtin/remote.c | 17 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 581bb4c..d7457df 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -71,7 +71,11 @@ When a fetch mirror is created with `--mirror=fetch`, the
refs will not
be stored in the 'refs/remotes/' namespace, but rather everything in
'refs/' on the remote will be directly mirrored into 'refs/' in the
local repository. This option only makes sense in bare repositories,
-because a fetch would overwrite any local commits.
+because a fetch would overwrite any local commits. If you want to add extra
+remotes to a repository created with `--mirror=fetch`, you will need to change
+the configuration of the mirrored remote to fetch only `refs/heads/*`,
+otherwise `git remote prune remote` will remove all branches for the extra
+remotes.
+
When a push mirror is created with `--mirror=push`, then `git push`
will always behave as if `--mirror` was passed.
diff --git a/builtin/remote.c b/builtin/remote.c
index 5e54d36..a4f9cb8 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -112,6 +112,21 @@ enum {
#define MIRROR_PUSH 2
#define MIRROR_BOTH (MIRROR_FETCH|MIRROR_PUSH)
+static int check_overlapping_refspec(struct remote *remote, void *priv)
+{
+ char *refspec = priv;
+ int i;
+ for (i = 0; i remote-fetch_refspec_nr; i++) {
+ if(strcmp(refspec, remote-fetch[i].dst)
+ (!fnmatch(refspec, remote-fetch[i].dst, 0) ||
+ !fnmatch(remote-fetch[i].dst, refspec, 0))) {
+ warning(_(Overlapping refspecs detected: '%s' and
'%s'),
+ refspec, remote-fetch[i].dst);
+ }
+ }
+ return 0;
+}
+
static int add_branch(const char *key, const char *branchname,
const char *remotename, int mirror, struct strbuf *tmp)
{
@@ -123,6 +138,8 @@ static int add_branch(const char *key, const char
*branchname,
else
strbuf_addf(tmp, refs/heads/%s:refs/remotes/%s/%s,
branchname, remotename, branchname);
+
+ for_each_remote(check_overlapping_refspec, strchr((const
char*)tmp-buf, ':') + 1);
return git_config_set_multivar(key, tmp-buf, ^$, 0);
}
--
1.8.3.1-619-gbec0aa7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] clone: regression in error messages in master
On Thu, Jun 20, 2013 at 9:16 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, So this should explain the problem: # using v1.8.3.1 $ git clone https://google.com Cloning into 'google.com'... fatal: repository 'https://google.com/' not found # using master $ git clone https://google.com Cloning into 'google.com'... fatal: repository 'https://google.com/' not found fatal: Reading from helper 'git-remote-https' failed I can see where this is confusing, but can also see how it's useful information to have. On clone, it's probably not that useful since you're looking right at the url, but I could see that information being more useful on a pull or push with the default arguments (when the source and destination aren't quite as obvious). -John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[HELP] Corrupted repository
Hi,
Until now, my interest in corrupted repositories has been very
limited. Just now, the power went out for a second and my UPS failed
me. As a result, my ~/src/git is completely borked. For your
amusement, here's a quick session showing me bumbling around:
$ ~/src/git
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
artagnon|remote-cruft*+:~/src/git$ rm
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
artagnon|remote-cruft*+:~/src/git$ git prune
artagnon|remote-cruft*+:~/src/git$ git status
fatal: bad object HEAD
fatal: bad object HEAD
artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
artagnon|master*+=:~/src/git$ git status
## master
MM Documentation/git-ls-remote.txt
MM remote.c
MM t/t5505-remote.sh
MM t/t5510-fetch.sh
MM t/t5515-fetch-merge-logic.sh
MM t/t5516-fetch-push.sh
?? lib/
?? outgoing/
That status is completely bogus, by the way.
artagnon|master*+=:~/src/git$ git reset --hard
artagnon|master*+=:~/src/git$ git checkout remote-cruft
fatal: reference is not a tree: remote-cruft
artagnon|master=:~/src/git$ git reflog
21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
refs/heads/remote-cruft
What happened to the rest of my reflog?! Okay, I give up. Let's go
back to what's present on Github. I push often, so it's not a
problem.
artagnon|master=:~/src/git$ git branch -D remote-cruft
error: Couldn't look up commit object for 'refs/heads/remote-cruft'
artagnon|master=:~/src/git$ rm .git/refs/heads/remote-cruft
artagnon|master=:~/src/git$ git checkout -b remote-cruft
Switched to a new branch 'remote-cruft'
Huh? What happened to my upstream?
artagnon|remote-cruft:~/src/git$ git branch -u ram/remote-cruft
warning: ignoring broken ref refs/remotes/ram/remote-cruft.
Fine, let's fetch.
artagnon|remote-cruft:~/src/git$ git fetch ram
remote: Counting objects: 101, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 92 (delta 78), reused 82 (delta 68)
error: object file
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty
fatal: loose object 082b069c11e8d4f372b963b038cbf5b71a676ef6 (stored
in .git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6) is corrupt
fatal: unpack-objects failed
Fine, let's run an fsck and get rid of all the corrupted objects.
$ git fsck
error: object file
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty
error: object file
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6 is empty
fatal: loose object 082b069c11e8d4f372b963b038cbf5b71a676ef6 (stored
in .git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6) is corrupt
artagnon|remote-cruft:~/src/git$ rm
.git/objects/08/2b069c11e8d4f372b963b038cbf5b71a676ef6
artagnon|remote-cruft:~/src/git$ git repack
artagnon|remote-cruft:~/src/git$ git fetch ram
remote: Counting objects: 101, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 92 (delta 78), reused 82 (delta 68)
Unpacking objects: 100% (92/92), done.
error: object file
.git/objects/64/fa33d706658278b871a6e2ca66694efcadacca is empty
fatal: loose object 64fa33d706658278b871a6e2ca66694efcadacca (stored
in .git/objects/64/fa33d706658278b871a6e2ca66694efcadacca) is corrupt
error: github.com:artagnon/git did not send all necessary objects
Fine, my packfiles are corrupt. Let's unpack-objects by hand.
artagnon|remote-cruft:~/src/git$ mv .git/objects/pack .git/objects/pack.old
artagnon|remote-cruft+:~/src/git$ for i in
.git/objects/pack.old/*.pack; do git unpack-objects -r $i; done
artagnon|remote-cruft:~/src/git$ git fetch ram
remote: Counting objects: 101, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 92 (delta 78), reused 82 (delta 68)
Unpacking objects: 100% (92/92), done.
error: object file
.git/objects/64/fa33d706658278b871a6e2ca66694efcadacca is empty
fatal: loose object 64fa33d706658278b871a6e2ca66694efcadacca (stored
in .git/objects/64/fa33d706658278b871a6e2ca66694efcadacca) is corrupt
error: github.com:artagnon/git did not send all necessary objects
Auto packing the repository for optimum performance. You may also
run git gc manually. See git help gc for more information.
error: bad ref for refs/remotes/ram/remote-cruft
error: bad ref for refs/remotes/ram/remote-cruft
Counting objects: 161917, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (159963/159963), done.
Writing objects: 100% (161917/161917), done.
Total 161917 (delta 117725), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
error: bad ref for refs/remotes/ram/remote-cruft
Checking connectivity: 161917, done.
warning: There are
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: * rr/triangle-push-fix (2013-06-20) 9 commits - push: honor branch.*.push - SQUASH??? fix git-config push.default description - SQUASH??? minimum simple safety fix-up - t/t5528-push-default: test pushdefault workflows - t/t5528-push-default: generalize test_push_* - push: remove dead code in setup_push_upstream() - push: change `simple` to accommodate triangular workflows - config doc: rewrite push.default section - t/t5528-push-default: remove redundant test_config lines Give me some more time to perfect this. * rr/rebase-checkout-reflog (2013-06-17) 8 commits - SQUASH??? - rebase -i: use a better reflog message - rebase: use a better reflog message - checkout: respect GIT_REFLOG_ACTION - status: do not depend on rebase reflog messages - t/t2021-checkout-last: checkout - should work after a rebase finishes - wt-status: remove unused field in grab_1st_switch_cbdata - t7512: test detached from as well Waiting for a reroll. $gmane/228271. Please pick up $gmane/228371. -- Four topics are awaiting review (they're important to me in this order): - rr/for-each-ref-pretty at $gmane/227057. - rr/describe-contains-all at $gmane/228278. - rr/mixed-case-aliases at $gmane/227959. - rr/completion-word-diff at $gmane/228305. One topic is stalled: - rr/pull-autostash at $gmane/227796. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/16] Cleanup {branches,remotes}-file cruft
Hi,
This is a cleanup operation to get rid of the historical
$GIT_DIR/{branches,remotes} cruft. Mostly no-brainers that don't
deserve a second look. The ordering of the series might be somewhat
weird, but that's because it's the order in which I wrote those
patches: rebasing results in stupid conflicts that's not worth
anyone's time.
Thanks.
Ramkumar Ramachandra (16):
t/t5505-remote: modernize subshell-style of one test
t/t5505-remote: test push-refspec in branches-file
t/t5505-remote: use test_path_is_missing
t/t5505-remote: remove dependency on $origin_url
remote: remove dead code in read_branches_file()
t/t5505-remote: test url-with-# in branches-file
t/t5516-fetch-push: don't use branches-file
t/t5516-fetch-push: use test_config()
ls-remote doc: fix example invocation on git.git
ls-remote doc: rewrite repository paragraph
ls-remote doc: don't encourage use of branches-file
t/t5505-remote: modernize subshell-style of one test
t/t5505-remote: test multiple push/pull in remotes-file
t/t5510-fetch: don't use remotes-file
t/t5515-fetch-merge-logic: don't use {branches,remotes}-file
remote: deprecate read_{branches,remotes}_file
Documentation/git-ls-remote.txt | 13 ---
remote.c| 34 ++-
t/t5505-remote.sh | 75 +
t/t5510-fetch.sh| 9 ++---
t/t5515-fetch-merge-logic.sh| 28 +++
t/t5516-fetch-push.sh | 62 +++---
6 files changed, 121 insertions(+), 100 deletions(-)
--
1.8.3.1.499.g7ad3486.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/16] ls-remote doc: don't encourage use of branches-file
One outdated example encourages the use of $GIT_DIR/branches files. Replace it with an equivalent example using a remote. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-ls-remote.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 0715892..340c3ff 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -70,8 +70,8 @@ EXAMPLES $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu 5fe978a5381f1fbad26a80e682ddd2a401966740refs/heads/master c781a84b5204fb294c9ccc79f8b3baceeb32c061refs/heads/pu - $ echo http://www.kernel.org/pub/scm/git/git.git .git/branches/public - $ git ls-remote --tags public v\* + $ git remote add korg http://www.kernel.org/pub/scm/git/git.git + $ git ls-remote --tags korg v\* d6602ec5194c87b0fc87103ca4d67251c76f233arefs/tags/v0.99 f25a265a342aed6041ab0cc484224d9ca54b6f41refs/tags/v0.99.1 c5db5456ae3b0873fc659c19fafdde22313cc441refs/tags/v0.99.2 -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/16] remote: deprecate read_{branches,remotes}_file
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 8
1 file changed, 8 insertions(+)
diff --git a/remote.c b/remote.c
index 128b210..b487865 100644
--- a/remote.c
+++ b/remote.c
@@ -227,6 +227,10 @@ static void add_instead_of(struct rewrite *rewrite, const
char *instead_of)
rewrite-instead_of_nr++;
}
+/*
+ * Deprecated; provided for backward compatibility with ancient
+ * repositories. Modern Git does not encourage their use.
+ */
static void read_remotes_file(struct remote *remote)
{
FILE *f = fopen(git_path(remotes/%s, remote-name), r);
@@ -274,6 +278,10 @@ static void read_remotes_file(struct remote *remote)
fclose(f);
}
+/*
+ * Deprecated; provided for backward compatibility with ancient
+ * repositories. Modern Git does not encourage their use.
+ */
static void read_branches_file(struct remote *remote)
{
char *frag;
--
1.8.3.1.499.g7ad3486.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/16] t/t5505-remote: modernize subshell-style of one test
Since we plan to edit the test migrate a remote from named file in $GIT_DIR/remotes in later patches, modernize the subshell-style by putting the parenthesis on separate lines and indenting the body. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 93e11c8..06ed381 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -676,15 +676,17 @@ EOF test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' ' git clone one five - (cd five -git remote remove origin -mkdir -p .git/remotes -cat ../remotes_origin .git/remotes/origin -git remote rename origin origin -test_path_is_missing .git/remotes/origin -test $(git config remote.origin.url) = quux -test $(git config remote.origin.push) = refs/heads/master:refs/heads/upstream -test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin) + ( + cd five + git remote remove origin + mkdir -p .git/remotes + cat ../remotes_origin .git/remotes/origin + git remote rename origin origin + test_path_is_missing .git/remotes/origin + test $(git config remote.origin.url) = quux + test $(git config remote.origin.push) = refs/heads/master:refs/heads/upstream + test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + ) ' test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/16] t/t5515-fetch-merge-logic: don't use {branches,remotes}-file
Replace it with the equivalent gitconfig configuration, using the
results of the corresponding tests in t/t5505-remote.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5515-fetch-merge-logic.sh | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh
index dbb927d..cde44e0 100755
--- a/t/t5515-fetch-merge-logic.sh
+++ b/t/t5515-fetch-merge-logic.sh
@@ -55,27 +55,25 @@ test_expect_success setup '
git config remote.config-glob.fetch refs/heads/*:refs/remotes/rem/*
remotes=$remotes config-glob
- mkdir -p .git/remotes
- {
- echo URL: ../.git/
- echo Pull: refs/heads/master:remotes/rem/master
- echo Pull: refs/heads/one:remotes/rem/one
- echo Pull: two:remotes/rem/two
- echo Pull: refs/heads/three:remotes/rem/three
- } .git/remotes/remote-explicit
+ git config remote.remote-explicit.url ../.git/
+ git config remote.remote-explicit.fetch
refs/heads/master:remotes/rem/master
+ git config --add remote.remote-explicit.fetch
refs/heads/one:remotes/rem/one
+ git config --add remote.remote-explicit.fetch two:remotes/rem/two
+ git config --add remote.remote-explicit.fetch
refs/heads/three:remotes/rem/three
remotes=$remotes remote-explicit
- {
- echo URL: ../.git/
- echo Pull: refs/heads/*:refs/remotes/rem/*
- } .git/remotes/remote-glob
+ git config remote.remote-glob.url ../.git/
+ git config remote.remote-glob.fetch refs/heads/*:refs/remotes/rem/*
remotes=$remotes remote-glob
- mkdir -p .git/branches
- echo ../.git .git/branches/branches-default
+ git config remote.branches-default.url ../.git/
+ git config remote.branches-default.fetch
refs/heads/master:refs/heads/branches-default
+ git config remote.branches-default.push HEAD:refs/heads/master
remotes=$remotes branches-default
- echo ../.git#one .git/branches/branches-one
+ git config remote.branches-one.url ../.git/
+ git config remote.branches-one.fetch
refs/heads/one:refs/heads/branches-one
+ git config remote.branches-one.push HEAD:refs/heads/one
remotes=$remotes branches-one
for remote in $remotes ; do
--
1.8.3.1.499.g7ad3486.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/16] t/t5505-remote: test push-refspec in branches-file
The test migrate a remote from named file in $GIT_DIR/branches reads the branches-file, but only checks that the url and fetch-refspec are set correctly. Check that the push-refspec is also set correctly. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 4d5810f..38c62ec 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -698,7 +698,8 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' git remote rename origin origin ! test -f .git/branches/origin test $(git config remote.origin.url) = $origin_url - test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + test $(git config remote.origin.push) = HEAD:refs/heads/master ) ' -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/16] t/t5505-remote: use test_path_is_missing
Replace instances of ! test -f with test_path_is_missing. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 38c62ec..dcb6c2f 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -682,7 +682,7 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' ' mkdir -p .git/remotes cat ../remotes_origin .git/remotes/origin git remote rename origin origin -! test -f .git/remotes/origin +test_path_is_missing .git/remotes/origin test $(git config remote.origin.url) = $origin_url test $(git config remote.origin.push) = refs/heads/master:refs/heads/upstream test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin) @@ -696,7 +696,7 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' git remote rm origin echo $origin_url .git/branches/origin git remote rename origin origin - ! test -f .git/branches/origin + test_path_is_missing .git/branches/origin test $(git config remote.origin.url) = $origin_url test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin test $(git config remote.origin.push) = HEAD:refs/heads/master -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/16] ls-remote doc: rewrite repository paragraph
Replace the repository paragraph containing specific references to $GIT_DIR/branches and . with a generic urls-or-remotes paragraph referencing the relevant sections in the git-fetch(1) manpage. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-ls-remote.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index a24b8b6..0715892 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -48,9 +48,9 @@ OPTIONS exit without talking to the remote. repository:: - Location of the repository. The shorthand defined in - $GIT_DIR/branches/ can be used. Use . (dot) to list references in - the local repository. + The remote repository to query. This parameter can be + either a URL or the name of a remote (see the GIT URLS and + REMOTES sections of linkgit:git-fetch[1]). refs...:: When unspecified, all references, after filtering done -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/16] t/t5505-remote: test url-with-# in branches-file
Add one more test similar to migrate a remote from named file in $GIT_DIR/branches to check that a url with a # can be used to specify the branch name (as opposed to the constant master). Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index fd0a81e..93e11c8 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -702,27 +702,42 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' ) ' -test_expect_success 'remote prune to cause a dangling symref' ' +test_expect_success 'migrate a remote from named file in $GIT_DIR/branches (2)' ' git clone one seven + origin_url=$(pwd)/one + ( + cd seven + git remote rm origin + echo quux#foom .git/branches/origin + git remote rename origin origin + test_path_is_missing .git/branches/origin + test $(git config remote.origin.url) = quux + test $(git config remote.origin.fetch) = refs/heads/foom:refs/heads/origin + test $(git config remote.origin.push) = HEAD:refs/heads/foom + ) +' + +test_expect_success 'remote prune to cause a dangling symref' ' + git clone one eight ( cd one git checkout side2 git branch -D master ) ( - cd seven + cd eight git remote prune origin ) err 21 test_i18ngrep has become dangling err : And the dangling symref will not cause other annoying errors ( - cd seven + cd eight git branch -a ) 2err ! grep points nowhere err ( - cd seven + cd eight test_must_fail git branch nomore origin ) 2err grep dangling symref err -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] t/t5505-remote: test multiple push/pull in remotes-file
Extend the test migrate a remote from named file in $GIT_DIR/remotes to test that multiple Push: and Pull: lines in the remotes-file works as expected. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 06ed381..5497a23 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -671,7 +671,9 @@ test_expect_success 'rename a remote with name prefix of other remote' ' cat remotes_origin EOF URL: quux Push: refs/heads/master:refs/heads/upstream +Push: refs/heads/master:refs/heads/upstream2 Pull: refs/heads/master:refs/heads/origin +Pull: refs/heads/master:refs/heads/origin2 EOF test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' ' @@ -684,8 +686,18 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' ' git remote rename origin origin test_path_is_missing .git/remotes/origin test $(git config remote.origin.url) = quux - test $(git config remote.origin.push) = refs/heads/master:refs/heads/upstream - test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + cat push_expected -\EOF + refs/heads/master:refs/heads/upstream + refs/heads/master:refs/heads/upstream2 + EOF + cat fetch_expected -\EOF + refs/heads/master:refs/heads/origin + refs/heads/master:refs/heads/origin2 + EOF + git config --get-all remote.origin.fetch push_actual + git config --get-all remote.origin.fetch fetch_actual + test_cmp push_expected push_actual + test_cmp fetch_expected fetch_actual ) ' -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/16] ls-remote doc: fix example invocation on git.git
Under the EXAMPLES section, there is one invocation on the git.git repository that attempts to list the refs master, pu, and rc. The ref rc does not exist in today's repository, so remove it. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-ls-remote.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 774de5e..a24b8b6 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -67,10 +67,9 @@ EXAMPLES 7ceca275d047c90c0c7d5afb13ab97efdf51bd6erefs/tags/v0.99.3 c5db5456ae3b0873fc659c19fafdde22313cc441refs/tags/v0.99.2 0918385dbd9656cab0d1d81ba7453d49bbc16250refs/tags/junio-gpg-pub - $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc + $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu 5fe978a5381f1fbad26a80e682ddd2a401966740refs/heads/master c781a84b5204fb294c9ccc79f8b3baceeb32c061refs/heads/pu - b1d096f2926c4e37c9c0b6a7bf2119bedaa277cbrefs/heads/rc $ echo http://www.kernel.org/pub/scm/git/git.git .git/branches/public $ git ls-remote --tags public v\* d6602ec5194c87b0fc87103ca4d67251c76f233arefs/tags/v0.99 -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/16] t/t5505-remote: modernize subshell-style of one test
Since we plan to edit the test migrate a remote from named file in $GIT_DIR/remotes in later patches, modernize the subshell-style by putting the parenthesis on separate lines and indenting the body. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index dd10ff0..4d5810f 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -691,13 +691,15 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' ' test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' git clone one six origin_url=$(pwd)/one - (cd six -git remote rm origin -echo $origin_url .git/branches/origin -git remote rename origin origin -! test -f .git/branches/origin -test $(git config remote.origin.url) = $origin_url -test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin) + ( + cd six + git remote rm origin + echo $origin_url .git/branches/origin + git remote rename origin origin + ! test -f .git/branches/origin + test $(git config remote.origin.url) = $origin_url + test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + ) ' test_expect_success 'remote prune to cause a dangling symref' ' -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/16] remote: remove dead code in read_branches_file()
The first line of the function checks that the remote-name contains a
slash ('/'), and sets the slash variable accordingly. The only caller
of read_branches_file() is remote_get_1(); the calling codepath is
guarded by valid_remote_nick(), which checks that the remote does not
contain a slash. Therefore, the slash variable can never be set:
remove the dead code that assumes otherwise.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/remote.c b/remote.c
index e71f66d..128b210 100644
--- a/remote.c
+++ b/remote.c
@@ -276,10 +276,9 @@ static void read_remotes_file(struct remote *remote)
static void read_branches_file(struct remote *remote)
{
- const char *slash = strchr(remote-name, '/');
char *frag;
struct strbuf branch = STRBUF_INIT;
- int n = slash ? slash - remote-name : 1000;
+ int n = 1000;
FILE *f = fopen(git_path(branches/%.*s, n, remote-name), r);
char *s, *p;
int len;
@@ -299,36 +298,17 @@ static void read_branches_file(struct remote *remote)
while (isspace(p[-1]))
*--p = 0;
len = p - s;
- if (slash)
- len += strlen(slash);
p = xmalloc(len + 1);
strcpy(p, s);
- if (slash)
- strcat(p, slash);
- /*
-* With slash, e.g. git fetch jgarzik/netdev-2.6 when
-* reading from $GIT_DIR/branches/jgarzik fetches HEAD from
-* the partial URL obtained from the branches file plus
-* /netdev-2.6 and does not store it in any tracking ref.
-* #branch specifier in the file is ignored.
-*
-* Otherwise, the branches file would have URL and optionally
-* #branch specified. The master (or specified) branch is
-* fetched and stored in the local branch of the same name.
-*/
frag = strchr(p, '#');
if (frag) {
*(frag++) = '\0';
strbuf_addf(branch, refs/heads/%s, frag);
} else
strbuf_addstr(branch, refs/heads/master);
- if (!slash) {
- strbuf_addf(branch, :refs/heads/%s, remote-name);
- } else {
- strbuf_reset(branch);
- strbuf_addstr(branch, HEAD:);
- }
+
+ strbuf_addf(branch, :refs/heads/%s, remote-name);
add_url_alias(remote, p);
add_fetch_refspec(remote, strbuf_detach(branch, NULL));
/*
--
1.8.3.1.499.g7ad3486.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/16] t/t5516-fetch-push: don't use branches-file
Four tests exercising fetch and push functionality unnecessarily depend on $GIT_DIR/branches files. Modern Git does not encourage the use of those files, and the parser remote.c:read_branches_file() is only provided for backward compatibility with older repositories. We already have tests in t/t5505-remote to verify that the parser works: so, substitute the $GIT_DIR/branches configuration with an equivalent gitconfig-style configuration, using the results of those tests. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5516-fetch-push.sh | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 4691d51..6e9fa84 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -852,9 +852,11 @@ test_expect_success 'fetch with branches' ' mk_empty testrepo git branch second $the_first_commit git checkout second - echo .. testrepo/.git/branches/branch1 ( cd testrepo + test_config remote.branch1.url .. + test_config remote.branch1.fetch refs/heads/master:refs/heads/branch1 + test_config remote.branch1.push HEAD:refs/heads/master git fetch branch1 echo $the_commit commitrefs/heads/branch1 expect git for-each-ref refs/heads actual @@ -865,9 +867,11 @@ test_expect_success 'fetch with branches' ' test_expect_success 'fetch with branches containing #' ' mk_empty testrepo - echo ..#second testrepo/.git/branches/branch2 ( cd testrepo + test_config remote.branch2.url .. + test_config remote.branch2.fetch refs/heads/second:refs/heads/branch2 + test_config remote.branch2.push HEAD:refs/heads/second git fetch branch2 echo $the_first_commit commit refs/heads/branch2 expect git for-each-ref refs/heads actual @@ -879,7 +883,9 @@ test_expect_success 'fetch with branches containing #' ' test_expect_success 'push with branches' ' mk_empty testrepo git checkout second - echo testrepo .git/branches/branch1 + test_config remote.branch1.url testrepo + test_config remote.branch1.fetch refs/heads/master:refs/heads/branch1 + test_config remote.branch1.push HEAD:refs/heads/master git push branch1 ( cd testrepo @@ -891,7 +897,9 @@ test_expect_success 'push with branches' ' test_expect_success 'push with branches containing #' ' mk_empty testrepo - echo testrepo#branch3 .git/branches/branch2 + test_config remote.branch2.url testrepo + test_config remote.branch2.fetch refs/heads/branch3:refs/heads/branch2 + test_config remote.branch2.push HEAD:refs/heads/branch3 git push branch2 ( cd testrepo -- 1.8.3.1.499.g7ad3486.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/16] t/t5505-remote: remove dependency on $origin_url
In the tests migrate a remote from named file in
$GIT_DIR/{remotes,branches}, we are only checking that a configuration
is migrated successfully; it has no correspondence with whether or not
those values do something sensible with other git
operations (fetch/push). Therefore, there is no need to determine
$origin_url: just substitute it with the constant value quux.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5505-remote.sh | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index dcb6c2f..fd0a81e 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -669,21 +669,20 @@ test_expect_success 'rename a remote with name prefix of
other remote' '
'
cat remotes_origin EOF
-URL: $(pwd)/one
+URL: quux
Push: refs/heads/master:refs/heads/upstream
Pull: refs/heads/master:refs/heads/origin
EOF
test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
git clone one five
- origin_url=$(pwd)/one
(cd five
git remote remove origin
mkdir -p .git/remotes
cat ../remotes_origin .git/remotes/origin
git remote rename origin origin
test_path_is_missing .git/remotes/origin
-test $(git config remote.origin.url) = $origin_url
+test $(git config remote.origin.url) = quux
test $(git config remote.origin.push) =
refs/heads/master:refs/heads/upstream
test $(git config remote.origin.fetch) =
refs/heads/master:refs/heads/origin)
'
@@ -694,10 +693,10 @@ test_expect_success 'migrate a remote from named file in
$GIT_DIR/branches' '
(
cd six
git remote rm origin
- echo $origin_url .git/branches/origin
+ echo quux .git/branches/origin
git remote rename origin origin
test_path_is_missing .git/branches/origin
- test $(git config remote.origin.url) = $origin_url
+ test $(git config remote.origin.url) = quux
test $(git config remote.origin.fetch) =
refs/heads/master:refs/heads/origin
test $(git config remote.origin.push) =
HEAD:refs/heads/master
)
--
1.8.3.1.499.g7ad3486.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/16] t/t5510-fetch: don't use remotes-file
Replace it with the equivalent gitconfig configuration, using the
results of a test in t/t5505-remote.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5510-fetch.sh | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index fde6891..47aeac2 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -46,12 +46,9 @@ test_expect_success clone and setup child repos '
cd three
git config branch.master.remote two
git config branch.master.merge refs/heads/one
- mkdir -p .git/remotes
- {
- echo URL: ../two/.git/
- echo Pull: refs/heads/master:refs/heads/two
- echo Pull: refs/heads/one:refs/heads/one
- } .git/remotes/two
+ git config remote.two.url ../two/.git/
+ git config remote.two.fetch refs/heads/master:refs/heads/two
+ git config --add remote.two.fetch
refs/heads/one:refs/heads/one
)
git clone . bundle
git clone . seven
--
1.8.3.1.499.g7ad3486.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] apply: carefully strdup a possibly-NULL name
2901bbe (apply: free patch-{def,old,new}_name fields, 2012-03-21)
cleaned up the memory management of filenames in the patches, but
forgot that find_name_traditional() can return NULL as a way of saying
I couldn't find a name.
That NULL unfortunately gets passed into xstrdup() next, resulting in
a segfault. Use null_strdup() so as to safely propagate the null,
which will let us emit the correct error message.
Reported-by: DevHC on #git
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
builtin/apply.c | 2 +-
t/t4111-apply-subdir.sh | 14 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index faf8e30..0e9b631 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -906,7 +906,7 @@ static void parse_traditional_patch(const char *first,
const char *second, struc
patch-old_name = name;
} else {
patch-old_name = name;
- patch-new_name = xstrdup(name);
+ patch-new_name = null_strdup(name);
}
}
if (!name)
diff --git a/t/t4111-apply-subdir.sh b/t/t4111-apply-subdir.sh
index 7c39843..1618a6d 100755
--- a/t/t4111-apply-subdir.sh
+++ b/t/t4111-apply-subdir.sh
@@ -86,6 +86,20 @@ test_expect_success 'apply --index from subdir of toplevel' '
test_cmp expected sub/dir/file
'
+test_expect_success 'apply half-broken patch from subdir of toplevel' '
+ (
+ cd sub/dir
+ test_must_fail git apply -EOF
+ --- sub/dir/file
+ +++ sub/dir/file
+ @@ -1,0 +1,0 @@
+ --- file_in_root
+ +++ file_in_root
+ @@ -1,0 +1,0 @@
+ EOF
+ )
+'
+
test_expect_success 'apply from .git dir' '
cp postimage expected
cp preimage .git/file
--
1.8.3.1.664.gae9f72a
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git diff returns fatal error with core.safecrlf is set to true.
Hi, Following my previous email Tracking vendor release with Git [1][2], and the advice from Git users/developers, I'm trying to use .gitattributes to handle CRLF/LF conversion. While testing the behavor of Git regarding CRLF handling, when core.safecrlf is set to true, I've found that git diff is returning fatal: CRLF would be replaced by LF without returning any kind of diff. This make me wonder if its the correct behavor for git diff to (only) fail: It should be fatal for git add / git commit ( / git cherry-pick / ... ?), but non fatal for git diff. According to the documentation git-config(5) [3]: Git will verify if a command modifies a file in the work tree either directly or indirectly I don't thing git diff is an operation that could modify a file. Regards. 1. 1370970410-7935-1-git-send-email-ydrone...@opteya.com 2. http://thread.gmane.org/gmane.comp.version-control.git/227466 http://marc.info/?l=gitm=137097069115462w=2 3. https://www.kernel.org/pub/software/scm/git/docs/git-config.html -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git rebase fail with CRLF conversion
Hi (again), Following my previous email Tracking vendor release with Git [1][2], and the advice from Git users/developers, I'm trying to use .gitattributes to handle CRLF/LF conversion. I'm following advices from: - Dealing with line endings https://help.github.com/articles/dealing-with-line-endings - Tim's Blog, Mind the End of Your Line http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ - 7.2 Customizing Git - Git Attributes http://git-scm.com/book/ch7-2.html - gitattributes(5) Manual Page https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html While testing the behavor of Git regarding CRLF handling, I've found git rebase fail when trying to apply a commit that's going to fix/convert CRLF to LF. I'm using the following script: A file with CRLF end of line (EOL) test is added and commited, then a file .gitattributes is added and commited. The .gitattributes has a single line test text to ask git to do EOL conversion. After adding this .gitattributes file, Git start complaining about the line ending to file test. The file is fixed and commited. Then this branch is rebased on top of another parent. And here come the failures: Most of the time git rebase failed with the following error: ... First, rewinding head to replay your work on top of it... Applying: Commit raw Applying: Added git attributes Applying: Normalization Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... error: Your local changes to the following files would be overwritten by merge: test Please, commit your changes or stash them before you can merge. Aborting Failed to merge in the changes. Patch failed at 0003 Normalization ... But sometime it failed with another error: with core.safecrlf = warn: ... First, rewinding head to replay your work on top of it... Applying: Commit raw Applying: Added git attributes warning: CRLF will be replaced by LF in test. The file will have its original line endings in your working directory. Applying: Normalization fatal: unrecognized input Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0003 Normalization ... with core.safecrlf = true: ... First, rewinding head to replay your work on top of it... Applying: Commit raw Applying: Added git attributes fatal: CRLF would be replaced by LF in test. Applying: Normalization fatal: unrecognized input Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0003 Normalization ... In thoses two latter cases, running git add does not fail with a fatal error: it does nothing. I need to run touch test to make git add fail with error fatal: CRLF would be replaced by LF in test. I believe git rebase should not fail here, but more, it must not fail in a different fashion randomly. Please find in reply to this email: - a shell script to demonstrate the behavor - a patch to t0020-crlf.sh to add two rebase tests. 1. 1370970410-7935-1-git-send-email-ydrone...@opteya.com 2. http://thread.gmane.org/gmane.comp.version-control.git/227466 http://marc.info/?l=gitm=137097069115462w=2 Regards -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase fail with CRLF conversion
Hi,
Le 21.06.2013 15:41, Yann Droneaud a écrit :
I believe git rebase should not fail here, but more, it must not
fail in a different fashion randomly.
Please find in reply to this email:
- a shell script to demonstrate the behavor
Please find a shell script to test git rebase with .gitattributes text
flag
set to enable End-Of-Line (EOL) conversion from CRLF to LF, with
core.safecrlf set to warn
and to true.
Regards.
--
Yann Droneaud
OPTEYA
--8--
#! /bin/sh
set -e
LC_ALL=C
export LC_ALL
#GIT_AUTHOR_DATE=`date -R`
GIT_AUTHOR_DATE=2001-01-01 00:00:00.+00:00
GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE
export GIT_AUTHOR_DATE
export GIT_COMMITTER_DATE
# global settings
set +e
global_core_eol=`git config --global core.eol`
global_core_safecrlf=`git config --global core.safecrlf`
global_core_autocrlf=`git config --global core.autocrlf`
set -e
# archive
if test -d work; then
dir=`mktemp -d work.X`
rmdir $dir
mv work $dir
fi
mkdir work
echo ** Testing in work ***
cd work
# prepare
git init
git commit --allow-empty -m empty root commit
# local settings, might be different from the global settings
set +e
local_core_eol=`git config core.eol`
local_core_safecrlf=`git config core.safecrlf`
local_core_autocrlf=`git config core.autocrlf`
set -e
echo global core.eol = $global_core_eol
echo global core.safecrlf = $global_core_safecrlf
echo global core.autocrlf = $global_core_autocrlf
echo local core.eol= $local_core_eol
echo local core.safecrlf = $local_core_safecrlf
echo local core.autocrlf = $local_core_autocrlf
# set default configuration
git config --local core.eol native
git config --local core.safecrl warn
git config --local core.autocrlf false
echo current core.eol = `git config core.eol`
echo current core.safecrlf = `git config core.safecrlf`
echo current core.autocrlf = `git config core.autocrlf`
CRLF=\r\n
CR=\r
LF=\n
# TODO detect line ending on the current environment
if true ; then
EOL=$LF
else
EOL=$CRLF
fi
echo Create work branches
git branch import-raw master
git branch import-eol master
echo Create a branch to be used as new root later
git checkout import-eol
git commit --allow-empty -m an empty commit
file_type=
create_raw_file ()
{
# Want to test mixed EOL:
# printf Hello World 1${CRLF}Hello World 2${CRLF}${CR}Hello World
3${CRLF}Hello World 4 test
printf Hello World 1${CRLF}Hello World 2${CRLF}Hello World
3${CRLF}Hello World 4 test
file_type=`file test`
echo ::: $file_type
}
check_file ()
{
local t=`file test`
if test x$file_type != x$t ; then
file_type=$t
echo ::: $file_type
fi
}
create_git_attributes ()
{
printf test text${EOL} .gitattributes
}
#
# First test:
#
# import raw, add .gitattributes after, normalize, rebase
#
echo = BEGIN: first test =
git checkout import-raw
git reset --hard master
create_raw_file
git add test check_file
git commit -m Commit raw check_file
create_git_attributes check_file
git add .gitattributes check_file
git commit -m Added git attributes check_file
echo --- First kind of 'normalization'
#
# trick from https://help.github.com/articles/dealing-with-line-endings
#
git rm --cached test
git reset --hard check_file
git add test check_file
git commit -m Normalization
check_file
git tag norm1
echo --- Second kind of 'normalization'
git reset --hard HEAD^
check_file
create_raw_file
rm test
git checkout test check_file
git add test check_file
git commit -m Normalization
check_file
git tag norm2
echo --- Third kind of 'normalization'
git reset --hard HEAD^
check_file
create_raw_file
dos2unix test check_file
git add test check_file
git commit -m Normalization
check_file
git tag norm3
echo --- differences ? ---
git diff norm1 norm2
git diff norm1 norm3
git diff norm2 norm1
git diff norm2 norm3
git diff norm3 norm1
git diff norm3 norm2
echo --- rebase, should failed ---
git rebase import-eol || {
echo --- Expected failure to rebase on another branch ---
check_file
git status
git diff -w --stat
git diff
# just adding the file again and continue ...
git add test check_file
git rebase --continue || { echo ### failed to continue rebase ;
exit 1 ; }
check_file
}
echo --- rebase complete ---
check_file
echo = END: first test =
#
# again, with safecrlf set
#
echo = BEGIN: second test =
git config core.safecrlf true
git checkout import-raw
git reset --hard master
create_raw_file
git add test check_file
git commit -m Commit raw check_file
create_git_attributes check_file
git add .gitattributes check_file
git commit -m Added git attributes check_file
echo --- First kind of 'normalization', git add should failed
git rm --cached test
git reset --hard check_file
git add test { echo ### git add must failed ! ; exit 1 ; }
echo --- Second kind of 'normalization', git add should failed
rm
[PATCH] t0020-crlf: test rebase with text conversion and safecrlf
This patch add two tests to reproduce the problems described
in thread git rebase fail with CRLF conversion
fb20a7d711fdd218f58f1f2090b1c...@meuh.org
http://thread.gmane.org/gmane.comp.version-control.git/228613
http://marc.info/?l=gitm=137182211414404w=2
- Add and commit a file with CRLF,
- Add and commit a .gitattributes with text flag for the file,
- Convert CRLF to LF in file, commit the change,
- Rebase the whole on top of another parent
The rebase currently failed.
This scenario is repeated twice, first with core.safecrlf set to warn,
a second time with core.safecrlf set to true.
git diff will also fail when core.safecrlf is set to true
and the file is not already converted to LF.
Signed-off-by: Yann Droneaud ydrone...@opteya.com
---
t/t0020-crlf.sh | 52
1 file changed, 52 insertions(+)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 1a8f44c..12147ba 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -506,4 +506,56 @@ test_expect_success 'New CRLF file gets LF in repo' '
test_cmp alllf alllf2
'
+test_expect_success 'Prepare rebase test' '
+ test_config core.autocrlf false
+ test_config core.safecrlf warn
+ test_config core.eol native
+ git branch rebase-initial
+ git checkout -b rebase-other rebase-initial
+ git commit --allow-empty -m Another commit
+ git checkout rebase-initial
+'
+
+# git rebase will failed to apply the normalization commit
+test_expect_success 'Rebase with core.safecrlf set to warn (default)' '
+ test_config core.autocrlf false
+ test_config core.safecrlf warn
+ test_config core.eol native
+ git checkout -b rebase-warn rebase-initial
+ for w in A couple of lines ; do echo $w ; done | append_cr
rebase-warn.txt
+ git add rebase-warn.txt git commit -m Added raw text
+ echo rebase-warn.txt text .gitattributes
+ git add .gitattributes git commit -m Added .gitattributes
+ git rm --cached rebase-warn.txt git reset --hard
+ git add rebase-warn.txt git commit -m Normalized
+ git rebase rebase-other || {
+ git status git diff
+ git add rebase-warn.txt git rebase --continue ;
+ }
+'
+
+#
+# git rebase will failed to apply the normalization commit
+# additionnaly
+# git diff and git add will failed when core.safecrlf is set to true
+#
+test_expect_success 'Rebase with core.safecrlf set to true' '
+ test_config core.autocrlf false
+ test_config core.safecrlf true
+ test_config core.eol native
+ git checkout -b rebase-true rebase-initial
+ for w in Another couple of lines ; do echo $w ; done | append_cr
rebase-true.txt
+ git add rebase-true.txt git commit -m Added raw text
+ echo rebase-true.txt text .gitattributes
+ git add .gitattributes git commit -m Added .gitattributes
+ git diff || git add rebase-true.txt ||
+ for w in Another couple of lines ; do echo $w ; done rebase-true.txt
+ git add rebase-true.txt git commit -m Normalized
+ git rebase rebase-other || {
+ git status git diff || git add rebase-true.txt ||
+ for w in Another couple of lines ; do echo $w ; done
rebase-true.txt
+ git add rebase-true.txt git rebase --continue ;
+ }
+'
+
test_done
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0020-crlf: test rebase with text conversion and safecrlf
Le 21.06.2013 16:15, Yann Droneaud a écrit : This patch add two tests to reproduce the problems described in thread git rebase fail with CRLF conversion fb20a7d711fdd218f58f1f2090b1c...@meuh.org http://thread.gmane.org/gmane.comp.version-control.git/228613 http://marc.info/?l=gitm=137182211414404w=2 - Add and commit a file with CRLF, - Add and commit a .gitattributes with text flag for the file, - Convert CRLF to LF in file, commit the change, - Rebase the whole on top of another parent The rebase currently failed. This scenario is repeated twice, first with core.safecrlf set to warn, a second time with core.safecrlf set to true. Note: those two tests might failed as described in message git rebase fail with CRLF conversion fb20a7d711fdd218f58f1f2090b1c...@meuh.org http://thread.gmane.org/gmane.comp.version-control.git/228613 http://marc.info/?l=gitm=137182211414404w=2 I haven't found a testcase to reproduce the same exact failure at will. So this patch should probably not used asis until the two kind of errors can be reproduced. Additionnaly, It should also be tested on a CRLF system (Windows). git diff will also fail when core.safecrlf is set to true and the file is not already converted to LF. It might be a test on its own. Regards -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase fail with CRLF conversion
Le 21.06.2013 15:41, Yann Droneaud a écrit : In thoses two latter cases, running git add does not fail with a fatal error: it does nothing. I need to run touch test to make git add fail with error fatal: CRLF would be replaced by LF in test. While searching on the Internet, I've found other people complaining of a similar error http://stackoverflow.com/questions/5074136/git-rebase-fails-your-local-changes-to-the-following-files-would-be-overwritte The workaround, git config --global core.trustctime false, might suggest there's a race somewhere while rebasing. BTW, I forgot to describe my environnment: - GNU/Linux - Fedora 18 x86_64 - git version 1.8.1.4 - git version 1.8.3.1.448.gfb7dfaa I believe git rebase should not fail here, but more, it must not fail in a different fashion randomly. Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] Cleanup {branches,remotes}-file cruft
Ramkumar Ramachandra artag...@gmail.com writes:
This is a cleanup operation to get rid of the historical
$GIT_DIR/{branches,remotes} cruft. Mostly no-brainers that don't
deserve a second look.
Only reacting to no-brainer.
The last time I hinted removal of .git/branches/, Andrew Morton
reminded me that there are those who use Git primarily to fetch from
many dozens of other people's branches, to maintain his own quilt
patch series on top of, and never push anything back. To them,
being able to say
$ echo the-repository-url#the-branch .git/branches/the-subsys
$ rm .git/branches/the-subsys
has been a much easier and simpler way than git config. The only
thing they do with them is essentially:
$ git fetch the-subsys
... use FETCH_HEAD to integrate it to a larger whole
... against which his remaining quilt queue is rebuilt
I myself thought that replacing the established work process of
these people to the one that instead uses git config should be
simple enough even back then, and in the longer term, these old
mechanisms will become disused so that we can remove them, but
deciding _when_ is the good time is not a no-brainer at all.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] status: display the SHA1 of the commit being currently processed
Johannes Sixt j.s...@viscovery.net writes: Am 6/20/2013 20:11, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: But you can't have this string: Splitting a commit while rebasing branch '%2$s' on '%3$s'. neither in the template nor in the translation, because the numbers must begin at 1 (and must be used without gaps). Did any message we saw in the patch (and the discussion to possibly improve it) need to have such a format string, or are you pointing out a common gotcha we may want to warn translators about in po/README? I took the example from Peter's message earlier in this thread: http://thread.gmane.org/gmane.comp.version-control.git/228062/focus=228064 Yeah, that one would not work. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git diff returns fatal error with core.safecrlf is set to true.
Yann Droneaud ydrone...@opteya.com writes: While testing the behavor of Git regarding CRLF handling, when core.safecrlf is set to true, I've found that git diff is returning fatal: CRLF would be replaced by LF without returning any kind of diff. This make me wonder if its the correct behavor for git diff to (only) fail: It should be fatal for git add / git commit ( / git cherry-pick / ... ?), but non fatal for git diff. Yeah, I agree. This is a diff between something and the working tree file, right? It needs to convert from the working tree representation to the canonical repository representation before doing the actual comparison, and most likely the same helper function that is reused for the check-in codepath, which needs to error out, is erroring out after finding an input in your working tree that cannot safely round-trip between LF/CRLF world. The helper may want to learn a way to be told to demote that error to a warning. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: Four topics are awaiting review (they're important to me in this order): - rr/for-each-ref-pretty at $gmane/227057. No comment on this at this moment. - rr/describe-contains-all at $gmane/228278. This may overlap with a topic in flight (but I didn't look at it). - rr/mixed-case-aliases at $gmane/227959. Personally, not just uninterested but moderately against. - rr/completion-word-diff at $gmane/228305. This was missed in the noise; obviously good and will pick up. I do not think I am the most qualified reviewer in some of the areas they touch, I do not want to be the only one who is reviewing patches here, and I am personally not very much interested in seeing these topics in Git, so I've been waiting if somebody else shows interest and starts reviewing. Which is not happening, so perhaps nobody is interested in them? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] clone: regression in error messages in master
Jeff King p...@peff.net writes: Note that I haven't thought too hard about this; there may be a way to detect for specific operations that we were expecting more data from the helper and didn't get it. But even if we do want to go that route, I think reverting the change to recvline_fh is probably going to be the first step. Yeah, I agree with that assessment. Will queue. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] web--browse: support /usr/bin/cygstart on Cygwin
Yaakov (Cygwin/X) yselkow...@users.sourceforge.net writes: From: Yaakov Selkowitz yselkow...@users.sourceforge.net While both GUI and console Cygwin browsers do exist, anecdotal evidence suggests most users rely on their native Windows browser. cygstart, which is a long-standing part of the base Cygwin installation, will cause the page to be opened in the default Windows browser (the one registered to open .html files). Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net Will queue and wait for somebody from Cygwin land to comment. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: - rr/describe-contains-all at $gmane/228278. This may overlap with a topic in flight (but I didn't look at it). Let me know if I can do anything to make it easier for you. I'm quite excited about this one. - rr/mixed-case-aliases at $gmane/227959. Personally, not just uninterested but moderately against. Okay, but I'd like an explanation. I do not think I am the most qualified reviewer in some of the areas they touch, I do not want to be the only one who is reviewing patches here, and I am personally not very much interested in seeing these topics in Git, so I've been waiting if somebody else shows interest and starts reviewing. Which is not happening, so perhaps nobody is interested in them? I don't know what happened. I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Everyone must share the burden of review, and I try to do my bit. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-remote-hg: Fix . at end of ref
Any Mercurial tag/branch/bookmark that ended with a period would be
rejected by fast-import. The repository could be cloned, but any
further fetch would fail.
Use a similar trick to the space handling, but only when the period is
at the end of the ref.
Probably need a more general solution to this problem.
Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com
---
contrib/remote-helpers/git-remote-hg | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..7fa6cd7 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -78,9 +78,11 @@ def hgbin(n):
return node.bin(n)
def hgref(ref):
+ref = re.sub('_\._$', '.', ref)
return ref.replace('___', ' ')
def gitref(ref):
+ref = re.sub('\.$', '_._', ref)
return ref.replace(' ', '___')
def check_version(*check):
--
1.8.3.1.636.g893104c
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] Cleanup {branches,remotes}-file cruft
Junio C Hamano wrote: The last time I hinted removal of .git/branches/, Andrew Morton reminded me that there are those who use Git primarily to fetch from many dozens of other people's branches, to maintain his own quilt patch series on top of, and never push anything back. To them, being able to say $ echo the-repository-url#the-branch .git/branches/the-subsys $ rm .git/branches/the-subsys has been a much easier and simpler way than git config. The only thing they do with them is essentially: $ git fetch the-subsys ... use FETCH_HEAD to integrate it to a larger whole ... against which his remaining quilt queue is rebuilt Interesting. A cheap alias for a URL + branch that can be added/removed very easily. I suppose it's worth keeping around. I myself thought that replacing the established work process of these people to the one that instead uses git config should be simple enough even back then, and in the longer term, these old mechanisms will become disused so that we can remove them, but deciding _when_ is the good time is not a no-brainer at all. Oh, this series is not about removing the feature: it's about removing dead code, testing the feature properly, and not mentioning it in obscure places. It is a prerequisite for removal, if we desire to do that at some later point. After your explanation, I think everything but [16/16] is fine. [16/16] adds a comment about deprecation; we should tweak/drop it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Ramkumar Ramachandra artag...@gmail.com writes:
$ ~/src/git
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
So fsync() and close() thought that the filesystem stored this loose
object safely, but it turns out that the data is not on disk.
artagnon|remote-cruft*+:~/src/git$ rm
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
As you know it is empty, removing (as long as you do not forget what
the object name was, which may later become useful when untangling
the mess further) does not hurt very much.
artagnon|remote-cruft*+:~/src/git$ git prune
artagnon|remote-cruft*+:~/src/git$ git status
fatal: bad object HEAD
fatal: bad object HEAD
And the value in the HEAD was???
artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
artagnon|master*+=:~/src/git$ git status
## master
MM Documentation/git-ls-remote.txt
MM remote.c
MM t/t5505-remote.sh
MM t/t5510-fetch.sh
MM t/t5515-fetch-merge-logic.sh
MM t/t5516-fetch-push.sh
?? lib/
?? outgoing/
That status is completely bogus, by the way.
... which may suggest that your index file may have been corrupted
on the filesystem.
artagnon|master*+=:~/src/git$ git reset --hard
... and using that known-to-be-corrupt index, the working tree state
is discarded.
artagnon|master*+=:~/src/git$ git checkout remote-cruft
fatal: reference is not a tree: remote-cruft
artagnon|master=:~/src/git$ git reflog
21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
refs/heads/remote-cruft
What happened to the rest of my reflog?!
On the filesystem known to not record the last consistent state of
the repository, the answer to that question may be rather obvious,
no?
artagnon|master=:~/src/git$ git branch -D remote-cruft
error: Couldn't look up commit object for 'refs/heads/remote-cruft'
The command would want to report what was at the tip, so it is
understandable it may want to look up that commit before removing
the ref.
artagnon|master=:~/src/git$ rm .git/refs/heads/remote-cruft
artagnon|master=:~/src/git$ git checkout -b remote-cruft
Switched to a new branch 'remote-cruft'
Huh? What happened to my upstream?
artagnon|remote-cruft:~/src/git$ git branch -u ram/remote-cruft
warning: ignoring broken ref refs/remotes/ram/remote-cruft.
So remotes/ram/remote-cruft is also broken.
Fine, let's fetch.
Why?
fetch walks the ancestry graph on both ends to minimize transfers.
It's not something you would expect to work when you know refs at
your end does not even record what you do have. It _may_ appear to
work if your refs are intact but you are missing objects, as they
will not be transferred again from the good copy if you let your
repository's ref claim that you have _all_ objects behind it when
you actually don't.
What would have been a better starting point to untangle is to make
a separate clone, pretending as if this repository did not even
exist, and copy the resulting packfile into this repository. That
would at least give you a known good copies of objects that you
already have pushed out.
And the next step would have been (without doing any of the above
remove this branch, recreate this one anew) to compare the tips
of refs in this broken repository and the clone. The same ones you
can trust, and different ones you dig further.
Was I being stupid, or is fixing corrupted repositories really this
non-trivial? Comments appreciated.
I think Let's fetch first was the step that took you in a wrong
direction that requires unnecessary work.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fast-import: fix ls command with empty path
Jonathan Nieder jrnieder at gmail.com writes: After sleeping on it, here are two patches for 'maint'. One plugs a memory leak. The other makes my above comment actually true, so trying to use this missing feature results in an error message that can help the frontend author instead of the silently broken conversion Andrew found. Then we can carefully add 'ls ' support in 1.7.11. The support for 'ls ' was nevre actually added, was it? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] Cleanup {branches,remotes}-file cruft
Junio C Hamano gits...@pobox.com writes: I myself thought that replacing the established work process of these people to the one that instead uses git config should be simple enough even back then, and in the longer term, these old mechanisms will become disused so that we can remove them, but deciding _when_ is the good time is not a no-brainer at all. I do not fundamentally have a strong objection against deprecation of these older mechanisms, if the removal is aimed to coincide with a major version bump, like Git 2.0. It however needs to be very well advertised, with clear instruction to help migrate people's workflow and scripts to the mechanism that will survive the purge (i.e. git config). We do not want to repeat the We have advertised that 'git-foo' will stop working at v1.6.0 for 6 months since v1.5.4 release notes, but people complained loudly only after it happend. fiasco again for something minor like this. I say minor only because I think the cost of keeping these old mechanisms alive is very low (if it is a heavy burden on the maintenance, please tell me and how). So from my point of view, a proposal to remove them has an almost no benefit vs potentially very high cost of having to break many people who are silently happily using them; not a very good benefit/cost ratio. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Junio C Hamano wrote:
$ ~/src/git
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
So fsync() and close() thought that the filesystem stored this loose
object safely, but it turns out that the data is not on disk.
Where should I start digging if I want to fix this? Actually you just
need to tell me how to build reduced-case corruptions to test: I can
trace and figure out the rest.
artagnon|remote-cruft*+:~/src/git$ git prune
artagnon|remote-cruft*+:~/src/git$ git status
fatal: bad object HEAD
fatal: bad object HEAD
And the value in the HEAD was???
ref: refs/heads/remote-cruft. That's why I included my prompt :)
artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
artagnon|master*+=:~/src/git$ git status
## master
MM Documentation/git-ls-remote.txt
MM remote.c
MM t/t5505-remote.sh
MM t/t5510-fetch.sh
MM t/t5515-fetch-merge-logic.sh
MM t/t5516-fetch-push.sh
?? lib/
?? outgoing/
That status is completely bogus, by the way.
... which may suggest that your index file may have been corrupted
on the filesystem.
Yeah, my question pertains to why is the index half-corrupted. Is
there no checksum to say index corrupted; do not display bogus
nonsense?
artagnon|master*+=:~/src/git$ git checkout remote-cruft
fatal: reference is not a tree: remote-cruft
artagnon|master=:~/src/git$ git reflog
21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
refs/heads/remote-cruft
What happened to the rest of my reflog?!
On the filesystem known to not record the last consistent state of
the repository, the answer to that question may be rather obvious,
no?
I didn't understand. What does .git/logs/HEAD have to do with any of
this? Why is it truncated?
artagnon|master=:~/src/git$ git branch -D remote-cruft
error: Couldn't look up commit object for 'refs/heads/remote-cruft'
The command would want to report what was at the tip, so it is
understandable it may want to look up that commit before removing
the ref.
I would have expected it to display a warning and remove the ref
anyway. Or error out, and override with a force-flag?
Fine, let's fetch.
Why?
fetch walks the ancestry graph on both ends to minimize transfers.
It's not something you would expect to work when you know refs at
your end does not even record what you do have. It _may_ appear to
work if your refs are intact but you are missing objects, as they
will not be transferred again from the good copy if you let your
repository's ref claim that you have _all_ objects behind it when
you actually don't.
Right. I expected it to figure out that I have a broken history and
fetch everything (which is what happened the second time, no?).
What would have been a better starting point to untangle is to make
a separate clone, pretending as if this repository did not even
exist, and copy the resulting packfile into this repository. That
would at least give you a known good copies of objects that you
already have pushed out.
Yeah, I deliberately avoided doing that: apart from the config and
refs, I had no real unpushed work in ~/src/git anyway (I push _very_
frequently, which explains my resolve HEAD early in current patch).
The most important part of what I did was running unpack-objects by
hand: that fixed everything. I shouldn't have had to run that by hand
though: why isn't there an in-built way to unpack everything, remove
corruptions, and repack the good stuff?
And the next step would have been (without doing any of the above
remove this branch, recreate this one anew) to compare the tips
of refs in this broken repository and the clone. The same ones you
can trust, and different ones you dig further.
Right. I didn't have local data in this case, so I didn't bother.
Was I being stupid, or is fixing corrupted repositories really this
non-trivial? Comments appreciated.
I think Let's fetch first was the step that took you in a wrong
direction that requires unnecessary work.
This was mainly a learning exercise for me: I wanted to see how good
git was at working with corrupted repositories. I did my surgery
fairly quickly, and avoided large network transfers (I have a slow
connection).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. I actually think all the usual suspects (I could name them, but I wouldn't---you know who you are) are doing a reasonably good job on patches that touch parts of the system that matter. Patches on the fringes (e.g. stuff in contrib/) may need a bit more love, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
t/t1402-check-ref-format.sh fails with bash-3.0
Hi,
With bash-3.0 (NOTE: CentOS 4's /bin/sh is actually a symlink to bash 3.0),
t/t1402-check-ref-format.sh failed.
Here is output.
% ~/bash-3.0.16/bin/bash --version
GNU bash, version 3.00.16(2)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
% cd ~/git/t
% ~/bash-3.0.16/bin/bash t1402-check-ref-format.sh
ok 1 - ref name '' is invalid
ok 2 - ref name '/' is invalid
ok 3 - ref name '/' is invalid with options --allow-onelevel
ok 4 - ref name '/' is invalid with options --normalize
ok 5 - ref name '/' is invalid with options --allow-onelevel --normalize
ok 6 - ref name 'foo/bar/baz' is valid
ok 7 - ref name 'foo/bar/baz' is valid with options --normalize
ok 8 - ref name 'refs///heads/foo' is invalid
ok 9 - ref name 'refs///heads/foo' is valid with options --normalize
ok 10 - ref name 'heads/foo/' is invalid
ok 11 - ref name '/heads/foo' is invalid
ok 12 - ref name '/heads/foo' is valid with options --normalize
ok 13 - ref name '///heads/foo' is invalid
ok 14 - ref name '///heads/foo' is valid with options --normalize
ok 15 - ref name './foo' is invalid
ok 16 - ref name './foo/bar' is invalid
ok 17 - ref name 'foo/./bar' is invalid
ok 18 - ref name 'foo/bar/.' is invalid
ok 19 - ref name '.refs/foo' is invalid
ok 20 - ref name 'heads/foo..bar' is invalid
ok 21 - ref name 'heads/foo?bar' is invalid
ok 22 - ref name 'foo./bar' is valid
ok 23 - ref name 'heads/foo.lock' is invalid
ok 24 - ref name 'heads///foo.lock' is invalid
ok 25 - ref name 'foo.lock/bar' is invalid
ok 26 - ref name 'foo.lock///bar' is invalid
ok 27 - ref name 'heads/foo@bar' is valid
ok 28 - ref name 'heads/v@{ation' is invalid
ok 29 - ref name 'heads/foo\bar' is invalid
ok 30 - ref name 'heads/foo ' is invalid
not ok 31 - ref name 'heads/foo' is invalid
#
# test_must_fail git check-ref-format 'heads/foo'
#
ok 32 - ref name 'heads/fuß' is valid
ok 33 - ref name 'heads/*foo/bar' is invalid with options --refspec-pattern
ok 34 - ref name 'heads/foo*/bar' is invalid with options --refspec-pattern
ok 35 - ref name 'heads/f*o/bar' is invalid with options --refspec-pattern
ok 36 - ref name 'foo' is invalid
ok 37 - ref name 'foo' is valid with options --allow-onelevel
ok 38 - ref name 'foo' is invalid with options --refspec-pattern
ok 39 - ref name 'foo' is valid with options --refspec-pattern --allow-onelevel
ok 40 - ref name 'foo' is invalid with options --normalize
ok 41 - ref name 'foo' is valid with options --allow-onelevel --normalize
ok 42 - ref name 'foo/bar' is valid
ok 43 - ref name 'foo/bar' is valid with options --allow-onelevel
ok 44 - ref name 'foo/bar' is valid with options --refspec-pattern
ok 45 - ref name 'foo/bar' is valid with options --refspec-pattern
--allow-onelevel
ok 46 - ref name 'foo/bar' is valid with options --normalize
ok 47 - ref name 'foo/*' is invalid
ok 48 - ref name 'foo/*' is invalid with options --allow-onelevel
ok 49 - ref name 'foo/*' is valid with options --refspec-pattern
ok 50 - ref name 'foo/*' is valid with options --refspec-pattern
--allow-onelevel
ok 51 - ref name '*/foo' is invalid
ok 52 - ref name '*/foo' is invalid with options --allow-onelevel
ok 53 - ref name '*/foo' is valid with options --refspec-pattern
ok 54 - ref name '*/foo' is valid with options --refspec-pattern
--allow-onelevel
ok 55 - ref name '*/foo' is invalid with options --normalize
ok 56 - ref name '*/foo' is valid with options --refspec-pattern --normalize
ok 57 - ref name 'foo/*/bar' is invalid
ok 58 - ref name 'foo/*/bar' is invalid with options --allow-onelevel
ok 59 - ref name 'foo/*/bar' is valid with options --refspec-pattern
ok 60 - ref name 'foo/*/bar' is valid with options --refspec-pattern
--allow-onelevel
ok 61 - ref name '*' is invalid
ok 62 - ref name '*' is invalid with options --allow-onelevel
ok 63 - ref name '*' is invalid with options --refspec-pattern
ok 64 - ref name '*' is valid with options --refspec-pattern --allow-onelevel
ok 65 - ref name 'foo/*/*' is invalid with options --refspec-pattern
ok 66 - ref name 'foo/*/*' is invalid with options --refspec-pattern
--allow-onelevel
ok 67 - ref name '*/foo/*' is invalid with options --refspec-pattern
ok 68 - ref name '*/foo/*' is invalid with options --refspec-pattern
--allow-onelevel
ok 69 - ref name '*/*/foo' is invalid with options --refspec-pattern
ok 70 - ref name '*/*/foo' is invalid with options --refspec-pattern
--allow-onelevel
ok 71 - ref name '/foo' is invalid
ok 72 - ref name '/foo' is invalid with options --allow-onelevel
ok 73 - ref name '/foo' is invalid with options --refspec-pattern
ok 74 - ref name '/foo' is invalid with options --refspec-pattern
--allow-onelevel
ok 75 - ref name '/foo' is invalid with options --normalize
ok 76 - ref name '/foo' is valid with options --allow-onelevel --normalize
ok 77 - ref name '/foo' is invalid with options --refspec-pattern --normalize
ok 78 - ref name '/foo' is valid with options --refspec-pattern
--allow-onelevel --normalize
ok 79 - check-ref-format --branch
Re: HTTP tests fail on OS X
On Jun 21, 2013, at 12:49 AM, Jeff King p...@peff.net wrote: I'm not sure what else to look at...I guess try ratcheting up the debugging/log level on your failing copy and see if it prints anything useful. I found this error in the error.log: [Fri Jun 21 12:59:59 2013] [emerg] (2)No such file or directory: Couldn't create accept lock (/private/var/run/accept.lock.64288) (5) Annoying that httpd returns before it tries to create the lock. Without the IfVersion directive, it creates the lock in the ./httpd directory instead. Not sure why apache is doing that, it's very irritating. ~~ Brian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [submodule] Remove duplicate call to set_rev_name
Heiko Voigt hvo...@hvoigt.net writes: Hi, On Mon, Jun 17, 2013 at 11:55:36AM +0200, Fredrik Gustafsson wrote: set_rev_name is a possible expensive operation. If a submodule has changes in it, set_rev_name was called twice. Solution is to move set_rev_name so it's only called once, no matter the codepath taken. Looks good to me. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] clone: regression in error messages in master
John Szakmeister j...@szakmeister.net writes: On Thu, Jun 20, 2013 at 9:16 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, So this should explain the problem: # using v1.8.3.1 $ git clone https://google.com Cloning into 'google.com'... fatal: repository 'https://google.com/' not found # using master $ git clone https://google.com Cloning into 'google.com'... fatal: repository 'https://google.com/' not found fatal: Reading from helper 'git-remote-https' failed I can see where this is confusing, but can also see how it's useful information to have. On clone, it's probably not that useful since you're looking right at the url, but I could see that information being more useful on a pull or push with the default arguments (when the source and destination aren't quite as obvious). The extra error messages is not the first one, but the last one, and the suggested revert is a proposal to remove the latter, not the repository $URL not found. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. Observer bias. To verify either claim, could you run some stats on the ML archives [1] and report the results? [1]: I lost the copy Peff gave me because I kept it locally. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
On Fri, Jun 21, 2013 at 7:13 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Junio C Hamano wrote: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. Observer bias. To verify either claim, could you run some stats on the ML archives [1] and report the results? Do we really need that ? Flaming generates lots of useless discussions that would be difficult to interpret/extract from your numbers. I think we should focus on improving what is left to improve. That is of course merely my humble opinion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HTTP tests fail on OS X
On Fri, Jun 21, 2013 at 01:03:40PM -0400, Brian Gernhardt wrote: On Jun 21, 2013, at 12:49 AM, Jeff King p...@peff.net wrote: I'm not sure what else to look at...I guess try ratcheting up the debugging/log level on your failing copy and see if it prints anything useful. I found this error in the error.log: [Fri Jun 21 12:59:59 2013] [emerg] (2)No such file or directory: Couldn't create accept lock (/private/var/run/accept.lock.64288) (5) Hmm. I am far from an apache expert, but I believe that is what would happen if the LockFile directive was not there at all. IOW, it seems like your apache is treating IfVersion 2.4 as false. Which seems weird to me. It's possible I'm using IfVersion wrong, though it does seem to work for me elsewhere. IfVersion comes from mod_version. I assume that if it were not loaded, apache would complain about the directive entirely. But it's true that we don't load it until later. Maybe try moving the IfVersion/Lockfile stanza down below the mod_version LoadModule line? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HTTP tests fail on OS X
On Jun 21, 2013, at 2:03 PM, Jeff King p...@peff.net wrote: IfVersion comes from mod_version. I assume that if it were not loaded, apache would complain about the directive entirely. But it's true that we don't load it until later. Maybe try moving the IfVersion/Lockfile stanza down below the mod_version LoadModule line? Apache is apparently overly accepting. Moving the IfVersion below all the IfModules fixes it. ~~ Brian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] lib-httpd/apache.conf: check version only after mod_version loads
On Fri, Jun 21, 2013 at 02:08:49PM -0400, Brian Gernhardt wrote: On Jun 21, 2013, at 2:03 PM, Jeff King p...@peff.net wrote: IfVersion comes from mod_version. I assume that if it were not loaded, apache would complain about the directive entirely. But it's true that we don't load it until later. Maybe try moving the IfVersion/Lockfile stanza down below the mod_version LoadModule line? Apache is apparently overly accepting. Moving the IfVersion below all the IfModules fixes it. Cool. I think the patch should look like the one below, then. Just to double-check that I have explained the issue correctly, can you share the output of apache2 -l? Mine has: $ apache2 -l Compiled in modules: core.c mod_log_config.c mod_logio.c mod_version.c prefork.c http_core.c mod_so.c which explains why it works here. I'm assuming you will not have mod_version.c compiled in. -- 8 -- Subject: lib-httpd/apache.conf: check version only after mod_version loads Commit 0442743 introduced an IfVersion directive near the top of the apache config file. However, at that point we have not yet checked for and loaded the mod_version module. This means that the directive will behave oddly if mod_version is dynamically loaded, failing to match when it should. We can fix this by moving the whole block below the LoadModule directive for mod_version. Reported-by: Brian Gernhardt br...@gernhardtsoftware.com Signed-off-by: Jeff King p...@peff.net --- t/lib-httpd/apache.conf | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf index 56ae548..dd17e3a 100644 --- a/t/lib-httpd/apache.conf +++ b/t/lib-httpd/apache.conf @@ -1,7 +1,4 @@ ServerName dummy ServerName dummy -IfVersion 2.4 -LockFile accept.lock -/IfVersion PidFile httpd.pid DocumentRoot www LogFormat %h %l %u %t \%r\ %s %b common @@ -26,6 +23,10 @@ ErrorLog error.log LoadModule version_module modules/mod_version.so /IfModule +IfVersion 2.4 +LockFile accept.lock +/IfVersion + IfVersion 2.1 IfModule !mod_auth.c LoadModule auth_module modules/mod_auth.so -- 1.8.3.rc2.14.g7eee6b3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lib-httpd/apache.conf: check version only after mod_version loads
On Jun 21, 2013, at 2:12 PM, Jeff King p...@peff.net wrote: On Fri, Jun 21, 2013 at 02:08:49PM -0400, Brian Gernhardt wrote: On Jun 21, 2013, at 2:03 PM, Jeff King p...@peff.net wrote: IfVersion comes from mod_version. I assume that if it were not loaded, apache would complain about the directive entirely. But it's true that we don't load it until later. Maybe try moving the IfVersion/Lockfile stanza down below the mod_version LoadModule line? Apache is apparently overly accepting. Moving the IfVersion below all the IfModules fixes it. Cool. I think the patch should look like the one below, then. Basically identical to what I've done, you're just faster to the actual patch. :-D +1 Just to double-check that I have explained the issue correctly, can you share the output of apache2 -l? Mine has: $ apache2 -l Compiled in modules: core.c mod_log_config.c mod_logio.c mod_version.c prefork.c http_core.c mod_so.c which explains why it works here. I'm assuming you will not have mod_version.c compiled in. Indeed I do not. $ httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lib-httpd/apache.conf: check version only after mod_version loads
On Fri, Jun 21, 2013 at 02:15:39PM -0400, Brian Gernhardt wrote: Cool. I think the patch should look like the one below, then. Basically identical to what I've done, you're just faster to the actual patch. :-D I started writing the rationale immediately after making the suggestion, before you responded. Lucky for me my guess turned out to be right. :) which explains why it works here. I'm assuming you will not have mod_version.c compiled in. Indeed I do not. $ httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c Makes sense. Thanks for the bug report. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: ... I've noticed a significant decline in list-reviews in general: a lot of good code on the list hasn't been reviewed. Hmph, I do not particularly see that happening. Observer bias. To verify either claim, could you run some stats on the ML archives [1] and report the results? Unfortunately, I tend to become bottleneck more often than you do, so I do not think that would be a good use of my time. Which ones went unreviewed that are of high value? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] remote: Add warnings about mixin --mirror and other remotes
Dennis Kaarsemaker den...@kaarsemaker.net writes:
When cloning a repo with --mirror, and adding more remotes later,
Even though --mirror is not the only way to trigger this, I think it
is good to mention it because it is the most common way to do so.
get_stale_heads for origin will mark all refs from other repos as stale.
As Peff already said, that is only one symptom. Another is git
fetch from origin and then git fetch another can try to overwrite
the same ref in refs/remotes/* hierarchy. We should say what we are
avoiding upfront, not just one of the consequences of the bad thing
we are avoiding.
... more remotes later, we would end up with fetch refspecs
from different remotes trying to overwrite the same ref for
their remote tracking purposes.
This can cause confusion (e.g. where did
refs/remotes/peff/master come from? Is it a copy of the
master branch of remote 'peff', or does our mirror origin
have a remote tracking branch for a remote it calls 'peff',
which may not be related to our 'peff', and we just got a
straight copy from it?) and can cause remote prune to
misbehave.
or something like that.
Add a warning to the documentation, and warn the user when we detect
such things during git remote add.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
Documentation/git-remote.txt | 6 +-
builtin/remote.c | 17 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 581bb4c..d7457df 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -71,7 +71,11 @@ When a fetch mirror is created with `--mirror=fetch`, the
refs will not
be stored in the 'refs/remotes/' namespace, but rather everything in
'refs/' on the remote will be directly mirrored into 'refs/' in the
local repository. This option only makes sense in bare repositories,
-because a fetch would overwrite any local commits.
+because a fetch would overwrite any local commits. If you want to add extra
+remotes to a repository created with `--mirror=fetch`, you will need to
change
+the configuration of the mirrored remote to fetch only `refs/heads/*`,
+otherwise `git remote prune remote` will remove all branches for the extra
+remotes.
+
When a push mirror is created with `--mirror=push`, then `git push`
will always behave as if `--mirror` was passed.
diff --git a/builtin/remote.c b/builtin/remote.c
index 5e54d36..a4f9cb8 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -112,6 +112,21 @@ enum {
#define MIRROR_PUSH 2
#define MIRROR_BOTH (MIRROR_FETCH|MIRROR_PUSH)
+static int check_overlapping_refspec(struct remote *remote, void *priv)
It is customery to call that cb_data (i.e. data for the callback) in
our codebase.
+{
+ char *refspec = priv;
You are passing only the RHS of the refspec, so this variable name
is confusing to the reader. Perhaps dst, as you will be comparing
with .dst which is RHS of the fetch refspec for the remotes?
+ int i;
+ for (i = 0; i remote-fetch_refspec_nr; i++) {
+ if(strcmp(refspec, remote-fetch[i].dst)
Style (have SP between if and open paren).
+(!fnmatch(refspec, remote-fetch[i].dst, 0) ||
+ !fnmatch(remote-fetch[i].dst, refspec, 0))) {
Does .dst always exist and is never a NULL? My quick scan of
remote.c::parse_refspec_internal() tells me otherwise.
Also what are you matching with what? refs/* against refs/remotes/origin/*?
What if remote-fetch[i] is not a wildcarded refspec, e.g.
[remote origin]
fetch = +refs/heads/master:refs/heads/origin
fetch = +refs/heads/next:refs/remotes/origin/next
You would want to check for equality in such a case against the RHS
of the refspeec you have.
+ warning(_(Overlapping refspecs detected: '%s' and
'%s'),
+ refspec, remote-fetch[i].dst);
We know which remote is the offending one, so we can afford to be
more helpful to the user and say which existing remote's fetch
refspec overlaps with the one the user is attempting to add.
+ }
+ }
+ return 0;
+}
+
static int add_branch(const char *key, const char *branchname,
const char *remotename, int mirror, struct strbuf *tmp)
{
@@ -123,6 +138,8 @@ static int add_branch(const char *key, const char
*branchname,
else
strbuf_addf(tmp, refs/heads/%s:refs/remotes/%s/%s,
branchname, remotename, branchname);
+
+ for_each_remote(check_overlapping_refspec, strchr((const
char*)tmp-buf, ':') + 1);
Do you need this cast???
return git_config_set_multivar(key, tmp-buf, ^$, 0);
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
[PATCH 1/5] t/lib-t6000: style fixes
Mostly fixes to initial indentation with 8-SP (they should be HT)
and wrapping long lines.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/lib-t6000.sh | 87 +++---
1 file changed, 40 insertions(+), 47 deletions(-)
diff --git a/t/lib-t6000.sh b/t/lib-t6000.sh
index ea25dd8..102d567 100644
--- a/t/lib-t6000.sh
+++ b/t/lib-t6000.sh
@@ -1,55 +1,50 @@
: included from 6002 and others
-[ -d .git/refs/tags ] || mkdir -p .git/refs/tags
+mkdir -p .git/refs/tags
-: sed.script
+sed.script
-# Answer the sha1 has associated with the tag. The tag must exist in .git or
.git/refs/tags
-tag()
-{
+# Answer the sha1 has associated with the tag. The tag must exist in
.git/refs/tags
+tag () {
_tag=$1
- [ -f .git/refs/tags/$_tag ] || error tag: \$_tag\ does not exist
- cat .git/refs/tags/$_tag
+ test -f .git/refs/tags/$_tag || error tag: \$_tag\ does not exist
+ cat .git/refs/tags/$_tag
}
# Generate a commit using the text specified to make it unique and the tree
# named by the tag specified.
-unique_commit()
-{
+unique_commit () {
_text=$1
-_tree=$2
+ _tree=$2
shift 2
- echo $_text | git commit-tree $(tag $_tree) $@
+ echo $_text | git commit-tree $(tag $_tree) $@
}
# Save the output of a command into the tag specified. Prepend
# a substitution script for the tag onto the front of sed.script
-save_tag()
-{
+save_tag () {
_tag=$1
- [ -n $_tag ] || error usage: save_tag tag commit-args ...
+ test -n $_tag || error usage: save_tag tag commit-args ...
shift 1
- $@ .git/refs/tags/$_tag
+ $@ .git/refs/tags/$_tag
-echo s/$(tag $_tag)/$_tag/g sed.script.tmp
- cat sed.script sed.script.tmp
+ echo s/$(tag $_tag)/$_tag/g sed.script.tmp
+ cat sed.script sed.script.tmp
rm sed.script
mv sed.script.tmp sed.script
}
# Replace unhelpful sha1 hashses with their symbolic equivalents
-entag()
-{
+entag () {
sed -f sed.script
}
# Execute a command after first saving, then setting the GIT_AUTHOR_EMAIL
# tag to a specified value. Restore the original value on return.
-as_author()
-{
+as_author () {
_author=$1
shift 1
-_save=$GIT_AUTHOR_EMAIL
+ _save=$GIT_AUTHOR_EMAIL
GIT_AUTHOR_EMAIL=$_author
export GIT_AUTHOR_EMAIL
@@ -63,45 +58,41 @@ as_author()
fi
}
-commit_date()
-{
-_commit=$1
- git cat-file commit $_commit | sed -n s/^committer .* \([0-9]*\)
.*/\1/p
+commit_date () {
+ _commit=$1
+ git cat-file commit $_commit |
+ sed -n s/^committer .* \([0-9]*\) .*/\1/p
}
-on_committer_date()
-{
-_date=$1
-shift 1
-GIT_COMMITTER_DATE=$_date
-export GIT_COMMITTER_DATE
-$@
-unset GIT_COMMITTER_DATE
+on_committer_date () {
+ _date=$1
+ shift 1
+ GIT_COMMITTER_DATE=$_date
+ export GIT_COMMITTER_DATE
+ $@
+ unset GIT_COMMITTER_DATE
}
# Execute a command and suppress any error output.
-hide_error()
-{
+hide_error () {
$@ 2/dev/null
}
-check_output()
-{
+check_output () {
_name=$1
shift 1
- if eval $* | entag $_name.actual
+ if eval $* | entag $_name.actual
then
- test_cmp $_name.expected $_name.actual
+ test_cmp $_name.expected $_name.actual
else
- return 1;
+ return 1
fi
}
# Turn a reasonable test description into a reasonable test name.
# All alphanums translated into -'s which are then compressed and stripped
# from front and back.
-name_from_description()
-{
+name_from_description () {
perl -pe '
s/[^A-Za-z0-9.]/-/g;
s/-+/-/g;
@@ -119,9 +110,11 @@ name_from_description()
test_output_expect_success()
{
_description=$1
-_test=$2
-[ $# -eq 2 ] || error usage: test_output_expect_success description
test EOF ... EOF
-_name=$(echo $_description | name_from_description)
- cat $_name.expected
+ _test=$2
+ test $# -eq 2 ||
+ error usage: test_output_expect_success description test EOF ... EOF
+
+ _name=$(echo $_description | name_from_description)
+ cat $_name.expected
test_expect_success $_description check_output $_name \$_test\
}
--
1.8.3.1-682-g924db96
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] t6003: add --date-order test
The --date-order output is a slight twist of --topo-order in that commits from parallel histories are shown in their committer date order without an attempt to clump commits from a single line of history together like --topo-order does. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t6003-rev-list-topo-order.sh | 22 ++ 1 file changed, 22 insertions(+) diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh index bb66b8b..0e3b7e1 100755 --- a/t/t6003-rev-list-topo-order.sh +++ b/t/t6003-rev-list-topo-order.sh @@ -100,6 +100,28 @@ l0 root EOF +test_output_expect_success 'simple date order' 'git rev-list --date-order HEAD' EOF +l5 +l4 +l3 +a4 +b4 +a3 +a2 +c3 +c2 +b3 +b2 +c1 +b1 +a1 +a0 +l2 +l1 +l0 +root +EOF + test_output_expect_success 'two diamonds topo order (g6)' 'git rev-list --topo-order g4' EOF g4 h2 -- 1.8.3.1-682-g924db96 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] log --author-date-order follow-up
Complete the series to teach --author-date-order to the commands in the log family by adding some tests. We did not have explicit tests for --date-order, so the third patch in this series adds one while at it. Junio C Hamano (5): t/lib-t6000: style fixes topology tests: teach a helper to take abbreviated timestamps t6003: add --date-order test topology tests: teach a helper to set author dates as well t6003: add --author-date-order test t/lib-t6000.sh | 104 ++--- t/t6002-rev-list-bisect.sh | 84 - t/t6003-rev-list-topo-order.sh | 101 +++ 3 files changed, 169 insertions(+), 120 deletions(-) -- 1.8.3.1-682-g924db96 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] topology tests: teach a helper to take abbreviated timestamps
The on_committer_date helper in t/lib-t6000 is used in t6002 and
t6003 with timestamps on a single day within a single minute
(i.e. 1971-08-16 00:00) and the tests repeat this over and over.
The actual value of the timestamp, however, does not matter very
much; only their relative ordering does.
Introduce another helper to expand only the suffix of the timestamp
to a full timestamp to make the lines shorter, and use it in this
helper. Also, because all the commits in the test are made with
specific GIT_COMMITTER_DATE, stop unsetting it at the end of the
helper.
We'll be specifying the author timestamp to these test commits in a
later patch, which will be helped with this change.
Also remove a test that was commented-out from t6003; it used to
test a commit with the same parent listed twice, which was allowed
by mistake but was fixed long time ago.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/lib-t6000.sh | 17 +++--
t/t6002-rev-list-bisect.sh | 84 +-
t/t6003-rev-list-topo-order.sh | 57 +---
3 files changed, 81 insertions(+), 77 deletions(-)
diff --git a/t/lib-t6000.sh b/t/lib-t6000.sh
index 102d567..e2c3615 100644
--- a/t/lib-t6000.sh
+++ b/t/lib-t6000.sh
@@ -64,13 +64,22 @@ commit_date () {
sed -n s/^committer .* \([0-9]*\) .*/\1/p
}
+# Assign the value of fake date to a variable, but
+# allow fairly common 1971-08-16 00:00 to be omittd
+assign_fake_date () {
+ case $2 in
+ ??:??:??) eval $1='1971-08-16 $2' ;;
+ ??:??) eval $1='1971-08-16 00:$2' ;;
+ ??) eval $1='1971-08-16 00:00:$2' ;;
+ *) eval $1='$2' ;;
+ esac
+}
+
on_committer_date () {
- _date=$1
- shift 1
- GIT_COMMITTER_DATE=$_date
+ assign_fake_date GIT_COMMITTER_DATE $1
export GIT_COMMITTER_DATE
+ shift 1
$@
- unset GIT_COMMITTER_DATE
}
# Execute a command and suppress any error output.
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
index fb07536..43ad772 100755
--- a/t/t6002-rev-list-bisect.sh
+++ b/t/t6002-rev-list-bisect.sh
@@ -39,25 +39,25 @@ test_bisection_diff()
date path0
git update-index --add path0
save_tag tree git write-tree
-on_committer_date 1971-08-16 00:00:00 hide_error save_tag root unique_commit
root tree
-on_committer_date 1971-08-16 00:00:01 save_tag l0 unique_commit l0 tree -p
root
-on_committer_date 1971-08-16 00:00:02 save_tag l1 unique_commit l1 tree -p l0
-on_committer_date 1971-08-16 00:00:03 save_tag l2 unique_commit l2 tree -p l1
-on_committer_date 1971-08-16 00:00:04 save_tag a0 unique_commit a0 tree -p l2
-on_committer_date 1971-08-16 00:00:05 save_tag a1 unique_commit a1 tree -p a0
-on_committer_date 1971-08-16 00:00:06 save_tag b1 unique_commit b1 tree -p a0
-on_committer_date 1971-08-16 00:00:07 save_tag c1 unique_commit c1 tree -p b1
-on_committer_date 1971-08-16 00:00:08 save_tag b2 unique_commit b2 tree -p b1
-on_committer_date 1971-08-16 00:00:09 save_tag b3 unique_commit b2 tree -p b2
-on_committer_date 1971-08-16 00:00:10 save_tag c2 unique_commit c2 tree -p
c1 -p b2
-on_committer_date 1971-08-16 00:00:11 save_tag c3 unique_commit c3 tree -p c2
-on_committer_date 1971-08-16 00:00:12 save_tag a2 unique_commit a2 tree -p a1
-on_committer_date 1971-08-16 00:00:13 save_tag a3 unique_commit a3 tree -p a2
-on_committer_date 1971-08-16 00:00:14 save_tag b4 unique_commit b4 tree -p
b3 -p a3
-on_committer_date 1971-08-16 00:00:15 save_tag a4 unique_commit a4 tree -p
a3 -p b4 -p c3
-on_committer_date 1971-08-16 00:00:16 save_tag l3 unique_commit l3 tree -p a4
-on_committer_date 1971-08-16 00:00:17 save_tag l4 unique_commit l4 tree -p l3
-on_committer_date 1971-08-16 00:00:18 save_tag l5 unique_commit l5 tree -p l4
+on_committer_date 00:00 hide_error save_tag root unique_commit root tree
+on_committer_date 00:01 save_tag l0 unique_commit l0 tree -p root
+on_committer_date 00:02 save_tag l1 unique_commit l1 tree -p l0
+on_committer_date 00:03 save_tag l2 unique_commit l2 tree -p l1
+on_committer_date 00:04 save_tag a0 unique_commit a0 tree -p l2
+on_committer_date 00:05 save_tag a1 unique_commit a1 tree -p a0
+on_committer_date 00:06 save_tag b1 unique_commit b1 tree -p a0
+on_committer_date 00:07 save_tag c1 unique_commit c1 tree -p b1
+on_committer_date 00:08 save_tag b2 unique_commit b2 tree -p b1
+on_committer_date 00:09 save_tag b3 unique_commit b2 tree -p b2
+on_committer_date 00:10 save_tag c2 unique_commit c2 tree -p c1 -p b2
+on_committer_date 00:11 save_tag c3 unique_commit c3 tree -p c2
+on_committer_date 00:12 save_tag a2 unique_commit a2 tree -p a1
+on_committer_date 00:13 save_tag a3 unique_commit a3 tree -p a2
+on_committer_date 00:14 save_tag b4 unique_commit b4 tree -p b3 -p a3
+on_committer_date 00:15 save_tag a4 unique_commit a4 tree -p a3 -p b4 -p c3
+on_committer_date 00:16 save_tag l3 unique_commit l3 tree -p a4
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Junio C Hamano wrote: Unfortunately, I tend to become bottleneck more often than you do, so I do not think that would be a good use of my time. Besides, as Antoine points out, those numbers might well be useless (or worse, misleading). It's probably not worth the effort. Which ones went unreviewed that are of high value? My observation can be boiled down to: I usually never get the opportunity to say something useful on most patches, because someone else already has; that has not been the case offlate. Probably some bias: I tried looking for examples and counter-examples, but the list is too large for individual patches to make any sense. I did run a script on git.git to see if there are any recent trends: if I'm right about patches not being reviewed, it must ultimately show up somewhere, right? v1.7.0..v1.7.1:: 702 jc (68), jn (50), jh (32), tr (22), jk (19), tr (19), mj (18), sb (15), bc (11), jl (10) v1.7.1..v1.7.2:: 772 jc (57), jn (56), Æa (32), mj (26), jk (21), tr (20), bc (19), gv (18), jn (18), cc (17) v1.7.2..v1.7.3:: 624 jn (117), Æa (64), jc (28), mm (23), nt (23), en (18), bc (17), tr (17), js (15), jl (12) v1.7.3..v1.7.4:: 1025 jn (89), nt (68), jc (59), en (54), jk (27), mj (26), Æa (25), ef (23), jh (23), ra (20) v1.7.4..v1.7.5:: 734 jn (90), Æa (79), jc (64), mj (40), jk (38), nt (31), bw (16), hv (13), pw (12), jl (10) v1.7.5..v1.7.6:: 650 jc (112), jk (51), mv (35), jn (28), jn (20), mj (16), jh (15), Æa (12), mk (11), jm (9) v1.7.6..v1.7.7:: 779 jc (105), jk (60), en (55), Æa (48), mh (44), js (19), di (16), jn (16), sr (15), tr (15) v1.7.7..v1.7.8:: 644 jc (85), mh (37), jk (31), rs (26), rr (23), jn (18), nt (15), bc (13), mj (10), ra (9) v1.7.8..v1.7.9:: 565 jc (82), jk (62), nt (24), mh (23), pw (18), jn (16), tr (15), bw (14), mv (11), pt (11) v1.7.9..v1.7.10:: 683 jc (84), jk (40), jn (27), nt (25), tr (21), jn (18), jx (15), zj (15), mh (13), th (11) v1.7.10..v1.7.11:: 925 jc (92), ap (73), jk (69), nt (39), rs (38), mh (37), jn (25), jx (19), rt (17), zj (17) v1.7.11..v1.7.12:: 548 jc (107), jk (51), mm (29), jx (15), mg (14), nt (14), pw (13), jn (12), as (7), cw (7) v1.8.0..v1.8.1:: 525 jc (55), jk (41), fc (32), nt (19), fa (15), mh (12), km (11), ta (11), mo (10), rr (9) v1.8.1..v1.8.2:: 957 jc (107), nt (53), jk (39), pw (35), jk (33), as (31), mh (31), fc (26), mv (23), wt (17) v1.8.2..v1.8.3:: 1005 fc (112), jc (95), jk (89), nt (35), jk (29), da (26), rr (24), tr (18), bc (15), jn (15) v1.8.3..master:: 497 fc (112), mh (60), rr (24), jc (23), rs (21), tr (18), kb (15), js (13), ra (12), nt (11) Meh, it looks normal. Sorry for the noise: I don't think there's any cause for worry. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] t6003: add --author-date-order test
Tweak the --topo/date-order test vector a bit and mark the author dates of two commits (a2 and a3) earlier than their own committer dates, making them much older than other commits that are made on parallel branches to simulate the case where a long running topic was rebased recently. They will show up as recent in the --date-order output due to their timestamps, but they appear a lot later in the --author-date-order output, even though their committer timestamp says otherwise. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t6003-rev-list-topo-order.sh | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh index 77bf2ca..24d1836 100755 --- a/t/t6003-rev-list-topo-order.sh +++ b/t/t6003-rev-list-topo-order.sh @@ -28,8 +28,8 @@ on_dates 00:08 00:08 as_author foo...@example.com save_tag b2 unique_commit on_dates 00:09 00:09 save_tag b3 unique_commit b3 tree -p b2 on_dates 00:10 00:10 save_tag c2 unique_commit c2 tree -p c1 -p b2 on_dates 00:11 00:11 save_tag c3 unique_commit c3 tree -p c2 -on_dates 00:12 00:12 save_tag a2 unique_commit a2 tree -p a1 -on_dates 00:13 00:13 save_tag a3 unique_commit a3 tree -p a2 +on_dates 00:12 00:00 save_tag a2 unique_commit a2 tree -p a1 +on_dates 00:13 00:01 save_tag a3 unique_commit a3 tree -p a2 on_dates 00:14 00:14 save_tag b4 unique_commit b4 tree -p b3 -p a3 on_dates 00:15 00:15 save_tag a4 unique_commit a4 tree -p a3 -p b4 -p c3 on_dates 00:16 00:16 save_tag l3 unique_commit l3 tree -p a4 @@ -122,6 +122,28 @@ l0 root EOF +test_output_expect_success 'simple author-date order' 'git rev-list --author-date-order HEAD' EOF +l5 +l4 +l3 +a4 +b4 +c3 +c2 +b3 +b2 +c1 +b1 +a3 +a2 +a1 +a0 +l2 +l1 +l0 +root +EOF + test_output_expect_success 'two diamonds topo order (g6)' 'git rev-list --topo-order g4' EOF g4 h2 -- 1.8.3.1-682-g924db96 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] topology tests: teach a helper to set author dates as well
Introduce on_dates helper that is similar to on_committer_date but
also sets the author date, not just the committer date.
At this step, just set the same timestamp to the author date as the
committer date, as no test looks at author date yet.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/lib-t6000.sh | 8 +++
t/t6003-rev-list-topo-order.sh | 52 +-
2 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/t/lib-t6000.sh b/t/lib-t6000.sh
index e2c3615..4ffd901 100644
--- a/t/lib-t6000.sh
+++ b/t/lib-t6000.sh
@@ -82,6 +82,14 @@ on_committer_date () {
$@
}
+on_dates () {
+ assign_fake_date GIT_COMMITTER_DATE $1
+ assign_fake_date GIT_AUTHOR_DATE $2
+ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
+ shift 2
+ $@
+}
+
# Execute a command and suppress any error output.
hide_error () {
$@ 2/dev/null
diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh
index 0e3b7e1..77bf2ca 100755
--- a/t/t6003-rev-list-topo-order.sh
+++ b/t/t6003-rev-list-topo-order.sh
@@ -16,32 +16,32 @@ list_duplicates()
date path0
git update-index --add path0
save_tag tree git write-tree
-on_committer_date 00:00 hide_error save_tag root unique_commit root tree
-on_committer_date 00:01 save_tag l0 unique_commit l0 tree -p root
-on_committer_date 00:02 save_tag l1 unique_commit l1 tree -p l0
-on_committer_date 00:03 save_tag l2 unique_commit l2 tree -p l1
-on_committer_date 00:04 save_tag a0 unique_commit a0 tree -p l2
-on_committer_date 00:05 save_tag a1 unique_commit a1 tree -p a0
-on_committer_date 00:06 save_tag b1 unique_commit b1 tree -p a0
-on_committer_date 00:07 save_tag c1 unique_commit c1 tree -p b1
-on_committer_date 00:08 as_author foo...@example.com save_tag b2
unique_commit b2 tree -p b1
-on_committer_date 00:09 save_tag b3 unique_commit b3 tree -p b2
-on_committer_date 00:10 save_tag c2 unique_commit c2 tree -p c1 -p b2
-on_committer_date 00:11 save_tag c3 unique_commit c3 tree -p c2
-on_committer_date 00:12 save_tag a2 unique_commit a2 tree -p a1
-on_committer_date 00:13 save_tag a3 unique_commit a3 tree -p a2
-on_committer_date 00:14 save_tag b4 unique_commit b4 tree -p b3 -p a3
-on_committer_date 00:15 save_tag a4 unique_commit a4 tree -p a3 -p b4 -p c3
-on_committer_date 00:16 save_tag l3 unique_commit l3 tree -p a4
-on_committer_date 00:17 save_tag l4 unique_commit l4 tree -p l3
-on_committer_date 00:18 save_tag l5 unique_commit l5 tree -p l4
-on_committer_date 00:19 save_tag m1 unique_commit m1 tree -p a4 -p c3
-on_committer_date 00:20 save_tag m2 unique_commit m2 tree -p c3 -p a4
-on_committer_date 00:21 hide_error save_tag alt_root unique_commit alt_root
tree
-on_committer_date 00:22 save_tag r0 unique_commit r0 tree -p alt_root
-on_committer_date 00:23 save_tag r1 unique_commit r1 tree -p r0
-on_committer_date 00:24 save_tag l5r1 unique_commit l5r1 tree -p l5 -p r1
-on_committer_date 00:25 save_tag r1l5 unique_commit r1l5 tree -p r1 -p l5
+on_dates 00:00 00:00 hide_error save_tag root unique_commit root tree
+on_dates 00:01 00:01 save_tag l0 unique_commit l0 tree -p root
+on_dates 00:02 00:02 save_tag l1 unique_commit l1 tree -p l0
+on_dates 00:03 00:03 save_tag l2 unique_commit l2 tree -p l1
+on_dates 00:04 00:04 save_tag a0 unique_commit a0 tree -p l2
+on_dates 00:05 00:05 save_tag a1 unique_commit a1 tree -p a0
+on_dates 00:06 00:06 save_tag b1 unique_commit b1 tree -p a0
+on_dates 00:07 00:07 save_tag c1 unique_commit c1 tree -p b1
+on_dates 00:08 00:08 as_author foo...@example.com save_tag b2
unique_commit b2 tree -p b1
+on_dates 00:09 00:09 save_tag b3 unique_commit b3 tree -p b2
+on_dates 00:10 00:10 save_tag c2 unique_commit c2 tree -p c1 -p b2
+on_dates 00:11 00:11 save_tag c3 unique_commit c3 tree -p c2
+on_dates 00:12 00:12 save_tag a2 unique_commit a2 tree -p a1
+on_dates 00:13 00:13 save_tag a3 unique_commit a3 tree -p a2
+on_dates 00:14 00:14 save_tag b4 unique_commit b4 tree -p b3 -p a3
+on_dates 00:15 00:15 save_tag a4 unique_commit a4 tree -p a3 -p b4 -p c3
+on_dates 00:16 00:16 save_tag l3 unique_commit l3 tree -p a4
+on_dates 00:17 00:17 save_tag l4 unique_commit l4 tree -p l3
+on_dates 00:18 00:18 save_tag l5 unique_commit l5 tree -p l4
+on_dates 00:19 00:19 save_tag m1 unique_commit m1 tree -p a4 -p c3
+on_dates 00:20 00:20 save_tag m2 unique_commit m2 tree -p c3 -p a4
+on_dates 00:21 00:21 hide_error save_tag alt_root unique_commit alt_root
tree
+on_dates 00:22 00:22 save_tag r0 unique_commit r0 tree -p alt_root
+on_dates 00:23 00:23 save_tag r1 unique_commit r1 tree -p r0
+on_dates 00:24 00:24 save_tag l5r1 unique_commit l5r1 tree -p l5 -p r1
+on_dates 00:25 00:25 save_tag r1l5 unique_commit r1l5 tree -p r1 -p l5
hide_error save_tag e1 as_author e...@example.com unique_commit e1 tree
--
1.8.3.1-682-g924db96
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH 3/3] remote: don't prune when detecting overlapping refspecs
Dennis Kaarsemaker den...@kaarsemaker.net writes:
+static int check_overlapping_remotes(struct remote *first, void *priv) {
+ struct remote *second = priv;
+ int i, j;
+ if(!second)
+ return for_each_remote(check_overlapping_remotes, first);
+ if(first == second)
+ return 0;
+ for (i = 0; i first-fetch_refspec_nr; i++) {
+ for (j = 0; j second-fetch_refspec_nr; j++) {
+ if(strcmp(first-fetch[i].dst, second-fetch[j].dst)
+(!fnmatch(first-fetch[i].dst, second-fetch[j].dst,
0) ||
+ !fnmatch(second-fetch[j].dst, first-fetch[i].dst,
0))) {
+ warning(_(Overlapping refspecs detected: '%s'
and '%s', not pruning.),
+ first-fetch[i].dst,
second-fetch[j].dst);
+ return 1;
+ }
+ }
+ }
+ return 0;
+}
This codepath essentially needs the same logic as 1/3, no? Instead
of open code the inner loop here, can't you call the check RHS of a
single fetch refspec for overlap with refspecs from a remote helper
you introduced in 1/3?
The logic in the inner loop shares the same issue as the code in
1/3; it needs to be extended to cover non-wildcard respecs and
non-storing refspecs.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
$ ~/src/git
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
So fsync() and close() thought that the filesystem stored this loose
object safely, but it turns out that the data is not on disk.
Where should I start digging if I want to fix this? Actually you just
need to tell me how to build reduced-case corruptions to test: I can
trace and figure out the rest.
That is a trip in the kernel source, isn't it? I cannot be your
guide there.
artagnon|remote-cruft*+:~/src/git$ git prune
artagnon|remote-cruft*+:~/src/git$ git status
fatal: bad object HEAD
fatal: bad object HEAD
And the value in the HEAD was???
ref: refs/heads/remote-cruft. That's why I included my prompt :)
artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
artagnon|master*+=:~/src/git$ git status
## master
MM Documentation/git-ls-remote.txt
MM remote.c
MM t/t5505-remote.sh
MM t/t5510-fetch.sh
MM t/t5515-fetch-merge-logic.sh
MM t/t5516-fetch-push.sh
?? lib/
?? outgoing/
That status is completely bogus, by the way.
... which may suggest that your index file may have been corrupted
on the filesystem.
Yeah, my question pertains to why is the index half-corrupted. Is
there no checksum to say index corrupted; do not display bogus
nonsense?
Another possibility is perhaps the objects that are referred to by
the index were missing or unreadable, and the index weren't.
artagnon|master*+=:~/src/git$ git checkout remote-cruft
fatal: reference is not a tree: remote-cruft
artagnon|master=:~/src/git$ git reflog
21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
refs/heads/remote-cruft
What happened to the rest of my reflog?!
On the filesystem known to not record the last consistent state of
the repository, the answer to that question may be rather obvious,
no?
I didn't understand. What does .git/logs/HEAD have to do with any of
this? Why is it truncated?
Explain why .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
was truncated to yourself, and the same explanation would apply to
the .git/logs/HEAD file, I think.
This was mainly a learning exercise for me: I wanted to see how good
git was at working with corrupted repositories.
You could have just asked ;-).
A tl;dr is that we _trust_ our refs and everything reachable from
them has to be complete. If that is not the case, things will not
work, and it is not a priority to add workarounds in the normal
codepath to slow things down.
That does not forbid an addition of git recover-corrupted-repo
command, whose assume everything might be broken code is not
shared with the fastpath of other commands.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] Cleanup {branches,remotes}-file cruft
Junio C Hamano wrote: So from my point of view, a proposal to remove them has an almost no benefit vs potentially very high cost of having to break many people who are silently happily using them; not a very good benefit/cost ratio. Yep, it should stay around because it's useful to some people and harms nobody. I say minor only because I think the cost of keeping these old mechanisms alive is very low (if it is a heavy burden on the maintenance, please tell me and how). Yeah, the point of this series is to reduce that maintenance burden. After it is applied, there will be exactly two functions (each with one caller) that are tested fully by precisely three tests in t/remote; and exactly one piece of documentation will refer to branches-file/remotes-file, namely urls-remotes.txt. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Junio C Hamano wrote: A tl;dr is that we _trust_ our refs and everything reachable from them has to be complete. If that is not the case, things will not work, and it is not a priority to add workarounds in the normal codepath to slow things down. Makes sense. That does not forbid an addition of git recover-corrupted-repo command, whose assume everything might be broken code is not shared with the fastpath of other commands. I'm not looking for a kitchen-sink command: I'm looking for a well-documented toolset to precisely fix corruptions. We have some corruption tests in our testsuite already: I think I'll start digging there. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: - rr/describe-contains-all at $gmane/228278. This may overlap with a topic in flight (but I didn't look at it). Let me know if I can do anything to make it easier for you. I'm quite excited about this one. - rr/mixed-case-aliases at $gmane/227959. Personally, not just uninterested but moderately against. Okay, but I'd like an explanation. Because the implementation is too ugly. The damage to the more generic config parser codepath is a real downside and the benefit from the little feature does not seem to justify it. I would however can imagine an alternative implementation which might be more palatable. It may go like this: [alias lgF] command = log --oneline --boundary --first-parent help = show the first parent chain, one line per commit completion = log so that not just alias.c code can take notice of alias.lgF.command to expand it, but we can later extend it to help git help lgF and bash/zsh completion (i.e. they would learn lgF parameter would complete in a way similar to 'log' from alias.lgF.completion). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not ignore merge options in interactive rebase
Arnaud Fontaine ar...@debian.org writes:
Merge strategy and its options can be specified in `git rebase`,
but with `--interactive`, they were completely ignored.
And why is it a bad thing? If you meant s/--interactive/-m/ in the
above, then I can sort of understand the justification, though.
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
old mode 100644
new mode 100755
I see an unjustifiable mode change here.
index f953d8d..c157fdf
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -239,7 +239,16 @@ pick_one () {
test -d $rewritten
pick_one_preserving_merges $@ return
- output git cherry-pick $empty_args $ff $@
+
+ if test -n $do_merge
+ then
So you _did_ mean rebase -m?
+ test -z $strategy strategy=recursive
+ output git cherry-pick --strategy=$strategy \
This is a bad change.
I would understand if the above were:
git cherry-pick ${strategy+--strategy=$strategy} ...
in other words, if there is no strategy specified, do not override
the configured default that might be different from recursive
(pull.twohead may be set to resolve).
+ $(echo $strategy_opts | sed s/'--\([^']*\)'/-X\1/g) \
Is it guaranteed $startegy_opts do not have a space in it?
There is a call to git merge that uses ${strategy+-s $strategy},
but it does not seem to propagate the strategy option. Does it need
a similar change? It seems that the first step might be to factor
out these calls to the git cherry-pick and git merge to helper
functions to make it easier to call them with -s/-X options in a
consistent way.
+ $empty_args $ff $@
+ else
+ output git cherry-pick $empty_args $ff $@
+ fi
It seems that there is another call to git cherry-pick in the
script (git grep for it). Does it need a similar change?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lib-httpd/apache.conf: check version only after mod_version loads
Jeff King p...@peff.net writes: Cool. I think the patch should look like the one below, then. Just to double-check that I have explained the issue correctly, can you share the output of apache2 -l? Mine has: $ apache2 -l Compiled in modules: core.c mod_log_config.c mod_logio.c mod_version.c prefork.c http_core.c mod_so.c which explains why it works here. I'm assuming you will not have mod_version.c compiled in. -- 8 -- Subject: lib-httpd/apache.conf: check version only after mod_version loads Commit 0442743 introduced an IfVersion directive near the top of the apache config file. However, at that point we have not yet checked for and loaded the mod_version module. This means that the directive will behave oddly if mod_version is dynamically loaded, failing to match when it should. We can fix this by moving the whole block below the LoadModule directive for mod_version. Reported-by: Brian Gernhardt br...@gernhardtsoftware.com Signed-off-by: Jeff King p...@peff.net --- t/lib-httpd/apache.conf | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf index 56ae548..dd17e3a 100644 --- a/t/lib-httpd/apache.conf +++ b/t/lib-httpd/apache.conf @@ -1,7 +1,4 @@ ServerName dummy ServerName dummy -IfVersion 2.4 -LockFile accept.lock -/IfVersion PidFile httpd.pid DocumentRoot www LogFormat %h %l %u %t \%r\ %s %b common @@ -26,6 +23,10 @@ ErrorLog error.log LoadModule version_module modules/mod_version.so /IfModule +IfVersion 2.4 +LockFile accept.lock +/IfVersion + Once you see it in the patch form, it is very clear what this change does and why it is necessary in the context ;-) Thanks, both of you, for digging this down to the root cause; you guys have done before it graduates to 'master', which I especially appreciate. Will queue. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git diff returns fatal error with core.safecrlf is set to true.
Junio C Hamano gits...@pobox.com writes:
The helper may want to learn a way to be told to demote that error
to a warning.
Perhaps something like this?
diff.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index f0b3e7c..9b4f3ac 100644
--- a/diff.c
+++ b/diff.c
@@ -2677,6 +2677,10 @@ static int diff_populate_gitlink(struct diff_filespec
*s, int size_only)
int diff_populate_filespec(struct diff_filespec *s, int size_only)
{
int err = 0;
+ enum safe_crlf crlf_warn = (safe_crlf != SAFE_CRLF_FAIL
+ ? safe_crlf
+ : SAFE_CRLF_WARN);
+
if (!DIFF_FILE_VALID(s))
die(internal error: asking to populate invalid file.);
if (S_ISDIR(s-mode))
@@ -2732,7 +2736,7 @@ int diff_populate_filespec(struct diff_filespec *s, int
size_only)
/*
* Convert from working tree format to canonical git format
*/
- if (convert_to_git(s-path, s-data, s-size, buf, safe_crlf))
{
+ if (convert_to_git(s-path, s-data, s-size, buf, crlf_warn))
{
size_t size = 0;
munmap(s-data, s-size);
s-should_munmap = 0;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] t/t5505-remote: modernize subshell-style of one test
Ramkumar Ramachandra artag...@gmail.com writes: Since we plan to edit the test migrate a remote from named file in $GIT_DIR/remotes in later patches, modernize the subshell-style by putting the parenthesis on separate lines and indenting the body. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Good, but a style only patch like this should consider taking advantage of the occasion to clean up the entire file, as we do not often get enough chance to do so without conflicting with in-flight topics. Is there something else that would conflict if this step did so? t/t5505-remote.sh | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index dd10ff0..4d5810f 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -691,13 +691,15 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' ' test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' git clone one six origin_url=$(pwd)/one - (cd six - git remote rm origin - echo $origin_url .git/branches/origin - git remote rename origin origin - ! test -f .git/branches/origin - test $(git config remote.origin.url) = $origin_url - test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin) + ( + cd six + git remote rm origin + echo $origin_url .git/branches/origin A SP between and the filename is still there? + git remote rename origin origin + ! test -f .git/branches/origin + test $(git config remote.origin.url) = $origin_url + test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + ) ' test_expect_success 'remote prune to cause a dangling symref' ' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/16] t/t5505-remote: test push-refspec in branches-file
Ramkumar Ramachandra artag...@gmail.com writes: The test migrate a remote from named file in $GIT_DIR/branches reads the branches-file, but only checks that the url and fetch-refspec are set correctly. Check that the push-refspec is also set correctly. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 4d5810f..38c62ec 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -698,7 +698,8 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' git remote rename origin origin ! test -f .git/branches/origin test $(git config remote.origin.url) = $origin_url - test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + test $(git config remote.origin.push) = HEAD:refs/heads/master OK. That is an ancient Cogito-compatible push which might not be a sensible setting, but there is no point changing it now, and there is a value in making sure it will stay working the way it has. Good. ) ' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/16] t/t5505-remote: remove dependency on $origin_url
Ramkumar Ramachandra artag...@gmail.com writes:
In the tests migrate a remote from named file in
$GIT_DIR/{remotes,branches}, we are only checking that a configuration
is migrated successfully; it has no correspondence with whether or not
those values do something sensible with other git
operations (fetch/push). Therefore, there is no need to determine
$origin_url: just substitute it with the constant value quux.
Is there a reason why quux is better than another randomly chosen
string $(pwd)/one?
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5505-remote.sh | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index dcb6c2f..fd0a81e 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -669,21 +669,20 @@ test_expect_success 'rename a remote with name prefix
of other remote' '
'
cat remotes_origin EOF
-URL: $(pwd)/one
+URL: quux
Push: refs/heads/master:refs/heads/upstream
Pull: refs/heads/master:refs/heads/origin
EOF
test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
git clone one five
- origin_url=$(pwd)/one
(cd five
git remote remove origin
mkdir -p .git/remotes
cat ../remotes_origin .git/remotes/origin
git remote rename origin origin
test_path_is_missing .git/remotes/origin
- test $(git config remote.origin.url) = $origin_url
+ test $(git config remote.origin.url) = quux
test $(git config remote.origin.push) =
refs/heads/master:refs/heads/upstream
test $(git config remote.origin.fetch) =
refs/heads/master:refs/heads/origin)
'
@@ -694,10 +693,10 @@ test_expect_success 'migrate a remote from named file
in $GIT_DIR/branches' '
(
cd six
git remote rm origin
- echo $origin_url .git/branches/origin
+ echo quux .git/branches/origin
git remote rename origin origin
test_path_is_missing .git/branches/origin
- test $(git config remote.origin.url) = $origin_url
+ test $(git config remote.origin.url) = quux
test $(git config remote.origin.fetch) =
refs/heads/master:refs/heads/origin
test $(git config remote.origin.push) =
HEAD:refs/heads/master
)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/16] remote: remove dead code in read_branches_file()
Ramkumar Ramachandra artag...@gmail.com writes:
The first line of the function checks that the remote-name contains a
slash ('/'), and sets the slash variable accordingly. The only caller
of read_branches_file() is remote_get_1(); the calling codepath is
guarded by valid_remote_nick(), which checks that the remote does not
contain a slash. Therefore, the slash variable can never be set:
remove the dead code that assumes otherwise.
This is extremely interesting.
As far as I can tell, that valid-remote-nick was done in df93e33c
(Validate nicknames of remote branches to prohibit confusing ones,
2008-02-15), and back in that version, the codepath and the feature
that wants to see a slash and do magical things, which is described
by this comment you are removing:
- /*
- * With slash, e.g. git fetch jgarzik/netdev-2.6 when
- * reading from $GIT_DIR/branches/jgarzik fetches HEAD from
- * the partial URL obtained from the branches file plus
- * /netdev-2.6 and does not store it in any tracking ref.
- * #branch specifier in the file is ignored.
did exist (see git show df93e33c:remote.c). It expects to see
jgarzik/netdev-2.6 in remote-name, grabs the leading jgarzik
part to form .git/branches/jgarzik to open and read from, and then
appends the remainder /netdev-2.6 to the partial URL it read
to come up with the final URL.
So it appears that back then (and througout to today), nobody uses
that partial URL feature which is specific (and was a rather nice
invention/legacy by Cogito) to .git/branches file.
Reminds me of the strategy to deprecate functionality in X (cf.
http://lwn.net/Articles/536520/) ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/16] t/t5505-remote: test url-with-# in branches-file
Ramkumar Ramachandra artag...@gmail.com writes: Add one more test similar to migrate a remote from named file in $GIT_DIR/branches to check that a url with a # can be used to specify the branch name (as opposed to the constant master). Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5505-remote.sh | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index fd0a81e..93e11c8 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -702,27 +702,42 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' ' ) ' -test_expect_success 'remote prune to cause a dangling symref' ' +test_expect_success 'migrate a remote from named file in $GIT_DIR/branches (2)' ' git clone one seven + origin_url=$(pwd)/one The variable assigned here does not seem to get used. Is this needed? + ( + cd seven + git remote rm origin + echo quux#foom .git/branches/origin + git remote rename origin origin + test_path_is_missing .git/branches/origin + test $(git config remote.origin.url) = quux + test $(git config remote.origin.fetch) = refs/heads/foom:refs/heads/origin + test $(git config remote.origin.push) = HEAD:refs/heads/foom + ) +' + +test_expect_success 'remote prune to cause a dangling symref' ' + git clone one eight ( cd one git checkout side2 git branch -D master ) ( - cd seven + cd eight git remote prune origin ) err 21 test_i18ngrep has become dangling err : And the dangling symref will not cause other annoying errors ( - cd seven + cd eight git branch -a ) 2err ! grep points nowhere err ( - cd seven + cd eight test_must_fail git branch nomore origin ) 2err grep dangling symref err -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/16] t/t5516-fetch-push: don't use branches-file
Ramkumar Ramachandra artag...@gmail.com writes: Four tests exercising fetch and push functionality unnecessarily depend on $GIT_DIR/branches files. Modern Git does not encourage the use of those files, and the parser remote.c:read_branches_file() is only provided for backward compatibility with older repositories. We already have tests in t/t5505-remote to verify that the parser works: so, substitute the $GIT_DIR/branches configuration with an equivalent gitconfig-style configuration, using the results of those tests. As we are not deprecating, I think we agree we would prefer to keep these working. If we need tests using remotes/ or config, they should be added as their own tests, not by removing branches/ one. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5516-fetch-push.sh | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 4691d51..6e9fa84 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -852,9 +852,11 @@ test_expect_success 'fetch with branches' ' mk_empty testrepo git branch second $the_first_commit git checkout second - echo .. testrepo/.git/branches/branch1 ( cd testrepo + test_config remote.branch1.url .. + test_config remote.branch1.fetch refs/heads/master:refs/heads/branch1 + test_config remote.branch1.push HEAD:refs/heads/master git fetch branch1 echo $the_commit commitrefs/heads/branch1 expect git for-each-ref refs/heads actual @@ -865,9 +867,11 @@ test_expect_success 'fetch with branches' ' test_expect_success 'fetch with branches containing #' ' mk_empty testrepo - echo ..#second testrepo/.git/branches/branch2 ( cd testrepo + test_config remote.branch2.url .. + test_config remote.branch2.fetch refs/heads/second:refs/heads/branch2 + test_config remote.branch2.push HEAD:refs/heads/second git fetch branch2 echo $the_first_commit commit refs/heads/branch2 expect git for-each-ref refs/heads actual @@ -879,7 +883,9 @@ test_expect_success 'fetch with branches containing #' ' test_expect_success 'push with branches' ' mk_empty testrepo git checkout second - echo testrepo .git/branches/branch1 + test_config remote.branch1.url testrepo + test_config remote.branch1.fetch refs/heads/master:refs/heads/branch1 + test_config remote.branch1.push HEAD:refs/heads/master git push branch1 ( cd testrepo @@ -891,7 +897,9 @@ test_expect_success 'push with branches' ' test_expect_success 'push with branches containing #' ' mk_empty testrepo - echo testrepo#branch3 .git/branches/branch2 + test_config remote.branch2.url testrepo + test_config remote.branch2.fetch refs/heads/branch3:refs/heads/branch2 + test_config remote.branch2.push HEAD:refs/heads/branch3 git push branch2 ( cd testrepo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16] t/t5516-fetch-push: use test_config()
Ramkumar Ramachandra artag...@gmail.com writes: Replace the 'git config' calls in tests with test_config for greater robustness. That may be a good thing in principle, but I _think_ mk_empty testrepo ( cd testrepo do whatever to its config run test ) sequence is used so that we do not even have to worry about what leftover configuration values are in the testrepo/.git/config; so does it really matter? If this conversion had something more than s/git config/test_config/ replacement, that would indicate that you uncovered a bug in the existing test and found a good fix, but that does not seem to be the case for this particular patch. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- t/t5516-fetch-push.sh | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 6e9fa84..afb25c4 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -142,8 +142,8 @@ test_expect_success 'fetch with wildcard' ' mk_empty testrepo ( cd testrepo - git config remote.up.url .. - git config remote.up.fetch refs/heads/*:refs/remotes/origin/* + test_config remote.up.url .. + test_config remote.up.fetch refs/heads/*:refs/remotes/origin/* git fetch up echo $the_commit commitrefs/remotes/origin/master expect @@ -157,9 +157,9 @@ test_expect_success 'fetch with insteadOf' ' ( TRASH=$(pwd)/ cd testrepo - git config url.$TRASH.insteadOf trash/ - git config remote.up.url trash/. - git config remote.up.fetch refs/heads/*:refs/remotes/origin/* + test_config url.$TRASH.insteadOf trash/ + test_config remote.up.url trash/. + test_config remote.up.fetch refs/heads/*:refs/remotes/origin/* git fetch up echo $the_commit commitrefs/remotes/origin/master expect @@ -173,9 +173,9 @@ test_expect_success 'fetch with pushInsteadOf (should not rewrite)' ' ( TRASH=$(pwd)/ cd testrepo - git config url.trash/.pushInsteadOf $TRASH - git config remote.up.url $TRASH. - git config remote.up.fetch refs/heads/*:refs/remotes/origin/* + test_config url.trash/.pushInsteadOf $TRASH + test_config remote.up.url $TRASH. + test_config remote.up.fetch refs/heads/*:refs/remotes/origin/* git fetch up echo $the_commit commitrefs/remotes/origin/master expect @@ -780,7 +780,7 @@ test_expect_success 'mixed ref updates, deletes, invalid deletes trigger hooks w test_expect_success 'allow deleting a ref using --delete' ' mk_test testrepo heads/master - (cd testrepo git config receive.denyDeleteCurrent warn) + (cd testrepo test_config receive.denyDeleteCurrent warn) git push testrepo --delete master (cd testrepo test_must_fail git rev-parse --verify refs/heads/master) ' @@ -809,7 +809,7 @@ test_expect_success 'warn on push to HEAD of non-bare repository' ' ( cd testrepo git checkout master - git config receive.denyCurrentBranch warn + test_config receive.denyCurrentBranch warn ) git push testrepo master 2stderr grep warning: updating the current branch stderr @@ -820,7 +820,7 @@ test_expect_success 'deny push to HEAD of non-bare repository' ' ( cd testrepo git checkout master - git config receive.denyCurrentBranch true + test_config receive.denyCurrentBranch true ) test_must_fail git push testrepo master ' @@ -830,8 +830,8 @@ test_expect_success 'allow push to HEAD of bare repository (bare)' ' ( cd testrepo git checkout master - git config receive.denyCurrentBranch true - git config core.bare true + test_config receive.denyCurrentBranch true + test_config core.bare true ) git push testrepo master 2stderr ! grep warning: updating the current branch stderr @@ -842,7 +842,7 @@ test_expect_success 'allow push to HEAD of non-bare repository (config)' ' ( cd testrepo git checkout master - git config receive.denyCurrentBranch false + test_config receive.denyCurrentBranch false ) git push testrepo master 2stderr ! grep warning: updating the current branch stderr @@ -918,7 +918,7 @@ test_expect_success 'push into aliased refs (consistent)' ' cd child1
Re: [PATCH 09/16] ls-remote doc: fix example invocation on git.git
Ramkumar Ramachandra artag...@gmail.com writes: Under the EXAMPLES section, there is one invocation on the git.git repository that attempts to list the refs master, pu, and rc. The ref rc does not exist in today's repository, so remove it. Hmph, I am on the fence but slightly on the negative side. It is just an example to show how to use the command and how the command may respond. If you ask your repository about --tags today, you will not get the v0.99 tags or a blob that has my public gpg key, and the readers would understand it. Removing the output line for rc without changing the command line would be a good change, though. We do not demonstrate that these are patterns that filter, and do not explain that not having rc over there is not an error. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-ls-remote.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 774de5e..a24b8b6 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -67,10 +67,9 @@ EXAMPLES 7ceca275d047c90c0c7d5afb13ab97efdf51bd6erefs/tags/v0.99.3 c5db5456ae3b0873fc659c19fafdde22313cc441refs/tags/v0.99.2 0918385dbd9656cab0d1d81ba7453d49bbc16250refs/tags/junio-gpg-pub - $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc + $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu 5fe978a5381f1fbad26a80e682ddd2a401966740refs/heads/master c781a84b5204fb294c9ccc79f8b3baceeb32c061refs/heads/pu - b1d096f2926c4e37c9c0b6a7bf2119bedaa277cbrefs/heads/rc $ echo http://www.kernel.org/pub/scm/git/git.git .git/branches/public $ git ls-remote --tags public v\* d6602ec5194c87b0fc87103ca4d67251c76f233arefs/tags/v0.99 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/16] ls-remote doc: rewrite repository paragraph
Ramkumar Ramachandra artag...@gmail.com writes: Replace the repository paragraph containing specific references to $GIT_DIR/branches and . with a generic urls-or-remotes paragraph referencing the relevant sections in the git-fetch(1) manpage. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/git-ls-remote.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index a24b8b6..0715892 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -48,9 +48,9 @@ OPTIONS exit without talking to the remote. repository:: - Location of the repository. The shorthand defined in - $GIT_DIR/branches/ can be used. Use . (dot) to list references in - the local repository. + The remote repository to query. This parameter can be + either a URL or the name of a remote (see the GIT URLS and + REMOTES sections of linkgit:git-fetch[1]). Looks OK. . was written before for-each-ref and branch --list have become the standard way to list your local refs and branches, and I would agree that the description outlived its usefulness. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] t/t5505-remote: test multiple push/pull in remotes-file
On Fri, Jun 21, 2013 at 7:12 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Extend the test migrate a remote from named file in $GIT_DIR/remotes to test that multiple Push: and Pull: lines in the remotes-file works as expected. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index 06ed381..5497a23 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -684,8 +686,18 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' ' git remote rename origin origin test_path_is_missing .git/remotes/origin test $(git config remote.origin.url) = quux - test $(git config remote.origin.push) = refs/heads/master:refs/heads/upstream - test $(git config remote.origin.fetch) = refs/heads/master:refs/heads/origin + cat push_expected -\EOF Broken -chain. + refs/heads/master:refs/heads/upstream + refs/heads/master:refs/heads/upstream2 + EOF + cat fetch_expected -\EOF Ditto. + refs/heads/master:refs/heads/origin + refs/heads/master:refs/heads/origin2 + EOF + git config --get-all remote.origin.fetch push_actual + git config --get-all remote.origin.fetch fetch_actual + test_cmp push_expected push_actual + test_cmp fetch_expected fetch_actual ) ' -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
