* Re: problem cloning via http since v1.6.6-rc0
From: Tay Ray Chuan @ 2010-01-21 7:51 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: Ilari Liusvaara, Shawn O. Pearce, git
In-Reply-To: <be6fef0d1001202247l7467a14ap8181eb3ed830167a@mail.gmail.com>
Hi,
On Thu, 21 Jan 2010 14:47:37 +0800
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Thu, Jan 21, 2010 at 1:08 PM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> > Looks like remote-curl (which handles http) issues request for:
> >
> > '.../info/refs?service=git-upload-pack'
> >
> > And expects that if there is no smart HTTP server there for the request to be
> > interpretted as:
> >
> > '.../info/refs'
> >
> > (i.e. webserver would ignore the query). This isn't true for git.debian.org.
> > Requesting the latter works (and the data formatting looks sane), but the
> > former is 404. This causes the fetch to fail.
>
> afaik, putting a "?var1=val1&var2=...." still makes it a normal GET
> request, even if the url requested is just a plain file and not some
> cgi handler that uses those variables/values.
Yaroslav, sorry for making you run in circles - it really is git's
fault (sorta).
In recent versions of git, we were sending out the GET request for
info/refs with a query string (?serivce=<service name>). I'm not sure
why, but your server is not playing nice when the query string is
appended.
Could you try this patch and see if it solves the issue? I manage to
clone your repo successfully with it.
--
Cheers,
Ray Chuan
-->8--
Subject: [PATCH] http/remote-curl: coddle picky servers
When "info/refs" is a static file and not behind a CGI handler, some
servers may not handle a GET request for it with a query string
appended (eg. "?foo=bar") properly.
If such a request fails, retry it sans the query string, and also
discount the possibility of using the "smart" protocol (since no
service is specified with "?service=<service name>").
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
remote-curl.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 1361006..a904164 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -102,7 +102,7 @@ static struct discovery* discover_refs(const char *service)
struct strbuf buffer = STRBUF_INIT;
struct discovery *last = last_discovery;
char *refs_url;
- int http_ret, is_http = 0;
+ int http_ret, is_http = 0, proto_git_candidate = 1;
if (last && !strcmp(service, last->service))
return last;
@@ -121,6 +121,19 @@ static struct discovery* discover_refs(const char *service)
init_walker();
http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
+
+ /* try again with "plain" url (no ? or & appended) */
+ if (http_ret != HTTP_OK) {
+ free(refs_url);
+ strbuf_reset(&buffer);
+
+ proto_git_candidate = 0;
+ strbuf_addf(&buffer, "%s/info/refs", url);
+ refs_url = strbuf_detach(&buffer, NULL);
+
+ http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
+ }
+
switch (http_ret) {
case HTTP_OK:
break;
@@ -137,7 +150,8 @@ static struct discovery* discover_refs(const char *service)
last->buf_alloc = strbuf_detach(&buffer, &last->len);
last->buf = last->buf_alloc;
- if (is_http && 5 <= last->len && last->buf[4] == '#') {
+ if (is_http && proto_git_candidate
+ && 5 <= last->len && last->buf[4] == '#') {
/* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
--
1.6.6.1.337.g96bc8
^ permalink raw reply related
* [PATCH] Make test case numbers unique
From: Johannes Sixt @ 2010-01-21 7:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
...ex-gitfile.sh => t2105-update-index-gitfile.sh} | 0
...threedots.sh => t3416-rebase-onto-threedots.sh} | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename t/{t2104-update-index-gitfile.sh => t2105-update-index-gitfile.sh} (100%)
rename t/{t3415-rebase-onto-threedots.sh => t3416-rebase-onto-threedots.sh} (100%)
diff --git a/t/t2104-update-index-gitfile.sh b/t/t2105-update-index-gitfile.sh
similarity index 100%
rename from t/t2104-update-index-gitfile.sh
rename to t/t2105-update-index-gitfile.sh
diff --git a/t/t3415-rebase-onto-threedots.sh b/t/t3416-rebase-onto-threedots.sh
similarity index 100%
rename from t/t3415-rebase-onto-threedots.sh
rename to t/t3416-rebase-onto-threedots.sh
--
1.6.6.1.1385.ge9ce6.dirty
^ permalink raw reply
* Re: [PATCH] Make test case numbers unique
From: Junio C Hamano @ 2010-01-21 8:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4B5808CF.20006@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Yuck; thanks.
I wonder if we can automate this somehow. Perhaps teach pre-applypatch
about this...
^ permalink raw reply
* Re: [PATCH] Make test case numbers unique
From: Johannes Sixt @ 2010-01-21 8:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfx5zx4yl.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> I wonder if we can automate this somehow. Perhaps teach pre-applypatch
> about this...
http://thread.gmane.org/gmane.comp.version-control.git/126701/focus=126708
-- Hannes
^ permalink raw reply
* [PATCH] Make 'rerere forget' work from a subdirectory.
From: Johannes Sixt @ 2010-01-21 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <4B56F916.7090503@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
It forgot to apply the prefix to the paths given on the command line.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Johannes Sixt schrieb:
> Junio C Hamano schrieb:
>> * jc/cache-unmerge (2009-12-25) 9 commits
>> (merged to 'next' on 2010-01-13 at 2290c44)
>> + rerere forget path: forget recorded resolution
>
> Heads up: there is something fishy with the pathspec on Windows (foo\bar
> is not recognized as foo/bar, but it should be). Will investigate.
A call get_pathspec is necessary, which applies the prefix and also
converts Windows's backslashes to forward-slashes.
-- Hannes
builtin-rerere.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 25f507a..34f9ace 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -120,8 +120,10 @@ int cmd_rerere(int argc, const char **argv, const char *prefix)
if (argc < 2)
return rerere(flags);
- if (!strcmp(argv[1], "forget"))
- return rerere_forget(argv + 2);
+ if (!strcmp(argv[1], "forget")) {
+ const char **pathspec = get_pathspec(prefix, argv + 2);
+ return rerere_forget(pathspec);
+ }
fd = setup_rerere(&merge_rr, flags);
if (fd < 0)
--
1.6.6.1.1388.g96b4
^ permalink raw reply related
* Re: [PATCH] Make 'rerere forget' work from a subdirectory.
From: Junio C Hamano @ 2010-01-21 8:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B580F14.5060105@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> It forgot to apply the prefix to the paths given on the command line.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Thanks; will squash this in (which fails without and passes with your patch).
t/t2030-unresolve-info.sh | 71 +++++++++++++++++++++++++++++++--------------
1 files changed, 49 insertions(+), 22 deletions(-)
diff --git a/t/t2030-unresolve-info.sh b/t/t2030-unresolve-info.sh
index a38bd6d..cb7effe 100755
--- a/t/t2030-unresolve-info.sh
+++ b/t/t2030-unresolve-info.sh
@@ -36,21 +36,22 @@ prime_resolve_undo () {
test_must_fail git merge third^0 &&
echo merge does not leave anything &&
check_resolve_undo empty &&
- echo different >file &&
- git add file &&
+ echo different >fi/le &&
+ git add fi/le &&
echo resolving records &&
- check_resolve_undo recorded file initial:file second:file third:file
+ check_resolve_undo recorded fi/le initial:fi/le second:fi/le third:fi/le
}
test_expect_success setup '
- test_commit initial file first &&
+ mkdir fi &&
+ test_commit initial fi/le first &&
git branch side &&
git branch another &&
- test_commit second file second &&
+ test_commit second fi/le second &&
git checkout side &&
- test_commit third file third &&
+ test_commit third fi/le third &&
git checkout another &&
- test_commit fourth file fourth &&
+ test_commit fourth fi/le fourth &&
git checkout master
'
@@ -59,7 +60,7 @@ test_expect_success 'add records switch clears' '
test_tick &&
git commit -m merged &&
echo committing keeps &&
- check_resolve_undo kept file initial:file second:file third:file &&
+ check_resolve_undo kept fi/le initial:fi/le second:fi/le third:fi/le &&
git checkout second^0 &&
echo switching clears &&
check_resolve_undo cleared
@@ -70,15 +71,15 @@ test_expect_success 'rm records reset clears' '
test_tick &&
git commit -m merged &&
echo committing keeps &&
- check_resolve_undo kept file initial:file second:file third:file &&
+ check_resolve_undo kept fi/le initial:fi/le second:fi/le third:fi/le &&
echo merge clears upfront &&
test_must_fail git merge fourth^0 &&
check_resolve_undo nuked &&
- git rm -f file &&
+ git rm -f fi/le &&
echo resolving records &&
- check_resolve_undo recorded file initial:file HEAD:file fourth:file &&
+ check_resolve_undo recorded fi/le initial:fi/le HEAD:fi/le fourth:fi/le &&
git reset --hard &&
echo resetting discards &&
@@ -90,7 +91,7 @@ test_expect_success 'plumbing clears' '
test_tick &&
git commit -m merged &&
echo committing keeps &&
- check_resolve_undo kept file initial:file second:file third:file &&
+ check_resolve_undo kept fi/le initial:fi/le second:fi/le third:fi/le &&
echo plumbing clear &&
git update-index --clear-resolve-undo &&
@@ -100,7 +101,7 @@ test_expect_success 'plumbing clears' '
test_expect_success 'add records checkout -m undoes' '
prime_resolve_undo &&
git diff HEAD &&
- git checkout --conflict=merge file &&
+ git checkout --conflict=merge fi/le &&
echo checkout used the record and removed it &&
check_resolve_undo removed &&
echo the index and the work tree is unmerged again &&
@@ -110,12 +111,12 @@ test_expect_success 'add records checkout -m undoes' '
test_expect_success 'unmerge with plumbing' '
prime_resolve_undo &&
- git update-index --unresolve file &&
+ git update-index --unresolve fi/le &&
git ls-files -u >actual &&
test $(wc -l <actual) = 3
'
-test_expect_success 'rerere and rerere --forget' '
+test_expect_success 'rerere and rerere forget' '
mkdir .git/rr-cache &&
prime_resolve_undo &&
echo record the resolution &&
@@ -123,20 +124,46 @@ test_expect_success 'rerere and rerere --forget' '
rerere_id=$(cd .git/rr-cache && echo */postimage) &&
rerere_id=${rerere_id%/postimage} &&
test -f .git/rr-cache/$rerere_id/postimage &&
- git checkout -m file &&
+ git checkout -m fi/le &&
echo resurrect the conflict &&
- grep "^=======" file &&
+ grep "^=======" fi/le &&
echo reresolve the conflict &&
git rerere &&
- test "z$(cat file)" = zdifferent &&
+ test "z$(cat fi/le)" = zdifferent &&
echo register the resolution again &&
- git add file &&
- check_resolve_undo kept file initial:file second:file third:file &&
+ git add fi/le &&
+ check_resolve_undo kept fi/le initial:fi/le second:fi/le third:fi/le &&
test -z "$(git ls-files -u)" &&
- git rerere forget file &&
+ git rerere forget fi/le &&
! test -f .git/rr-cache/$rerere_id/postimage &&
tr "\0" "\n" <.git/MERGE_RR >actual &&
- echo "$rerere_id file" >expect &&
+ echo "$rerere_id fi/le" >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'rerere and rerere forget (subdirectory)' '
+ rm -fr .git/rr-cache &&
+ mkdir .git/rr-cache &&
+ prime_resolve_undo &&
+ echo record the resolution &&
+ (cd fi && git rerere) &&
+ rerere_id=$(cd .git/rr-cache && echo */postimage) &&
+ rerere_id=${rerere_id%/postimage} &&
+ test -f .git/rr-cache/$rerere_id/postimage &&
+ (cd fi && git checkout -m le) &&
+ echo resurrect the conflict &&
+ grep "^=======" fi/le &&
+ echo reresolve the conflict &&
+ (cd fi && git rerere) &&
+ test "z$(cat fi/le)" = zdifferent &&
+ echo register the resolution again &&
+ (cd fi && git add le) &&
+ check_resolve_undo kept fi/le initial:fi/le second:fi/le third:fi/le &&
+ test -z "$(git ls-files -u)" &&
+ (cd fi && git rerere forget le) &&
+ ! test -f .git/rr-cache/$rerere_id/postimage &&
+ tr "\0" "\n" <.git/MERGE_RR >actual &&
+ echo "$rerere_id fi/le" >expect &&
test_cmp expect actual
'
^ permalink raw reply related
* Re: git notes: notes
From: Michael J Gruber @ 2010-01-21 8:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Joey Hess, git, Johannes Schindelin, Jeff King, Johan Herland
In-Reply-To: <7veilk1o3s.fsf@alter.siamese.dyndns.org>
[Adding cc from elsewhere in this thread, for fairness.]
Junio C Hamano venit, vidit, dixit 20.01.2010 22:08:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Junio C Hamano venit, vidit, dixit 20.01.2010 21:10:
>>> Joey Hess <joey@kitenet.net> writes:
>>>
>>>> Do you think it makes sense for even git log --format=format:%s to be
>>>> porcelain and potentially change when new features are used?
>>>
>>> If the series changed the meaning of "%s" format to mean "the subject of
>>> the commit and notes information", with or without documenting it, then it
>>> is just a bug we would like to fix.
>>
>> No, but outputting the note as part of the log is the standard. So for
>> example, when you do a format-patch | apply cycle, format-patch will
>> insert the note as part of the commit message, and apply will *store*
>> the note text (including Note:\n) as part of the commit message of the
>> new commit.
>
> Thanks; that was the kind of breakage report I was looking for (and wished
> to have heard a lot earlier). Personally I find it is unexcusable that
> format-patch defaults to giving notes.
>
>> So, I would say the notes feature is not that well integrated right now,
>
> No question about it.
>
>> I'm not complaining, I actually have this on a maybe-to-do list, but the
>> way the series went kept me from investing time.
>
> Hmm, that hints there is a failure in the review and merge process. Care
> to explain how we could have done better please?
Well, I can only recall why it kept *me* from investing more time. I
actually have very little free time available, I contribute to Git
because it's fun, or I want a certain feature, or, admittedly, having a
commit in a project like Git gives me a certain satisfaction.
The notes feature looked very promising to me, and when Dscho came up
with it (or followed up on someone else's proposal, I don't remember) I
invested time in testing and contributing (minor) fixes. Then the series
took on a life on it's own, first "disappearing" (when I was wondering
if anything is going forward), then reappearing with (not only my)
commits squashed in (which took away the satisfaction part), then going
through a lengthy technical discussion on fan-out schemes (which was
necessary, but took away the fun part). [The last two parts may have
been the other way round, which doesn't matter.]
When the first part of the series landed I began to look at it again and
use it for the comments which go after the "--" part of a patch, only to
find out that format-patch issue. I noticed the bad consequence on
format-patch|apply only later. So I looked at the code, the log flags,
and was about to code when the notes API changed again (on pu). So I
decided to wait until the API is baked (that decision may have been
influenced by my expectation that my patches would get squashed in
again) and to fix that issue before 1.7.0.
Note that I have to match the project's necessities with time
availability on my side - otherwise I would have written that patch when
more of that series had landed. Now I reported it because it came up in
some disguise (and didn't want anyone spend time needlessly fixing a
side issue), and I'm not the one fixing it, but that's fine.
Besides the sociological aspect, I think you mentioned the main
technical aspects:
* If you introduce a new features, write extensive tests covering
non-uses and mixed uses of the feature.
* Write redundancy tests, such as checking that format-patch|apply and
apply|format-patch both amount to the "identity" in the appropriate sense.
Right now we do very atomic testing, which does have its merits (for
determining the cause of a breakage). But since many features and
commands are not orthogonal, atomic testing does not test for side
effects, and test repos are minimal. Trying to test for specific
combinations makes you miss some combinations, especially combinations
with future features. But testing for those identity operations
(quasi-noops, or cycles) should ensure some consistency.
Maybe we should have a test repo which has all kinds of features turned
on and used, and on which a set of those identities are tested. With
every new feature, the repo as well as the set of supposed identities
would need to be amended (maybe by cloning the repo, adding commits, and
testing on an increasing set of repos). That would have caught at least
the current issue immediately.
Cheers,
Michael
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #06; Wed, 20)
From: Johan Herland @ 2010-01-21 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git
In-Reply-To: <7vvdeww187.fsf@alter.siamese.dyndns.org>
On Thursday 21 January 2010, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > On Thursday 21 January 2010, Sverre Rabbelier wrote:
> >> On Thu, Jan 21, 2010 at 01:52, Junio C Hamano <gitster@pobox.com>
wrote:
> >> > * jh/notes (2010-01-17) 23 commits
> >> > [...]
> >> > Updated with a re-roll.
> >>
> >> Just checking, you reverted all from next (with exception of the first
> >> three), and now re-queued it to pu, with the first three still in
> >> next? Or did I mis-remember and did only the first three make it to
> >> next in the first place?
> >
> > You misremembered. Only the three first were merged to 'next'. Junio
> > was about to merge the rest, but I asked him to hold until I had
> > produced the current iteration.
>
> I've been meaning to merge the first three to 'master', as many people
> have been running 'next' and new features tend to be exercised less by
> those on 'master' than on 'next', and it would be beneficial to make
> 'master' at 1.7.0-rc0 as close to what we have had in 'next' for a long
> time.
>
> Worries?
Maybe. I've got a maybe-todo entry about (yet again) rewriting the fast-
import handling of notes to use the updated notes API (which now can handle
non-notes, and therefore should be better suited for fast-import's use
case). However, the result is only worth submitting if it _both_ decreases
code duplication between fast-import.c and notes.c, _and_ decreases the
overall impact on fast-import.c. I don't know when I'll get around to doing
this experiment, so feel free to ignore it for now.
In any case, I totally understand if you'd rather want to hold the entire
notes series in 'pu', and instead focus on fixing the bugs in what's already
been released.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* How do I get a list of tracking branches
From: Howard Miller @ 2010-01-21 9:25 UTC (permalink / raw)
To: git
Hi,
I know I can go and look at the config file and get this info but is
there a simple command that shows which local branches are tracking
remote branches? It seems like a very obvious thing to want to know
but I can't find it. 'branch -av' even shows 'n behind' and/or 'n
ahead' but not *what* it is behind or ahead.
Thanks!
^ permalink raw reply
* Re: [PATCH] Make 'rerere forget' work from a subdirectory.
From: Johannes Sixt @ 2010-01-21 9:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hrbx31c.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Thanks; will squash this in (which fails without and passes with your patch).
Thanks; it catches the breakage and verifies the fix here on Windows
as well.
-- Hannes
^ permalink raw reply
* Re: git locate
From: Michael J Gruber @ 2010-01-21 9:42 UTC (permalink / raw)
To: SungHyun Nam; +Cc: Git List
In-Reply-To: <4B579BA8.8050000@gmail.com>
SungHyun Nam venit, vidit, dixit 21.01.2010 01:11:
> Hello,
>
> Johannes Schindelin wrote:
>>
>> On Tue, 19 Jan 2010, Jakub Narebski wrote:
>>
>>> Johannes Schindelin<Johannes.Schindelin@gmx.de> writes:
>>>
>>>> On Wed, 20 Jan 2010, John Tapsell wrote:
>>>>
>>>>> Could we add a: git locate<filename> or git find<filename>
>>>>
>>>> How about "git ls-files \*<filename>"?
>>>
>>> Or "git ls-files '*filename'...
>>>
>>> ... but how to make an (git) alias for this?
>>
>> Add something like this to your $HOME/.gitconfig:
>>
>> [alias]
>> locate = !sh -c 'git ls-files "\\*$1"' -
>
> The alias 'git locate' and the command 'git ls-files' runs
> differently if I run them in a subdirectory.
> Is it expected?
>
> [master] ~/srcs/git[299]$ git locate urls.txt
> Documentation/urls.txt
> [master] ~/srcs/git[300]$ git ls-files '*urls.txt'
> Documentation/urls.txt
> [master] ~/srcs/git[301]$ cd t
> [master] ~/srcs/git/t[302]$ git locate urls.txt
> Documentation/urls.txt
> [master] ~/srcs/git/t[303]$ git ls-files '*urls.txt'
> [master] ~/srcs/git/t[304]$
Yes, aliases with "!" are executed from the root of the worktree,
ls-files from the current wd.
Michael
^ permalink raw reply
* Re: git locate
From: Štěpán Němec @ 2010-01-21 9:51 UTC (permalink / raw)
To: SungHyun Nam; +Cc: Git List
In-Reply-To: <4B579BA8.8050000@gmail.com>
On Thu, Jan 21, 2010 at 09:11:20AM +0900, SungHyun Nam wrote:
> Hello,
>
> Johannes Schindelin wrote:
> >
> >On Tue, 19 Jan 2010, Jakub Narebski wrote:
> >
> >>Johannes Schindelin<Johannes.Schindelin@gmx.de> writes:
> >>
> >>>On Wed, 20 Jan 2010, John Tapsell wrote:
> >>>
> >>>> Could we add a: git locate<filename> or git find<filename>
> >>>
> >>>How about "git ls-files \*<filename>"?
> >>
> >>Or "git ls-files '*filename'...
> >>
> >>... but how to make an (git) alias for this?
> >
> >Add something like this to your $HOME/.gitconfig:
> >
> >[alias]
> > locate = !sh -c 'git ls-files "\\*$1"' -
>
> The alias 'git locate' and the command 'git ls-files' runs
> differently if I run them in a subdirectory.
> Is it expected?
>
> [master] ~/srcs/git[299]$ git locate urls.txt
> Documentation/urls.txt
> [master] ~/srcs/git[300]$ git ls-files '*urls.txt'
> Documentation/urls.txt
> [master] ~/srcs/git[301]$ cd t
> [master] ~/srcs/git/t[302]$ git locate urls.txt
> Documentation/urls.txt
> [master] ~/srcs/git/t[303]$ git ls-files '*urls.txt'
> [master] ~/srcs/git/t[304]$
Yeah, as stated in another part of the Wiki page Dscho referred to
(namely the "Serve repo on the spot" section):
"It makes use of the fact that (currently, as of git 1.5.6.1) non-git
alias are executed from the top-level dir of a repo."
("non-git" == those starting with "!", which is the case here)
Štěpán
^ permalink raw reply
* Re: How do I get a list of tracking branches
From: Michael J Gruber @ 2010-01-21 9:52 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a1001210125j156b61afs64bb915a934530c6@mail.gmail.com>
Howard Miller venit, vidit, dixit 21.01.2010 10:25:
> Hi,
>
> I know I can go and look at the config file and get this info but is
> there a simple command that shows which local branches are tracking
> remote branches? It seems like a very obvious thing to want to know
> but I can't find it. 'branch -av' even shows 'n behind' and/or 'n
> ahead' but not *what* it is behind or ahead.
The latter info you get with git branch -vv.
But you said you wanted to know which local branches have upstreams. Or
do you want to know which local branches have a specific remote as upstream?
Michael
^ permalink raw reply
* Re: How do I get a list of tracking branches
From: Howard Miller @ 2010-01-21 10:03 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B5823C1.9010904@drmicha.warpmail.net>
>> I know I can go and look at the config file and get this info but is
>> there a simple command that shows which local branches are tracking
>> remote branches? It seems like a very obvious thing to want to know
>> but I can't find it. 'branch -av' even shows 'n behind' and/or 'n
>> ahead' but not *what* it is behind or ahead.
>
> The latter info you get with git branch -vv.
>
> But you said you wanted to know which local branches have upstreams. Or
> do you want to know which local branches have a specific remote as upstream?
>
> Michael
Hi Michael,
Thanks. That's *exactly* what I needed. It's just an extension of my
general rant that while git makes it very easy to create branches it
also makes it very easy to forget why you created them. Or it's easy
for me to forget anyway :-)
Howard
^ permalink raw reply
* Re: [PATCH 1/2] Allow to override mergetool.prompt with $GIT_MERGETOOL*_PROMPT
From: Sebastian Schuberth @ 2010-01-21 10:10 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <20100121074427.GA26973@gmail.com>
On 21.01.2010 08:44, David Aguilar wrote:
> The GIT_DIFFTOOL*_PROMPT variables are implementation details
> about how git-difftool passes options to git-difftool--helper.
> We don't advertise them in the documentation so we probably
> shouldn't support them aside from what is needed for
> git-difftool. We can drop this part.
Thanks for the explanation, I already was wondering why they don't
appear in the docs.
> git-difftool falling back to mergetool.prompt when
> difftool.prompt is not available is good, especially
> since we advertise that feature.
>
> Once you drop the local declarations and the env. variable
> it should be good to go. Patch v2, soon?
If I drop env. variable support, I don't see much reason to introduce
the should_prompt_merge () at all. I'd then leave git-mergetool* as-is,
and directly run "git config --bool mergetool.prompt" inside
should_prompt_diff (). Would that be OK with you?
--
Sebastian Schuberth
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Ilari Liusvaara @ 2010-01-21 10:35 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Yaroslav Halchenko, git, Shawn O. Pearce
In-Reply-To: <be6fef0d1001202247l7467a14ap8181eb3ed830167a@mail.gmail.com>
On Thu, Jan 21, 2010 at 02:47:37PM +0800, Tay Ray Chuan wrote:
> Hi,
>
> On Thu, Jan 21, 2010 at 1:08 PM, Ilari Liusvaara
> >
> > (i.e. webserver would ignore the query). This isn't true for git.debian.org.
> > Requesting the latter works (and the data formatting looks sane), but the
> > former is 404. This causes the fetch to fail.
>
> afaik, putting a "?var1=val1&var2=...." still makes it a normal GET
> request, even if the url requested is just a plain file and not some
> cgi handler that uses those variables/values.
Yes, it is normal GET (POST would be something else). And wheither it is CGI
doesn't come into play for request since client decides wheither to send GET
or POST and wheither to include query or not.
Query is just technical name for part between ? and # (or end of HTTP URL),
and can be present in any type of request that accepts http:// URL.
As said, code expects query part to be ignored if target is regular file
but broke when it didn't get ignored.
-Ilari
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Tay Ray Chuan @ 2010-01-21 11:36 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Yaroslav Halchenko, git, Shawn O. Pearce
In-Reply-To: <20100121103500.GA19285@Knoppix>
Hi,
On Thu, Jan 21, 2010 at 6:35 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Thu, Jan 21, 2010 at 02:47:37PM +0800, Tay Ray Chuan wrote:
>> Hi,
>>
>> On Thu, Jan 21, 2010 at 1:08 PM, Ilari Liusvaara
>> >
>> > (i.e. webserver would ignore the query). This isn't true for git.debian.org.
>> > Requesting the latter works (and the data formatting looks sane), but the
>> > former is 404. This causes the fetch to fail.
>>
>> afaik, putting a "?var1=val1&var2=...." still makes it a normal GET
>> request, even if the url requested is just a plain file and not some
>> cgi handler that uses those variables/values.
>
> Yes, it is normal GET (POST would be something else). And wheither it is CGI
> doesn't come into play for request since client decides wheither to send GET
> or POST and wheither to include query or not.
>
> Query is just technical name for part between ? and # (or end of HTTP URL),
> and can be present in any type of request that accepts http:// URL.
yes, indeed, I misread your message. Your idea of the query string
affecting the server response didn't strike me then.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 2/2] rev-parse --branches/--tags/--remotes=pattern
From: Johannes Sixt @ 2010-01-21 12:51 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git, Junio C Hamano
In-Reply-To: <1263980906-11058-2-git-send-email-ilari.liusvaara@elisanet.fi>
Works for me, thank you very much!
Junio, kindly squash in these speeling fixes in both patches:
sed -i 's/impiled/implied/g' `git diff HEAD^ --name-only Documentation/`
-- Hannes
^ permalink raw reply
* [GIT-GUI PATCH] Correctly launch gitk for branch whose name matches a local file
From: Peter Krefting @ 2010-01-21 12:15 UTC (permalink / raw)
To: Git Mailing List
When trying to run gitk on a branch name whose name matches a local file,
it will toss an error saying that the name is ambiguous. Adding a pair
of dashes will make gitk parse the options to the left of it as branch
names. Since wish eats the first pair of dashes we throw at it, we need
to add a second one to ensure they get through.
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Reproducible test case:
1. git clone git://git.debian.org/users/peterk/lyskom-server.git
2. cd lyskom-server
3. git gui + "Visualize debian's history"
diff --git a/git-gui.sh b/git-gui.sh
index 822d598..2114945 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1941,7 +1941,7 @@ proc do_gitk {revs} {
cd [file dirname [gitdir]]
set env(GIT_DIR) [file tail [gitdir]]
- eval exec $cmd $revs &
+ eval exec $cmd $revs "--" "--" &
if {$old_GIT_DIR eq {}} {
unset env(GIT_DIR)
--
1.6.6
^ permalink raw reply related
* Re: [PATCH 2/2] rev-parse --branches/--tags/--remotes=pattern
From: Michael J Gruber @ 2010-01-21 13:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ilari Liusvaara, git, Junio C Hamano
In-Reply-To: <4B584DDD.7060701@viscovery.net>
Johannes Sixt venit, vidit, dixit 21.01.2010 13:51:
> Works for me, thank you very much!
>
> Junio, kindly squash in these speeling fixes in both patches:
>
> sed -i 's/impiled/implied/g' `git diff HEAD^ --name-only Documentation/`
>
Also, the option descriptions are kind of staccato English right now,
lacking a few "the" here and there. Should we fix this or simply leave
it at that?
Michael
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Yaroslav Halchenko @ 2010-01-21 14:00 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Ilari Liusvaara, Shawn O. Pearce, git
In-Reply-To: <20100121155136.17b59e8f.rctay89@gmail.com>
Hi Tay Ray,
That patch works fine for me ;) I only hope it would get accepted into
bugfix and next dev release (I guess it might annoy some of apache
admins a bit due to increase of their errors.log now even for well
maintained repositories, but well -- that is life ;-) )
Thanks!
Yarik
On Thu, 21 Jan 2010, Tay Ray Chuan wrote:
> > afaik, putting a "?var1=val1&var2=...." still makes it a normal GET
> > request, even if the url requested is just a plain file and not some
> > cgi handler that uses those variables/values.
> Yaroslav, sorry for making you run in circles - it really is git's
> fault (sorta).
> In recent versions of git, we were sending out the GET request for
> info/refs with a query string (?serivce=<service name>). I'm not sure
> why, but your server is not playing nice when the query string is
> appended.
> Could you try this patch and see if it solves the issue? I manage to
> clone your repo successfully with it.
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
^ permalink raw reply
* Re: git-merge segfault in 1.6.6 and master
From: Miklos Vajna @ 2010-01-21 14:00 UTC (permalink / raw)
To: Tim Olsen; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <4B577C3F.7040608@brooklynpenguin.com>
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
On Wed, Jan 20, 2010 at 04:57:19PM -0500, Tim Olsen <tim@brooklynpenguin.com> wrote:
> It appears that a segfault still happens with your patch applied, but
> this time it is caught:
>
> tolsen@neurofunk:~/git/site-build-dav-sync-05 [git:build-dav-sync-05]$
> git merge origin/deployed
> error: merge-recursive died of signal 11
> Merge with strategy recursive failed.
> tolsen@neurofunk:~/git/site-build-dav-sync-05 [git:build-dav-sync-05]$
>
>
> > "common = NULL" means merged_common_ancestors->tree is NULL in the caller.
> > Somebody is passing a bogus commit in "ca" (aka common ancestors) list
> > when calling merge_recursive(), or forgetting to parse them before calling
> > it. In your debugger could you find out where it comes from and what it
> > has before this call into merge_trees() is made? Specifically, what the
> > "ca" list at 0x7b3c00 contains, and how "merged_common_ancestors" at
> > 0x121e360 looks like. in this trace we see below:
>
> Here is the replay of the flow of execution from the first time we enter
> merge_recursive(). The repository has been modified slightly so the
> pointers are different this time but the segfault is still happening
> (I'll stop modifying the repository now ;-) .
Two ideas to help debugging:
- Can you try if this happens in a new repo as well? (If not, is the
repo public?) If yes, can you write a script that shows your problem?
- Can you see if this happens with v1.6.0? If yes, can you bisect it?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] http/remote-curl: coddle picky servers
From: Tay Ray Chuan @ 2010-01-21 14:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Yaroslav Halchenko, Ilari Liusvaara,
Shawn O. Pearce
In-Reply-To: <20100121140054.GH18213@onerussian.com>
When "info/refs" is a static file and not behind a CGI handler, some
servers may not handle a GET request for it with a query string
appended (eg. "?foo=bar") properly.
If such a request fails, retry it sans the query string. In addition,
ensure that the "smart" http protocol is not used (a service has to be
specified with "?service=<service name>" to be conformant).
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Reported-and-tested-by: Yaroslav Halchenko <debian@onerussian.com>
---
remote-curl.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 1361006..a904164 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -102,7 +102,7 @@ static struct discovery* discover_refs(const char *service)
struct strbuf buffer = STRBUF_INIT;
struct discovery *last = last_discovery;
char *refs_url;
- int http_ret, is_http = 0;
+ int http_ret, is_http = 0, proto_git_candidate = 1;
if (last && !strcmp(service, last->service))
return last;
@@ -121,6 +121,19 @@ static struct discovery* discover_refs(const char *service)
init_walker();
http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
+
+ /* try again with "plain" url (no ? or & appended) */
+ if (http_ret != HTTP_OK) {
+ free(refs_url);
+ strbuf_reset(&buffer);
+
+ proto_git_candidate = 0;
+ strbuf_addf(&buffer, "%s/info/refs", url);
+ refs_url = strbuf_detach(&buffer, NULL);
+
+ http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
+ }
+
switch (http_ret) {
case HTTP_OK:
break;
@@ -137,7 +150,8 @@ static struct discovery* discover_refs(const char *service)
last->buf_alloc = strbuf_detach(&buffer, &last->len);
last->buf = last->buf_alloc;
- if (is_http && 5 <= last->len && last->buf[4] == '#') {
+ if (is_http && proto_git_candidate
+ && 5 <= last->len && last->buf[4] == '#') {
/* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
--
1.6.6.1.337.g96bc8
^ permalink raw reply related
* Re: [PATCH] http/remote-curl: coddle picky servers
From: Shawn O. Pearce @ 2010-01-21 15:56 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Junio C Hamano, Yaroslav Halchenko, Ilari Liusvaara
In-Reply-To: <20100121224100.624c9c9d.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> When "info/refs" is a static file and not behind a CGI handler, some
> servers may not handle a GET request for it with a query string
> appended (eg. "?foo=bar") properly.
>
> If such a request fails, retry it sans the query string. In addition,
> ensure that the "smart" http protocol is not used (a service has to be
> specified with "?service=<service name>" to be conformant).
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> Reported-and-tested-by: Yaroslav Halchenko <debian@onerussian.com>
*grumble* stupid Apache *grumble*
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: Error when cloning gc'ed repository
From: Andre Loker @ 2010-01-21 16:02 UTC (permalink / raw)
To: git
In-Reply-To: <hj6ms0$vcg$1@ger.gmane.org>
Andre Loker wrote:
> Hi,
>
> $ git clone git@theserver:the/repository.git
> Initialized empty Git repository in /e/Temp/dr/.git/
> remote: Counting objects: 1396, done.
> remote: Compressing objects: 100% (654/654), done.
> fatal: The remote end hung up unexpectedly
> fatal: early EOFs: 47% (657/1396)
> fatal: index-pack failed
To answer the question myself: it seems that it is a problem with
openssh under cygwin 1.7.1. I found a similar problem here:
http://www.mail-archive.com/cygwin@cygwin.com/msg103749.html
The proposed workaround is to use plink instead of openssh. I tried it
and so far it seems to work. It's not as nice as openssh, but at least
it's a workaround until the issue is solved.
Kind Regards,
Andre
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox