* Re: [RFC] Add a new email notification script to "contrib"
From: Michael Haggerty @ 2012-11-22 7:32 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Andy Parkins, Sitaram Chamarty, Stefan Näwe,
Junio C Hamano, Marc Branchaud, Matthieu Moy
In-Reply-To: <CACBZZX4gzgTZCk78PYpYHnKdwQ0vScoLz02tuAuUQRXVVXSLVg@mail.gmail.com>
On 11/08/2012 04:38 PM, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 8, 2012 at 1:17 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
>>> But in addition to that we have our own custom E-Mail notification
>>> scripts for:
>>>
>>> * People can subscribe to changes to certain files. I.e. if you
>>> modify very_important.c we'll send an E-Mail to a more widely seen
>>> review list.
>>>
>>> * Invididuals can also edit a config file to watch individual files /
>>> glob patterns of files, e.g. src/main.c or src/crypto*
>>
[...]
>
> I think just sending the individual patch e-mails to all people who
> subscribe to paths that got changed in that patch that match their
> watchlist makes sense.
I forgot to mention, but Environment.get_revision_recipients() has all
the information needed to implement such a policy. You could override
this method in your own Environment class to get the behavior that you want.
> That script *also* supports sending the whole batch of patches pushed
> in that push to someone watching any file that got modified in one of
> the patches, in case you also want to get other stuff pushed in pushes
> for files you're interested in.
This is not yet possible without more intrusive code changes.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Remote hung up during `git fetch`
From: Yichao Yu @ 2012-11-22 4:18 UTC (permalink / raw)
To: git
Hi everyone,
I want to build packages for snap shoot of different branches from
different remote git repositories in the same local directory (so that
I don't need to recompile everything everytime.) and I am using a
combination of `git clone/checkout/reset/fetch` to do that. However,
during git-fetch, the remote sometimes stop responding or simply reset
the connection. This happens occasionally at least for both ssh and
git protocol (not sure about http/https) on github, bitbucket and also
kernel.org so I think it is probably not due to a weird behavior of a
certain host. Does anyone know the reason or is there anything I have
done wrong? And is there a better way to set the local tree to a
certain branch at a certain url? THX
My git version is ArchLinux package 1.8.0-1. (timezone
America/New_York in case the time stamp somehow matters)
Here is a script that always triggers the issue (at least now) and
it's output. (No I am not trying to merge git and the kernel... These
are just random public repos on kernel.org that can trigger the issue.
Although I am pulling from two repos from different project here, the
same thing can also happen on other hosts when the two repos are
actually the same project)
Yichao Yu
------------------------------------------------------------------
#!/bin/bash
repo_name=git
# remote1='git://github.com/torvalds/linux.git'
remote1='git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'
branch1='master'
# remote2='git://github.com/git/git.git'
remote2='git://git.kernel.org/pub/scm/git/git.git'
branch2='next'
git clone --depth 1 --single-branch --branch "$branch1" "$remote1" "$repo_name"
cd "$repo_name"
git fetch -vvv "$remote2" # "$branch2:$branch2"
-----------------------------------------------
Cloning into 'git'...
remote: Counting objects: 43215, done.
remote: Compressing objects: 100% (41422/41422), done.
remote: Total 43215 (delta 3079), reused 22032 (delta 1247)
Receiving objects: 100% (43215/43215), 119.06 MiB | 1.60 MiB/s, done.
Resolving deltas: 100% (3079/3079), done.
Checking out files: 100% (40905/40905), done.
fatal: destination path 'git' already exists and is not an empty directory.
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386
have db9d8c60266a5010e905829e10cd722519e14777
done
fatal: The remote end hung up unexpectedly
^ permalink raw reply
* [PATCH 3/5] git-send-email: remove invalid addresses earlier
From: Krzysztof Mazur @ 2012-11-22 18:12 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen, Krzysztof Mazur
In-Reply-To: <1353607932-10436-1-git-send-email-krzysiek@podlesie.net>
Some addresses are passed twice to unique_email_list() and invalid addresses
may be reported twice per send_message. Now we warn about them earlier
and we also remove invalid addresses.
This also removes using of undefined values for string comparison
for invalid addresses in cc list processing.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
git-send-email.perl | 52 +++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 356f99d..5056fdc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -786,9 +786,11 @@ sub expand_one_alias {
}
@initial_to = expand_aliases(@initial_to);
-@initial_to = (map { sanitize_address($_) } @initial_to);
+@initial_to = validate_address_list(sanitize_address_list(@initial_to));
@initial_cc = expand_aliases(@initial_cc);
+@initial_cc = validate_address_list(sanitize_address_list(@initial_cc));
@bcclist = expand_aliases(@bcclist);
+@bcclist = validate_address_list(sanitize_address_list(@bcclist));
if ($thread && !defined $initial_reply_to && $prompting) {
$initial_reply_to = ask(
@@ -839,6 +841,28 @@ sub extract_valid_address {
return undef;
}
+sub extract_valid_address_or_die {
+ my $address = shift;
+ $address = extract_valid_address($address);
+ die "error: unable to extract a valid address from: $address\n"
+ if !$address;
+ return $address;
+}
+
+sub validate_address {
+ my $address = shift;
+ if (!extract_valid_address($address)) {
+ print STDERR "W: unable to extract a valid address from: $address\n";
+ return undef;
+ }
+ return $address;
+}
+
+sub validate_address_list {
+ return (grep { defined $_ }
+ map { validate_address($_) } @_);
+}
+
# Usually don't need to change anything below here.
# we make a "fake" message id by taking the current number
@@ -955,6 +979,10 @@ sub sanitize_address {
}
+sub sanitize_address_list {
+ return (map { sanitize_address($_) } @_);
+}
+
# Returns the local Fully Qualified Domain Name (FQDN) if available.
#
# Tightly configured MTAa require that a caller sends a real DNS
@@ -1017,14 +1045,13 @@ sub maildomain {
sub send_message {
my @recipients = unique_email_list(@to);
- @cc = (grep { my $cc = extract_valid_address($_);
+ @cc = (grep { my $cc = extract_valid_address_or_die($_);
not grep { $cc eq $_ || $_ =~ /<\Q${cc}\E>$/ } @recipients
}
- map { sanitize_address($_) }
@cc);
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc,@bcclist);
- @recipients = (map { extract_valid_address($_) } @recipients);
+ @recipients = (map { extract_valid_address_or_die($_) } @recipients);
my $date = format_2822_time($time++);
my $gitversion = '@@GIT_VERSION@@';
if ($gitversion =~ m/..GIT_VERSION../) {
@@ -1267,7 +1294,7 @@ foreach my $t (@files) {
foreach my $addr (parse_address_line($1)) {
printf("(mbox) Adding to: %s from line '%s'\n",
$addr, $_) unless $quiet;
- push @to, sanitize_address($addr);
+ push @to, $addr;
}
}
elsif (/^Cc:\s+(.*)$/) {
@@ -1376,6 +1403,9 @@ foreach my $t (@files) {
($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1));
$needs_confirm = "inform" if ($needs_confirm && $confirm_unconfigured && @cc);
+ @to = validate_address_list(sanitize_address_list(@to));
+ @cc = validate_address_list(sanitize_address_list(@cc));
+
@to = (@initial_to, @to);
@cc = (@initial_cc, @cc);
@@ -1431,14 +1461,10 @@ sub unique_email_list {
my @emails;
foreach my $entry (@_) {
- if (my $clean = extract_valid_address($entry)) {
- $seen{$clean} ||= 0;
- next if $seen{$clean}++;
- push @emails, $entry;
- } else {
- print STDERR "W: unable to extract a valid address",
- " from: $entry\n";
- }
+ my $clean = extract_valid_address_or_die($entry))
+ $seen{$clean} ||= 0;
+ next if $seen{$clean}++;
+ push @emails, $entry;
}
return @emails;
}
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* Re: [RFC] Add a new email notification script to "contrib"
From: Michael Haggerty @ 2012-11-22 7:27 UTC (permalink / raw)
To: marcnarc
Cc: Marc Branchaud, Ævar Arnfjörð Bjarmason, git,
Andy Parkins, Sitaram Chamarty, Stefan Näwe, Junio C Hamano,
Matthieu Moy
In-Reply-To: <509BD7E7.2010807@xiplink.com>
On 11/08/2012 05:03 PM, Marc Branchaud wrote:
> I look forward to trying out your updates. One thing I had to do to the
> original script was override get_envelopesender() in GenericEnvironment to
> use $USER if hooks.envelopesender is not set. (This is what the old
> post-receive-email script does.)
I was going to fix this, but it doesn't look to me like the old
post-receive-email script does what you claim. That script only uses
$envelopesender in the sendmail command line
/usr/sbin/sendmail -t -f "$envelopesender
, but if it is not set then the "-f" option is omitted entirely (it does
not default to $USER as you claim).
My script handles envelopesender the same way with respect to the
sendmail command line. The difference is that my script also tries to
set a "From: $envelopesender" line inside the emails, which can result
in "From: None" if envelopesender is not configured.
I suppose the correct thing to do is omit the "From:" line if no
envelopesender is known. But I don't understand your reason for wanting
envelopesender to default to $USER, which is probably not even a valid
email address. If, in your environment, $USER is the pusher, then you
might want "From: $pusher". I rather thought it is better to have a
uniform "From" address to make it easy for users to configure email
filtering on the emails. Instead I set the Reply-To field to the email
address of the person responsible for the change being described (i.e.,
the pusher for reference changes and the author for commit notifications).
Please explain better why you want the behavior changed.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH 4/5] git-send-email: ask what to do with an invalid email address
From: Krzysztof Mazur @ 2012-11-22 18:12 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen, Krzysztof Mazur
In-Reply-To: <1353607932-10436-1-git-send-email-krzysiek@podlesie.net>
We used to warn about invalid emails and just drop them. Such warnings
can be unnoticed by user or noticed after sending email when we are not
giving the "final sanity check [Y/n]?"
Now we quit by default.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Suggested-by: Junio C Hamano <gitster@pobox.com>
---
git-send-email.perl | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5056fdc..d42dca2 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -852,8 +852,16 @@ sub extract_valid_address_or_die {
sub validate_address {
my $address = shift;
if (!extract_valid_address($address)) {
- print STDERR "W: unable to extract a valid address from: $address\n";
- return undef;
+ print STDERR "error: unable to extract a valid address from: $address\n";
+ $_ = ask("What to do with this address? ([q]uit|[d]rop): ",
+ valid_re => qr/^(?:quit|q|drop|d)/i,
+ default => 'q');
+ if (/^d/i) {
+ return undef;
+ } elsif (/^q/i) {
+ cleanup_compose_files();
+ exit(0);
+ }
}
return $address;
}
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2] Teach rm to remove submodules when given with a trailing '/'
From: Jens Lehmann @ 2012-11-22 22:32 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Sixt, Junio C Hamano, Jeff King
In-Reply-To: <5090C54C.90902@viscovery.net>
Doing a "git rm submod/" on a submodule results in an error:
fatal: pathspec 'submod/' did not match any files
This is really inconvenient as e.g. using TAB completion in a shell on a
submodule automatically adds the trailing '/' when it completes the path
of the submodule directory. The user has then to remove the '/' herself to
make a "git rm" succeed. Doing a "git rm -r somedir/" is working fine, so
there is no reason why that shouldn't work for submodules too.
Teach git rm to not error out when a '/' is appended to the path of a
submodule. Achieve this by chopping off trailing slashes from the path
names given if they represent directories. Add tests to make sure that
logic only applies to directories and not to files.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 31.10.2012 07:29, schrieb Johannes Sixt:
> Am 10/30/2012 22:28, schrieb Jens Lehmann:
>> Am 29.10.2012 08:11, schrieb Johannes Sixt:
>>> Am 10/29/2012 0:28, schrieb Jens Lehmann:
>>>> + /* Remove trailing '/' from directories to find submodules in the index */
>>>> + for (i = 0; i < argc; i++) {
>>>> + size_t pathlen = strlen(argv[i]);
>>>> + if (pathlen && is_directory(argv[i]) && (argv[i][pathlen - 1] == '/'))
>>>> + argv[i] = xmemdupz(argv[i], pathlen - 1);
>>>> + }
>>>> +
>>>> pathspec = get_pathspec(prefix, argv);
>>>> refresh_index(&the_index, REFRESH_QUIET, pathspec, NULL, NULL);
>>>
>>> That's wrong: Either move the check below get_pathspec() (which normalizes
>>> backslashes to forward-slashes on Windows) or use is_dir_sep().
>>
>> Thanks for bringing this up.
And sorry for taking so long to follow up on this, but I'm currently
pretty occupied with real life issues and am rather short on git time.
>>> But isn't it somewhat dangerous to check pathspec for existance in the
>>> worktree without interpreting them? Think of magic pathspec syntax (that
>>> we do not have yet, but which may materialize sometime in the future).
>>
>> I have to admit I'm not aware of magic pathspec syntax. Do you happen to
>> have any pointers where I could look at code doing similar things right?
>
> cmd_mv() in builtin/mv.c looks like a good candidate. It has to check
> whether the destination (the last argument) is a directory.
Thanks, that was a good pointer (and judging from the comment just before
prefix_pathspec() in setup.c I currently can't do /that/ much about the
magic pathspec syntax as it has not materialized yet ;-).
I was thinking about reusing the copy_pathspec() function from mv.c but
came to the conclusion not to do so because it a) doesn't care if a '/'
is following a file (where I believe it should not be dropped but mv
should error out, but it currently doesn't) and b) it also has the
base_name argument I don't need (and which seems to be rather special to
the needs of mv.c). So I coded that loop myself using is_dir_sep()
(taking care that is_directory() will only be called on paths which have
a trailing directory separator).
builtin/rm.c | 15 +++++++++++++++
t/t3600-rm.sh | 17 +++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/builtin/rm.c b/builtin/rm.c
index 2aea3b5..dabfcf6 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -234,6 +234,21 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (read_cache() < 0)
die(_("index file corrupt"));
+ /*
+ * Drop trailing directory separators from directories so we'll find
+ * submodules in the index.
+ */
+ for (i = 0; i < argc; i++) {
+ size_t pathlen = strlen(argv[i]);
+ if (pathlen && is_dir_sep(argv[i][pathlen - 1]) &&
+ is_directory(argv[i])) {
+ do {
+ pathlen--;
+ } while (pathlen && is_dir_sep(argv[i][pathlen - 1]));
+ argv[i] = xmemdupz(argv[i], pathlen);
+ }
+ }
+
pathspec = get_pathspec(prefix, argv);
refresh_index(&the_index, REFRESH_QUIET, pathspec, NULL, NULL);
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 97254e8..06f6384 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -302,6 +302,23 @@ test_expect_success 'rm removes work tree of unmodified submodules' '
test_cmp expect actual
'
+test_expect_success 'rm removes a submodule with a trailing /' '
+ git reset --hard &&
+ git submodule update &&
+ git rm submod/ &&
+ test ! -d submod &&
+ git status -s -uno --ignore-submodules=none > actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'rm fails when given a file with a trailing /' '
+ test_must_fail git rm empty/
+'
+
+test_expect_success 'rm succeeds when given a directory with a trailing /' '
+ git rm -r frotz/
+'
+
test_expect_success 'rm of a populated submodule with different HEAD fails unless forced' '
git reset --hard &&
git submodule update &&
--
1.8.0.91.gf07e555
^ permalink raw reply related
* Re: Requirements for integrating a new git subcommand
From: Eric S. Raymond @ 2012-11-22 22:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJsQjXEhmfRUEgBc=RkF3Lk8QVqUqmeAJiOZ0dtvcMYVFw@mail.gmail.com>
Shawn Pearce <spearce@spearce.org>:
> [Lots of helpful stuff ended by]
> > 4. How does "git help" work? That is, how is a subcommand expected
> > to know when it is being called to export its help text?
>
> IIRC "git help foo" runs "man git-foo".
OK, that makes sense.
> > 5. I don't see any extensions written in Python. Are there any special
> > requirements or exclusions for Python scripts?
>
> Nope, it just has to be executable. We don't have any current Python
> code. IIRC the last Python code was the implementation of
> git-merge-recursive, which was ported to C many years ago. We avoid
> Python because it is not on every platform where Git is installed. Yes
> Python is very portable and can be installed in many places, but we
> prefer not to make it a requirement.
I find that odd. You avoid Python but use shellscripts? *blink*
One would think shellscripts were a much more serious portability problem.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH v5 05/15] Add new simplified git-remote-testgit
From: Felipe Contreras @ 2012-11-21 23:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vboeq3h0t.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 7:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> It's way simpler. It exerceises the same features of remote helpers.
>> It's easy to read and understand. It doesn't depend on python.
>>
>> It does _not_ exercise the python remote helper framework; there's
>> another tool and another test for that.
>
> You mention why you _think_ it is better, and what it is _not_, but
> with your excitement, end up failing to mention what it is. I'll
> try to reword the commit with this sentence:
>
> This script is to test the remote-helper interface.
That's right.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Max Horn @ 2012-11-21 22:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Felipe Contreras, git, Johannes Schindelin,
Jeff King, Sverre Rabbelier, Brandon Casey, Brandon Casey,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <7vfw43pmp7.fsf@alter.siamese.dyndns.org>
On 21.11.2012, at 06:08, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Never mind that others have said that that's not the current interface
>> (I don't yet see why it would be a good interface after a transition,
>> but maybe it would be). Still, hopefully that clarifies the intended
>> meaning.
>
> Care to explain how the current interface is supposed to work, how
> fast-export and transport-helper should interact with remote helpers
> that adhere to the current interface, and how well/correctly the
> current implementation of these pieces work?
Yes, please!
>
> What I am trying to get at is to see where the problem lies. Felipe
> sees bugs in the aggregated whole. Is the root cause of the problems
> he sees some breakages in the current interface? Is the interface
> designed right but the problem is that the implementation of the
> transport-helper is buggy and driving fast-export incorrectly? Or is
> the implementation of the fast-export buggy and emitting wrong results,
> even though the transport-helper is driving fast-export correctly?
> Something else?
>
> I see Felipe keeps repeating that there are bugs, and keeps posting
> patches to change fast-export, but I haven't seen a concrete "No,
> the reason why you see these problems is because you are not using
> the interface correctly; the currrent interface is fine. Here is
> how you can fix your program" from "others".
I was wondering about the same, actually... Moreover, I started to try to understand more about this, but found this a bit difficult. Apparently I am primarily supposed to learn about remote helpers by reverse engineering the (sparsely commented, if at all) existing ones. The fact that remote helpers can implement different subsets of the feature spectrum complicates this further.
Overall, my impression is that there are two kinds of remote helpers:
1) Some are git-to-git helpers, which allow access to another git repos via some intermediate media / protocol (via http, ssh, ...). Those use either connect, or fetch+push. They do not need marks, because they can use the git sha1s. Examples (together with the capabilities they claim to implement):
- remote-curl: fetch, option, push
- remote-ext: connect
- remote-fd: connect
2) Some are interfaces to foreign systems (bzr, hg, mediawiki, ...). They cannot use sha1s and must use marks (at least that is how I understand felipe's explanation). These tools use import combined with either export, or push. Examples:
- git-remote-mediawiki: import, push, refspec
(its capabilities command also prints "list", but that seems to be a bug?)
- git-remote-hg: import, export, refspec, import-marks, export-marks
(both the msysgit one and felipe's
- git-remote-bzr: import, push
(the one from https://github.com/lelutin/git-remote-bzr)
- git-remote-bzr (felipe's): import, export, refspec, *import-marks, *export-marks
(but why the * ?)
Does that sound about right? If so, can somebody give me a hint when a type 2 helper would use "export" and when "push"?
And while I am at it: git-remote-helpers.txt does not mention the "export", "import-marks" and "export-marks" capabilities. Could somebody who knows what they do look into fixing that? Overall, that doc helped me a bit, but it is more a reference to somebody who already understands in detail how remote helpers work, and who just wants to look up some specific detail :-(. Some hints on when to implement which capabilities might be useful (similar to the "Tips and Tricks" section in git-fast-import.txt).
As it is, felipe's recent explanation on why he thinks marks are essential for remote-helpers (I assume he was only referring to type 2 helpers, though) was one of the most enlightening texts I read on the whole subject so far (then again, I am fairly new to this list, so I may have missed lots of past goodness). Anyway, it would be nice if this could be augmented by "somebody from the other camp" ;).
Cheers,
Max
^ permalink raw reply
* [PATCH] makefile: hide stderr of curl-config test
From: Paul Gortmaker @ 2012-11-22 3:19 UTC (permalink / raw)
To: git; +Cc: Paul Gortmaker
Currently, if you don't have curl installed, you will get
$ make distclean 2>&1 | grep curl
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
$
The intent is not to alarm the user, but just to test if there is
a new enough curl installed. However, if you look at search engine
suggested completions, the above "error" messages are confusing
people into thinking curl is a hard requirement.
This test dates back 7+ years to:
---------------------
commit 0890098780f295f2a58658d1f6b6627e40426c72
Author: Nick Hengeveld <nickh@reactrix.com>
Date: Fri Nov 18 17:08:36 2005 -0800
Decide whether to build http-push in the Makefile
---------------------
It wants to ensure curl is newer than 070908. The oldest
machine I could find (RHEL 4.6) is 2007 vintage according
to /proc/version data, and it has curl 070C01.
The failure here is to mask stderr in the test. However, since
the chance of curl being installed, but too old is essentially
nil, lets just check for existence and drop the ancient version
threshold check, if for no other reason, than to simplifly the
parsing of what the makefile is trying to do by humans.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/Makefile b/Makefile
index 9bc5e40..56f55f6 100644
--- a/Makefile
+++ b/Makefile
@@ -1573,8 +1573,8 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PROGRAM_OBJS += http-fetch.o
PROGRAMS += $(REMOTE_CURL_NAMES)
- curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
- ifeq "$(curl_check)" "070908"
+ curl_check := $(shell curl-config --vernum 2>/dev/null)
+ ifneq "$(curl_check)" ""
ifndef NO_EXPAT
PROGRAM_OBJS += http-push.o
endif
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v5 09/15] remote-testgit: exercise more features
From: Felipe Contreras @ 2012-11-21 23:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vhaoi3h0v.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 7:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Unfortunately they do not work.
>
> As far as I can tell, "more features" simply mean one, no? Perhaps
>
> remote-testgit: exercise non-default refspec feature
It's the other way around, a good refspec works, anything else
doesn't. s/non-default/default/ but there's other stuff:
1) *:* refspec
2) no refspec
3) no marks
--
Felipe Contreras
^ permalink raw reply
* Re: gitk: Portuguese "Ignore space change" translation
From: Thiago Farina @ 2012-11-21 23:18 UTC (permalink / raw)
To: Joao Vitor P. Moraes; +Cc: git
In-Reply-To: <CADJyvEdgeC1fHWz9sU6RDUcrfXbkk5qZ6RVBp5iYUcvbnh2BdA@mail.gmail.com>
Hi Joao,
On Tue, Nov 20, 2012 at 8:03 AM, Joao Vitor P. Moraes <jvlppm@gmail.com> wrote:
> Inside gitk there's a checkbox which says:
> Ignore space change
>
> It was translated to portuguese (pt-br) as:
> Ignorar mudanças de caixa
>
> But that message in portuguese means:
> Ignore case changes
>
> that checkbox does not ignore case changes, but instead it ignores space
> changes, a better translation would be
>
> Ignorar mudanças de espaço
> or
As a native speaker I'd say go with that one. Although 'Ignorar
espaçamentos' sounds more succinct.
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-22 0:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vmwya3h0x.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 7:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> They have been marked as UNINTERESTING for a reason, lets respect that.
>> ...
>> The current behavior is most certainly not what we want. After this
>> patch, nothing gets exported, because nothing was selected (everything
>> is UNINTERESTING).
>
> The old behaviour was an incorrect "workaround" that has been
> superseded by your 14/15 "make sure updated refs get updated", no?
> Mentioning that would help people realize that this patch would not
> cause regression on them, I would think.
This particular patch is not getting rid of that "workaround", if you
can call it that, it's just making it work correctly.
There's absolutely no possibility of regression (that is known or
anybody has mentioned).
The only argument that was put forward was that 'git fast-export
^master master' should throw:
from :0
As it does now, because in the future, with another patch (that nobody
is pursuing), it might do:
from 8c7a786
Which as I have tried to explain; is equally useless.
There's no regression, nobody would be affected negatively by this
because when there are no marks, nobody expects a 'from :0'; it's
totally useless, and when there are marks, nobody expects an update
when the user does '^uninteresting master' for the 'uninteresting'
ref. And not even potential future users would be affected, because
'from 8c7a786' is not helpful either, even if the user wanted
'^uninsteresting' to be updated (which they won't), the git SHA-1 is
useless to a remote helper without marks.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* git bash does not access drive f:
From: Angelo Borsotti @ 2012-11-22 7:07 UTC (permalink / raw)
To: git
Hi
I have attached an external disc, which appears on Windows as drive f:
in Windows Explorer.
Right-clicking on it displays a context menu showing (among other
items) Git Init Here, Git Gui and
Git Bash. The first two work properly on that drive.
However, the git bash does not. Not even the one that is run from the icon:
$ cd f:
sh.exe": cd: f:: No such file or directory
Is there any way to make it access drive f?
-Angelo Borsotti
^ permalink raw reply
* Re: [PATCH v5 00/15] fast-export and remote-testgit improvements
From: Felipe Contreras @ 2012-11-22 0:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vtxsi22g6.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 8:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I can agree that the updates to fast-export will make remote-testgit
> script work better, but I cannot tell how big an impact the changes
> will have to people's existing use of fast-export. Some of them may
> be relying on the current behaviour (in other words, they may be
> relying on "existing bugs"), which may mean that this series will
> bring regression to them. I am still open to reasonable objections
> along the lines of "This script X uses fast-export and is broken
> when used with the updated behaviour." if there is any.
We've discussed about this extensively, and I've asked the same;
nobody put forward any. I've also thought long and hard; can't think
of any.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Remote hung up during `git fetch`
From: Yichao Yu @ 2012-11-22 20:09 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJs5PwLxwtBoYb+ZLmY=ts9U=UhDPmKXW7KY2BFNpBJfDQ@mail.gmail.com>
On Thu, Nov 22, 2012 at 2:52 PM, Shawn Pearce <spearce@spearce.org> wrote:
> On Thu, Nov 22, 2012 at 11:44 AM, Yichao Yu <yyc1992@gmail.com> wrote:
>>> US holiday today? The list traffic tends to be down during holidays.
>> This silent?.... 0 email from the kernel mailing list for 10+ hours?..
>> anyway.... nvm...
>
> Check your spam filters? I am having no trouble getting email for the
> Git list. Traffic is down, but there have been several messages within
> the past 4 hours. E.g. this thread among them.
My spam filter is fine (they are not in spam...)... probably gmail
just failed to send to / receive from vger.kernel.org for the last
several hours (or sth similar...)....
>
>> packet: fetch> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64
>> multi_ack_detailed side-band-64k thin-pack ofs-delta
>> packet: fetch> shallow 65546ab097b023886a60df4cbc931d4cc362b98e
>> packet: fetch> shallow b80d60e1c3854460a1f01d4110da5ae98f30f9b2
>> packet: fetch> 0000
>
> I think this is the problem. Your client told the sever it has the
> Linux kernel shallow cloned, but its talking to a repository that
> hosts git.git. The remote server doesn't know these two SHA-1s
> mentioned on the shallow line, as they are from the Linux kernel
> repository, so the server just hung up on you.
I C. So in my real case it is probably because the different server I
am pulling from are on different branches.... (for a shallow clone, it
may look the same with commits from different projects?...)
>
> Basically this is an unsupported use case. A shallow repository can
> only fetch from the place it cloned from. Anything else working is
> pure luck. It _may_ be able to fetch from a clone of that same
> repository at another server, if the clone has at least all of the
> commits the client already has. If the remote clone is missing commits
> (as in this case where it has none!) then it doesn't work.
So is there a way to ask for a certain commit from a certain server
and update local files that has changed accordingly? For the server,
it shouldn't be much different from another shallow clone (although it
would be better if locally existing objects are not transferred.). But
I am wondering what client side command/script do I need to use.
THX.
^ permalink raw reply
* [PATCH] Completion script must sort before using uniq
From: Marc Khouzam @ 2012-11-22 20:02 UTC (permalink / raw)
To: git, SZEDER Gábor, Felipe Contreras
The uniq program only works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs use the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
For example if all available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the choices given are
maint
master
but when performing completion on 'git checkout mai', no choices
appear, which is obviously contradictory.
The reason is that, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same.
But when dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u'.
The solution is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
Sorry if you get this twice, my first try never showed up on the list.
I ran into this by fluke when testing the tcsh completion.
Thanks for considering the fix.
Marc
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc0657a..85ae419 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,7 +321,7 @@ __git_refs ()
if [[ "$ref" == "$cur"* ]]; then
echo "$ref"
fi
- done | uniq -u
+ done | sort | uniq -u
fi
return
fi
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: [PATCH] Fix bash completion when `egrep` is aliased to `egrep --color=always`
From: Marc Khouzam @ 2012-11-22 19:55 UTC (permalink / raw)
To: Adam Tkac; +Cc: git
In-Reply-To: <20121122154120.GA16835@redhat.com>
On Thu, Nov 22, 2012 at 10:41 AM, Adam Tkac <atkac@redhat.com> wrote:
> Hello all,
>
> attached patch fixes bash completion when `egrep` is aliased to `egrep --color=always`.
To avoid any aliases, it may be better to use
\egrep
This could be worthwhile for all utilities used by the script.
Just a thought.
Marc
>
> Comments are welcomed.
>
> Regards, Adam
>
> --
> Adam Tkac, Red Hat, Inc.
^ permalink raw reply
* Re: Remote hung up during `git fetch`
From: Shawn Pearce @ 2012-11-22 19:52 UTC (permalink / raw)
To: Yichao Yu; +Cc: git
In-Reply-To: <CAMvDr+Rv6Krmjto6nQL18GnEj-+qCFPYgp7jDQnLs-ybamM0FA@mail.gmail.com>
On Thu, Nov 22, 2012 at 11:44 AM, Yichao Yu <yyc1992@gmail.com> wrote:
>> US holiday today? The list traffic tends to be down during holidays.
> This silent?.... 0 email from the kernel mailing list for 10+ hours?..
> anyway.... nvm...
Check your spam filters? I am having no trouble getting email for the
Git list. Traffic is down, but there have been several messages within
the past 4 hours. E.g. this thread among them.
> packet: fetch> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64
> multi_ack_detailed side-band-64k thin-pack ofs-delta
> packet: fetch> shallow 65546ab097b023886a60df4cbc931d4cc362b98e
> packet: fetch> shallow b80d60e1c3854460a1f01d4110da5ae98f30f9b2
> packet: fetch> 0000
I think this is the problem. Your client told the sever it has the
Linux kernel shallow cloned, but its talking to a repository that
hosts git.git. The remote server doesn't know these two SHA-1s
mentioned on the shallow line, as they are from the Linux kernel
repository, so the server just hung up on you.
Basically this is an unsupported use case. A shallow repository can
only fetch from the place it cloned from. Anything else working is
pure luck. It _may_ be able to fetch from a clone of that same
repository at another server, if the clone has at least all of the
commits the client already has. If the remote clone is missing commits
(as in this case where it has none!) then it doesn't work.
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-22 0:28 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Jonathan Nieder, git, Johannes Schindelin,
Max Horn, Sverre Rabbelier, Brandon Casey, Brandon Casey,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <20121121194810.GE16280@sigill.intra.peff.net>
On Wed, Nov 21, 2012 at 8:48 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 20, 2012 at 09:08:36PM -0800, Junio C Hamano wrote:
>
>> With such a one-sided discussion, I've been having a hard time
>> convincing myself if Felipe's effort is making the interface better,
>> or just breaking it even more for existing remote helpers, only to
>> fit his world model better.
>
> Felipe responded in more detail, but I will just add the consensus we
> came to earlier in the discussion: the series does make things better
> for users of fast-export that use marks, but does not make things any
> better for users of negative refs on the command line. However, I do not
> think that it makes things worse for them, either (neither by changing
> the behavior negatively, nor by making the code harder for a more
> complete fix later).
Patch 14 changes the behavior depending on the marks, patch 15 doesn't.
This patch is mostly orthogonal to marks.
Before without marks:
% git branch unintresting master
% git fast-export master ^uninteresting
reset refs/heads/uninteresting
from :0
Before with marks:
% git fast-export --import-marks=marks master ^uninteresting
reset refs/heads/uninteresting
from :100
See? In both cases git is doing something the user doesn't want, nor
specified. After my patch nothing gets updated, because nothing was
specified to be updated.
I'm not going to bother explaining why other people objected to this
patch (again), which is indeed related to marks, they should do it for
themselves. Let me reaffirm that no valid reason has put forward to
object to this patch.
> So while fixing everybody might be nice
I would like to understand that that even means. What behavior is
currently broken? And for who? And how is this patch related to that?
> [1] There are other possible use cases for fast-export which might
> benefit from negative refs working more sanely, but since they are
> in the minority and are not being made worse, I think the partial
> fix is OK.
Which ones? I don't think this is a partial fix.
Nobody has put forward such a use-case.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Completion must sort before using uniq
From: Marc Khouzam @ 2012-11-22 4:16 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor, Felipe Contreras
In-Reply-To: <1353557598-4820-1-git-send-email-marc.khouzam@gmail.com>
The uniq program only works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs use the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
For example if all available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the choices given are
maint
master
but when performing completion on 'git checkout mai', no choices
appear, which is obviously contradictory.
The reason is that, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same.
But when dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u'.
The solution is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
I ran into this by fluke when testing the tcsh completion.
Thanks for considering the fix.
Marc
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc0657a..85ae419 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,7 +321,7 @@ __git_refs ()
if [[ "$ref" == "$cur"* ]]; then
echo "$ref"
fi
- done | uniq -u
+ done | sort | uniq -u
fi
return
fi
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: Remote hung up during `git fetch`
From: Yichao Yu @ 2012-11-22 19:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJveYb09uhZWsKWKYor5Jcuz+wZ40F3wnsR3Hy8bcxeb6g@mail.gmail.com>
On Thu, Nov 22, 2012 at 2:01 PM, Shawn Pearce <spearce@spearce.org> wrote:
> On Thu, Nov 22, 2012 at 10:39 AM, Yichao Yu <yyc1992@gmail.com> wrote:
>> I sent this email yesterday to the git mailing list but I cannot find
>> it in any archive so I decide to send it again.
>
> If it was HTML formatted it would have been silently dropped by the list.
Well, I simply forward the original email and both of them are plain
text I believe....
>
>> Does anyone know what has happened to the mailing list? I haven't
>> receive any email from several kernel related busy mailing lists for
>> several hours....
>
> US holiday today? The list traffic tends to be down during holidays.
This silent?.... 0 email from the kernel mailing list for 10+ hours?..
anyway.... nvm...
>
>> I want to build packages for snap shoot of different branches from
>> different remote git repositories in the same local directory (so that
>> I don't need to recompile everything everytime.) and I am using a
>> combination of `git clone/checkout/reset/fetch` to do that. However,
>> during git-fetch, the remote sometimes stop responding or simply reset
>> the connection. This happens occasionally at least for both ssh and
>> git protocol (not sure about http/https) on github, bitbucket and also
>> kernel.org so I think it is probably not due to a weird behavior of a
>> certain host. Does anyone know the reason or is there anything I have
>> done wrong? And is there a better way to set the local tree to a
>> certain branch at a certain url? THX
>
> If the remote server is really busy it might be OOM'ing the server
Well, clone succeeded but fetch didn't?...
> process which would disconnect the client. Or maybe its your ISP
> sending a rogue RST packet to kill the connection because they don't
> like traffic that leaves their network and costs them money on a
> peering agreement. Or... ?
Well, yes I have only tested here but I don't really think MIT is
doing that... No?
>
>> #!/bin/bash
>>
>> repo_name=git
>> # remote1='git://github.com/torvalds/linux.git'
>> remote1='git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'
>> branch1='master'
>> # remote2='git://github.com/git/git.git'
>> remote2='git://git.kernel.org/pub/scm/git/git.git'
>> branch2='next'
>>
>> git clone --depth 1 --single-branch --branch "$branch1" "$remote1" "$repo_name"
>> cd "$repo_name"
>> git fetch -vvv "$remote2" # "$branch2:$branch2"
>>
>> -----------------------------------------------
>>
>> Cloning into 'git'...
>> remote: Counting objects: 43215, done.
>> remote: Compressing objects: 100% (41422/41422), done.
>> remote: Total 43215 (delta 3079), reused 22032 (delta 1247)
>> Receiving objects: 100% (43215/43215), 119.06 MiB | 1.60 MiB/s, done.
>> Resolving deltas: 100% (3079/3079), done.
>> Checking out files: 100% (40905/40905), done.
>> fatal: destination path 'git' already exists and is not an empty directory.
>
> Why does this error come up? It looks like git already exists locally.
> Git should have aborted much earlier in clone when the directory
> exists.
Ahh, sorry. I killed the previous script to use LANG=C but forgot to
remove the directory which is normally deleted automatically by the
last few lines of my script that I didn't paste here (cd and rm...).
So here is the right output.
---------------------------------------
Cloning into 'git'...
remote: Counting objects: 43215, done.
remote: Compressing objects: 100% (41071/41071), done.
remote: Total 43215 (delta 3699), reused 13345 (delta 1598)
Receiving objects: 100% (43215/43215), 116.91 MiB | 4.51 MiB/s, done.
Resolving deltas: 100% (3699/3699), done.
Checking out files: 100% (40905/40905), done.
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386
have db9d8c60266a5010e905829e10cd722519e14777
done
fatal: read error: Connection reset by peer
----------------------------------------------------
>
>> Server supports multi_ack_detailed
>> Server supports side-band-64k
>> Server supports ofs-delta
>> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
>> have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386
>> have db9d8c60266a5010e905829e10cd722519e14777
>> done
>> fatal: The remote end hung up unexpectedly
>
> This looks like its from the fetch command. Since the server doesn't
yes, plz simply ignore the previous one....
> report any errors to the client, its hard to say why the server just
> gave up right there. I wonder if this is related to the fact that you
> did a shallow clone initially. The shallow clone may have confused the
> server when fetch ran because it only sent 2 have lines and gave up.
Probably (related to shallow clone...) but hopefully this is not sth I
shouldn't do?
And a shallow clone is really what I want in my case. I really don't
need the full history to compile...
>
> Try exporting GIT_TRACE_PACKET=1 and seeing if you can get more
> detailed information from the protocol on the client side.
So here it is, I have removed lots of tags fetching (hopefully they
are irrelevant). Is there anything that looks strange (Looks like it's
actually .... done???)? Any more information needed?
----------------------------------------------
Cloning into 'git'...
remote: Counting objects: 43385, done.
remote: Compressing objects: 100% (41117/41117), done.
Receiving objects: 100% (43385/43385), 117.05 MiB | 4.73 MiB/s, done.
remote: Total 43385 (delta 3862), reused 13596 (delta 1722)
Resolving deltas: 100% (3862/3862), done.
Checking out files: 100% (40905/40905), done.
packet: fetch> git-upload-pack
/pub/scm/git/git.git\0host=git.kernel.org\0
packet: fetch< 2d242fb3fc19fc9ba046accdd9210be8b9913f64
HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow
no-progress include-tag multi_ack_detailed
packet: fetch< 1c03999bef32edabd3db6479279b3ef90cc635ca refs/heads/maint
packet: fetch< 2d242fb3fc19fc9ba046accdd9210be8b9913f64 refs/heads/master
packet: fetch< ce6fbe5b9dc5e1e8ce1499bd8f7fb982e0c68289 refs/heads/next
packet: fetch< 7b4a70c62f3a83fbd8b44bf712141754a5f64205 refs/heads/pu
packet: fetch< 2c806864e99fc1252cea652ab0fc837067e726ba refs/heads/todo
packet: fetch< d5aef6e4d58cfe1549adef5b436f3ace984e8c86
refs/tags/gitgui-0.10.0
packet: fetch< 3d654be48f65545c4d3e35f5d3bbed5489820930
refs/tags/gitgui-0.10.0^{}
packet: fetch< 33682a5e98adfd8ba4ce0e21363c443bd273eb77
refs/tags/gitgui-0.10.1
packet: fetch< 729ffa50f75a025935623bfc58d0932c65f7de2f
refs/tags/gitgui-0.10.1^{}
... tags... and tags... and tags.....
packet: fetch< c15295d7477ccec489953299bd03a8e62f86e611
refs/tags/v1.8.0-rc2
packet: fetch< cd46259ebf2e624bcee2aaae05c36663d414e1a2
refs/tags/v1.8.0-rc2^{}
packet: fetch< 22ed067acc84eac8a0a72d20478a18aee4e25571
refs/tags/v1.8.0-rc3
packet: fetch< 87a5461fa7b30f7b7baf27204f10219d61500fbf
refs/tags/v1.8.0-rc3^{}
packet: fetch< 0000
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
packet: fetch> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64
multi_ack_detailed side-band-64k thin-pack ofs-delta
packet: fetch> shallow 65546ab097b023886a60df4cbc931d4cc362b98e
packet: fetch> shallow b80d60e1c3854460a1f01d4110da5ae98f30f9b2
packet: fetch> 0000
packet: fetch> have 5a903166dd31a42e39283b075cc6b9a9c079d1af
have 5a903166dd31a42e39283b075cc6b9a9c079d1af
packet: fetch> have b80d60e1c3854460a1f01d4110da5ae98f30f9b2
have b80d60e1c3854460a1f01d4110da5ae98f30f9b2
packet: fetch> have 65546ab097b023886a60df4cbc931d4cc362b98e
have 65546ab097b023886a60df4cbc931d4cc362b98e
packet: fetch> done
done
fatal: read error: Connection reset by peer
----------------------------------------------------------
>
> FYI, https://kernel.googlesource.com/ mirrors git://git.kernel.org/ so
> you can also try pulling from that server (e.g.
> https://kernel.googlesource.com/pub/scm/git/git.git).
THX. I have no problem cloning/pulling either the git or the kernel
tree from anywhere. It only happens when I want to do this kind of
fetching. I think git.kernel.org should be the best place to
demonstrate this kind of error since you may know exactly what is
running on the server. (And you probably don't want to try reproducing
sth on my private ssh git server?.) =P
^ permalink raw reply
* Re: git-fetch does not work from .git subdirectory
From: Patrik Gornicz @ 2012-11-22 0:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <50AC0316.7090002@freescale.com>
Just a hunch but your remote's location uses a relative path
'../linux-2.6.git', perhaps git is messing up what the path is relative
to.
I assume this repo is beside the linux.cq-test repo? ie. perhaps
they're located at /home/user/git/linux.cq-test and
/home/user/git/linux-2.6.git.
Then, for example, from linux.cq-test it looks for
/home/user/git/linux-2.6.git but from linux.cq-test/.git it looks for
/home/user/git/linux.cq-test/linux-2.6.git, which is wrong.
Note sure what the fix will be though as it'll likely break existing
repositories that use relative paths either way. Can you try an
absolute path to see if that fixes thing?
Patrik
On Tue Nov 20 17:24:22 2012, Timur Tabi wrote:
> I was under the impression that git commands which affect repository (as
> opposed to the local file system) work from any subdirectory inside the
> repository. For example:
>
> [b04825@efes linux.cq-test]$ git log -1
> commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
> Author: Timur Tabi <timur@freescale.com>
> Date: Wed Oct 31 15:56:20 2012 +0200
> ...
> [b04825@efes linux.cq-test]$ cd .git
> [b04825@efes .git]$ git log -1
> commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
> Author: Timur Tabi <timur@freescale.com>
> Date: Wed Oct 31 15:56:20 2012 +0200
> ...
>
> It appears, however, that git-fetch does not work this way:
>
> [b04825@efes linux.cq-test]$ git fetch upstream master
> From ../linux-2.6
> * branch master -> FETCH_HEAD
> [b04825@efes linux.cq-test]$ cd .git
> [b04825@efes .git]$ git fetch upstream master
> fatal: '../linux-2.6.git' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
>
> This makes it complicated because git hooks run from the .git directory on
> normal repositories, but they run from the top-level directory on bare
> repositories. Apparently, you need to be in the top-level directory for
> git-fetch to run in any kind of repository.
>
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-22 0:38 UTC (permalink / raw)
To: Max Horn
Cc: Junio C Hamano, Jonathan Nieder, git, Johannes Schindelin,
Jeff King, Sverre Rabbelier, Brandon Casey, Brandon Casey,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <0F47AA24-F5B6-4197-8D74-6DD32E253856@quendi.de>
On Wed, Nov 21, 2012 at 11:30 PM, Max Horn <max@quendi.de> wrote:
> 2) Some are interfaces to foreign systems (bzr, hg, mediawiki, ...). They cannot use sha1s and must use marks (at least that is how I understand felipe's explanation). These tools use import combined with either export, or push. Examples:
>
> - git-remote-mediawiki: import, push, refspec
> (its capabilities command also prints "list", but that seems to be a bug?)
I don't think remote mediawiki uses marks. They are strictly not
needed by 'import' because the remote helper has full control over
this operation. For example, in my remote helpers, I store the
previous tip of the branches, so when git ask for 'import
refs/heads/master', I only import the new commits. I named this file
'marks' anyway, but they are not marks for fast-import.
> - git-remote-hg: import, export, refspec, import-marks, export-marks
> (both the msysgit one and felipe's
> - git-remote-bzr: import, push
> (the one from https://github.com/lelutin/git-remote-bzr)
> - git-remote-bzr (felipe's): import, export, refspec, *import-marks, *export-marks
> (but why the * ?)
AFAIK both of my remote helpers have * in them, they are to denote
they are required.
> Does that sound about right? If so, can somebody give me a hint when a type 2 helper would use "export" and when "push"?
I don't know when would be appropriate to use push, there's another
git-remote-bzr that uses the bzr-git infrastructure, and uses push.
I picked export/import because I think they are the easiest to
implement to get all the features, and should be efficient.
> And while I am at it: git-remote-helpers.txt does not mention the "export", "import-marks" and "export-marks" capabilities. Could somebody who knows what they do look into fixing that? Overall, that doc helped me a bit, but it is more a reference to somebody who already understands in detail how remote helpers work, and who just wants to look up some specific detail :-(. Some hints on when to implement which capabilities might be useful (similar to the "Tips and Tricks" section in git-fast-import.txt).
I've had problems finding out the right information, but I hope the
git-remote-testgit I wrote in bash in less than 90 lines of code
should give a pretty good idea of how the whole thing works.
> As it is, felipe's recent explanation on why he thinks marks are essential for remote-helpers (I assume he was only referring to type 2 helpers, though) was one of the most enlightening texts I read on the whole subject so far (then again, I am fairly new to this list, so I may have missed lots of past goodness). Anyway, it would be nice if this could be augmented by "somebody from the other camp" ;).
Wouldn't that be nice?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH v2 2/4] format-patch: stricter S-o-b detection
From: Nguyễn Thái Ngọc Duy @ 2012-11-22 16:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1353602289-9418-1-git-send-email-pclouds@gmail.com>
S-o-b in the middle of a sentence, at the beginning of the sentence
but it is just because of text wrapping, or a full paragraph of valid
S-o-b in the middle of the message. All these are not S-o-b, but
detected as is. Fix them.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
log-tree.c | 37 +++++++++++++++++++++++++++++++--
t/t4014-format-patch.sh | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index c894930..aff7c0a 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -260,14 +260,47 @@ static void append_signoff(struct strbuf *sb, const char *signoff)
int has_signoff = 0;
char *cp;
- cp = sb->buf;
+ /*
+ * Only search in the last paragrah, don't be fooled by a
+ * paragraph full of valid S-o-b in the middle.
+ */
+ cp = sb->buf + sb->len - 1;
+ while (cp > sb->buf) {
+ if (cp[0] == '\n' && cp[1] == '\n') {
+ cp += 2;
+ break;
+ }
+ cp--;
+ }
/* First see if we already have the sign-off by the signer */
while ((cp = strstr(cp, signed_off_by))) {
+ const char *s = cp;
+ cp += strlen(signed_off_by);
+
+ if (!has_signoff && s > sb->buf) {
+ /*
+ * S-o-b in the middle of a sentence is not
+ * really S-o-b
+ */
+ if (s[-1] != '\n')
+ continue;
+
+ if (s - 1 > sb->buf && s[-2] == '\n')
+ ; /* the first S-o-b */
+ else if (!detect_any_signoff(sb->buf, s - sb->buf))
+ /*
+ * The previous line looks like an
+ * S-o-b. There's still no guarantee
+ * that it's an actual S-o-b. For that
+ * we need to look back until we find
+ * a blank line, which is too costly.
+ */
+ continue;
+ }
has_signoff = 1;
- cp += strlen(signed_off_by);
if (cp + signoff_len >= sb->buf + sb->len)
break;
if (strncmp(cp, signoff, signoff_len))
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index c8d5d29..d0b3c85 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -989,6 +989,60 @@ EOF
test_cmp expected actual
'
+test_expect_success 'signoff: not really a signoff' '
+ append_signoff <<\EOF >actual &&
+subject
+
+I want to mention about Signed-off-by: here.
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+9:I want to mention about Signed-off-by: here.
+10:
+11:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: not really a signoff (2)' '
+ append_signoff <<\EOF >actual &&
+subject
+
+My unfortunate
+Signed-off-by: example happens to be wrapped here.
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+10:Signed-off-by: example happens to be wrapped here.
+11:
+12:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: valid S-o-b paragraph in the middle' '
+ append_signoff <<\EOF >actual &&
+subject
+
+Signed-off-by: my@house
+Signed-off-by: your@house
+
+A lot of houses.
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: my@house
+10:Signed-off-by: your@house
+11:
+13:
+14:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
test_expect_success 'signoff: the same signoff at the end' '
append_signoff <<\EOF >actual &&
subject
--
1.8.0.4.g5d0415a
^ permalink raw reply related
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