* Re: Is anyone working on a next-gen Git protocol?
From: Junio C Hamano @ 2012-10-22 4:59 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jeff King, spearce, Ævar Arnfjörð
In-Reply-To: <7va9vxq5gp.fsf@alter.siamese.dyndns.org>
On Sun, Oct 7, 2012 at 3:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I and Shawn helped privately somebody from Gerrit circle, where the
> initial ref advertisement is a huge problem (primarily because they
> add tons of refs to one commit that eventually goes to their
> integration branch), to coming up with a problem description and
> proposal document to kick-start a discussion some time ago, but not
> much has happened since. Unless I hear from them soonish, I'll send
> a cleaned-up version of the draft before I leave for my vacation.
Which I forgot and never happened. Here is a link (not cleaned-up)
http://tinyurl.com/WhoSpeaksFirstInGit
^ permalink raw reply
* Re: [PATCH] transport-helper: check when helpers fail
From: Johannes Sixt @ 2012-10-22 6:35 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <1350847158-14154-1-git-send-email-felipe.contreras@gmail.com>
Am 10/21/2012 21:19, schrieb Felipe Contreras:
> diff --git a/run-command.c b/run-command.c
> index 1101ef7..2852e9d 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -559,6 +559,23 @@ int run_command(struct child_process *cmd)
> return finish_command(cmd);
> }
>
> +int check_command(struct child_process *cmd)
> +{
> + int status;
> + pid_t pid;
> +
> + pid = waitpid(cmd->pid, &status, WNOHANG);
> +
> + if (pid < 0)
> + return -1;
> + if (WIFSIGNALED(status))
> + return WTERMSIG(status);
> + if (WIFEXITED(status))
> + return WEXITSTATUS(status);
> +
> + return 0;
> +}
> +
In this form, the function is not suitable as a public run-command API: If
the child did exit, it does not allow finish_command() to do its thing.
The only thing the caller of this function can do is to die() if it
returns non-zero. It doesn't report treat error cases in the same way as
wait_or_whine().
I would expect the function to be usable in this way:
start_command(&proc);
loop {
if (check_command(&proc))
break;
}
finish_command(&proc);
but it would require a bit more work because it would have to cache the
exit status in struct child_process.
BTW, you should check for return value 0 from waitpid() explicitly.
Another thought: In your use-case, isn't it so that it would be an error
that the process exited for whatever reason? I.e., even if it exited with
code 0 ("success"), it would be an error because it violated the protocol?
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
From: Michael Haggerty @ 2012-10-22 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jiang Xin, Lea Wiemann, David Reiss, Johannes Sixt, git
In-Reply-To: <7v7gqkgvxe.fsf@alter.siamese.dyndns.org>
On 10/21/2012 08:51 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> This patch series has the side effect that all of the directories
>> listed in GIT_CEILING_DIRECTORIES are accessed *unconditionally* to
>> resolve any symlinks that are present in their paths. It is
>> admittedly odd that a feature intended to avoid accessing expensive
>> directories would now *intentionally* access directories near the
>> expensive ones. In the above scenario this shouldn't be a problem,
>> because /home would be the directory listed in
>> GIT_CEILING_DIRECTORIES, and accessing /home itself shouldn't be
>> expensive.
>
> Interesting observation. In the last sentence, "accessing /home"
> does not exactly mean accessing /home, but accessing / to learn
> about "home" in it, no?
This is the extra overhead on my system for using
GIT_CEILING_DIRECTORIES=/home:
stat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getcwd("/home/mhagger", 1024) = 14
chdir("/home") = 0
getcwd("/home", 4096) = 6
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
chdir("/home/mhagger") = 0
If I use GIT_CEILING_DIRECTORIES=/dev/shm, which is a symlink to
/run/shm on my system, the overhead is comparable:
stat("/dev/shm", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=200, ...}) = 0
getcwd("/home/mhagger", 1024) = 14
chdir("/dev/shm") = 0
getcwd("/run/shm", 4096) = 9
lstat("/run/shm", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=200, ...}) = 0
chdir("/home/mhagger") = 0
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-22 11:50 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <5084E931.3010809@viscovery.net>
On Mon, Oct 22, 2012 at 8:35 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 10/21/2012 21:19, schrieb Felipe Contreras:
> I would expect the function to be usable in this way:
>
> start_command(&proc);
>
> loop {
> if (check_command(&proc))
> break;
> }
>
> finish_command(&proc);
>
> but it would require a bit more work because it would have to cache the
> exit status in struct child_process.
Yes, I would expect that as well. I just noticed transport-helper also
fails with that, but some reason that's not enough to actually fail
the tests, so something weird is going on.
> BTW, you should check for return value 0 from waitpid() explicitly.
Right.
> Another thought: In your use-case, isn't it so that it would be an error
> that the process exited for whatever reason? I.e., even if it exited with
> code 0 ("success"), it would be an error because it violated the protocol?
How is that violating the protocol?
--
Felipe Contreras
^ permalink raw reply
* diff support for the Eiffel language?
From: Ulrich Windl @ 2012-10-22 11:58 UTC (permalink / raw)
To: git
Hi!
After a longer pause, I did some programming in Eiffel again, and while doing so, why not use Git? It works!
However there's one little thing I noticed with "git diff":
The conte4xt lines (staring with "@@") show the current function (in Perl and C), but they show the current "feature clause" in Eiffel (as opposed to the expected current feature). I wonder how hard it is to fix it (Observed in git 1.7.7 of openSUSE 12.1).
For the non-Eiffelists:
Eiffel has a class structure like this:
class FOO
feature {BAR} -- This is a "feature clause", grouping related features (attributes/routines)
baz (x,y : INTEGER) : STRING is
-- blabla...
do
...
end -- baz
end -- class FOO
---
Now if I change something inside "baz", it would be nice if the @@-contect line would show "baz" (or more) instead of "feature {BAR}...".
Regards,
Ulrich
P.S. Apologies if the feature requested had been added already.
^ permalink raw reply
* [PATCH] git-send-email: use compose-encoding for Subject
From: Krzysztof Mazur @ 2012-10-22 12:41 UTC (permalink / raw)
To: gitster, git; +Cc: Krzysztof Mazur
The commit "git-send-email: introduce compose-encoding" introduced
the compose-encoding option to specify the introduction email encoding
(--compose option), but the email Subject encoding was still hardcoded
to UTF-8.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
Patch against km/send-email-compose-encoding
(commit 62e0069056ed11294c29bae25df69b6518f6339e). Cleanly applies to current
next (commit 291341ca77d902dc76e204a3fc498a155f0ab75d)
git-send-email.perl | 8 ++++----
t/t9001-send-email.sh | 14 ++++++++++++++
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 107e814..adcb4e3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -636,15 +636,15 @@ EOT
my $need_8bit_cte = file_has_nonascii($compose_filename);
my $in_body = 0;
my $summary_empty = 1;
+ if (!defined $compose_encoding) {
+ $compose_encoding = "UTF-8";
+ }
while(<$c>) {
next if m/^GIT:/;
if ($in_body) {
$summary_empty = 0 unless (/^\n$/);
} elsif (/^\n$/) {
$in_body = 1;
- if (!defined $compose_encoding) {
- $compose_encoding = "UTF-8";
- }
if ($need_8bit_cte) {
print $c2 "MIME-Version: 1.0\n",
"Content-Type: text/plain; ",
@@ -658,7 +658,7 @@ EOT
my $subject = $initial_subject;
$_ = "Subject: " .
($subject =~ /[^[:ascii:]]/ ?
- quote_rfc2047($subject) :
+ quote_rfc2047($subject, $compose_encoding) :
$subject) .
"\n";
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 265ae04..89fceda 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -909,6 +909,20 @@ test_expect_success $PREREQ '--compose-encoding overrides sendemail.composeencod
grep "^Content-Type: text/plain; charset=iso-8859-2" msgtxt1
'
+test_expect_success $PREREQ '--compose-encoding adds correct MIME for subject' '
+ clean_fake_sendmail &&
+ GIT_EDITOR="\"$(pwd)/fake-editor\"" \
+ git send-email \
+ --compose-encoding iso-8859-2 \
+ --compose --subject utf8-sübjëct \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $patches &&
+ grep "^fake edit" msgtxt1 &&
+ grep "^Subject: =?iso-8859-2?q?utf8-s=C3=BCbj=C3=ABct?=" msgtxt1
+'
+
test_expect_success $PREREQ 'detects ambiguous reference/file conflict' '
echo master > master &&
git add master &&
--
1.8.0.2.g35080e9
^ permalink raw reply related
* Re: diff support for the Eiffel language?
From: Ævar Arnfjörð Bjarmason @ 2012-10-22 13:06 UTC (permalink / raw)
To: Ulrich Windl; +Cc: git
In-Reply-To: <508550E8020000A10000CF36@gwsmtp1.uni-regensburg.de>
On Mon, Oct 22, 2012 at 1:58 PM, Ulrich Windl
<Ulrich.Windl@rz.uni-regensburg.de> wrote:
> However there's one little thing I noticed with "git diff":
> The conte4xt lines (staring with "@@") show the current function (in Perl and C), but they show the current "feature clause" in Eiffel (as opposed to the expected current feature). I wonder how hard it is to fix it (Observed in git 1.7.7 of openSUSE 12.1).
See git.git's e90d065 for an example of adding a new diff pattern.
You could easily come up with a patch and send it to the list, however
it would probably be good to CC some Eiffel language list in case
there's some syntax oddities you've missed.
^ permalink raw reply
* Re: [PATCH] grep: remove tautological check
From: Peter Krefting @ 2012-10-22 13:20 UTC (permalink / raw)
To: David Soria Parra; +Cc: Git Mailing List
In-Reply-To: <1350753964-29346-1-git-send-email-dsp@php.net>
David Soria Parra:
> - if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
> + if (GREP_HEADER_FIELD_MAX <= p->field)
A friend taught me this trick, which will check that it isn't negative
for compilers that have the enumeration be signed (notably MSVC),
while not complaining for compilers that have it unsigned (GCC, Clang):
const unsigned int sign = 1u << (sizeof(p->field) * CHAR_BIT - 1);
if (!(sign & (unsigned int) p->field) || GREP_HEADER_FIELD_MAX <= p->field)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: diff support for the Eiffel language?
From: Johannes Sixt @ 2012-10-22 13:35 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Ulrich Windl, git
In-Reply-To: <CACBZZX4wF8C_9ok+zeTfO70BgZXufvQaJ+8B5EiOAmxvVwr54g@mail.gmail.com>
Am 10/22/2012 15:06, schrieb Ævar Arnfjörð Bjarmason:
> On Mon, Oct 22, 2012 at 1:58 PM, Ulrich Windl
> <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>> However there's one little thing I noticed with "git diff": The
>> conte4xt lines (staring with "@@") show the current function (in Perl
>> and C), but they show the current "feature clause" in Eiffel (as
>> opposed to the expected current feature). I wonder how hard it is to
>> fix it (Observed in git 1.7.7 of openSUSE 12.1).
>
> See git.git's e90d065 for an example of adding a new diff pattern.
It's not necessary to wait until there is built-in support for a new language.
For example, for Windows resource files, I have
*.rc diff=winres
in .gitattributes or .git/info/attributes and
[diff "winres"]
xfuncname =
"!^(BEGIN|END|FONT|CAPTION|STYLE)\n^[a-zA-Z_][a-zA-Z_0-9]*.*\n^[[:space:]]*([[:alnum:]_]+,
*DIALOG.*)"
in .git/config (the xfuncname is all on a single line). The first part
beginning at ! up to \n tells to ignore the specified matches. The other
parts separated by \n tell the things to put in the hunk header. You can
have "ignore" parts (with exlamation mark) and "take this" parts (without)
in any order that is convenient, as long as the last one is "take this".
-- Hannes
^ permalink raw reply
* Git submodule for a local branch?
From: W. Trevor King @ 2012-10-22 12:37 UTC (permalink / raw)
To: Git
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
I have a bunch of branches in my repo (a, b, c, …), and I'd like to
check them out into subdirectories of another branch (index). My
initial inclination was to use something like
$ git checkout index
$ git branch
a
b
c
* index
$ git submodule add -b a --reference ./ ./ dir-for-a/
$ git submodule add -b b --reference ./ ./ dir-for-b/
$ git submodule add -b c --reference ./ ./ dir-for-c/
but cloning a remote repository (vs. checking out a local branch)
seems to be baked into the submodule implementation. Should I be
thinking about generalizing git-submodule.sh, or am I looking under
the wrong rock? My ideal syntax would be something like
$ git submodule add -b c --local dir-for-c/
The motivation is that I have website that contains a bunch of
sub-sites, and the sub-sites share content. I have per-sub-site
branches (a, b, c) and want a master branch (index) that aggregates
them. Perhaps this is too much to wedge into a single repository?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* signing commits with openssl/PKCS#11
From: Mat Arge @ 2012-10-22 13:38 UTC (permalink / raw)
To: git
Hy!
I would like to sign each commit with a X.509 certificate and a private key
stored on a PKCS#11 token. I assume that that should be possible somehow using
a hook which calls openssl. Does somebody know a working implementation of
this?
cheers
Mat
^ permalink raw reply
* merge --no-commit not able to report stats more verbosely?
From: Scott R. Godin @ 2012-10-22 13:39 UTC (permalink / raw)
To: git
As you can see from the below, I can't seem to get it to give me more
verbose results of what's being merged (as in the actual merge below)
with --stat or -v .. is it supposed to do that?
(develop)>$ git merge --no-commit --stat -v widget_twitter
Automatic merge went well; stopped before committing as requested
(develop|MERGING)>$ git merge --abort
(develop)>$ git merge widget_twitter
Merge made by the 'recursive' strategy.
.../code/community/Dnd/Magentweet/Model/User.php | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
(develop)>$ git --version
git version 1.7.7.6
--
(please respond to the list as opposed to my email box directly,
unless you are supplying private information you don't want public
on the list)
^ permalink raw reply
* Re: [PATCH] transport-helper: check when helpers fail
From: Johannes Sixt @ 2012-10-22 13:46 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <CAMP44s2XDkLhKkqvxnGH+U5X=42dXU1550xVQvyQk=WD2p0c6Q@mail.gmail.com>
Am 10/22/2012 13:50, schrieb Felipe Contreras:
> On Mon, Oct 22, 2012 at 8:35 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Another thought: In your use-case, isn't it so that it would be an error
>> that the process exited for whatever reason? I.e., even if it exited with
>> code 0 ("success"), it would be an error because it violated the protocol?
>
> How is that violating the protocol?
Because the helper stops talking too early. But as I said, I actually
don't know the protocol.
I was just infering what I saw in transport-helper.c: get_helper() dup's
the output of the helper process and stores it in data->out (after
fdopen()ing on it). (The original file descriptor is handed over to
fast-import or fast-export.)
Actually, I didn't find a spot where data->out was used except to fclose()
it. But I take it that there is a reason that it exists and infer that
further output from the helper is expected by something after fast-import
or fast-export have exited.
But I may be completely off...
-- Hannes
^ permalink raw reply
* Re: make test
From: Joachim Schmitz @ 2012-10-22 14:19 UTC (permalink / raw)
To: git
"Joachim Schmitz" <jojo@schmitz-digital.de> schrieb im Newsbeitrag news:<k5gov5$fe1$1@ger.gmane.org>...
> Hi folks
>
> I'm trying to understand why certain tests in 'make test' fail. Here's the
> first one
>
> $ ../git --version
> git version 1.8.0.rc2.5.g6b89306
> $ GIT_TEST_CMP_USE_COPIED_CONTEXT=true ./t0000-basic.sh # our diff doesn't
> understand -u
> ok 1 - .git/objects should be empty after git init in an empty repo
> ...
> ok 3 - success is reported like this
> not ok 4 - pretend we have a known breakage # TODO known breakage
>
> This is expected, right?
>
> ok 5 - pretend we have fixed a known breakage (run in sub test-lib)
> ...
> ok 11 - tests clean up after themselves
>
> the next is not though? Why might it be failing, where to check?
>
> not ok - 12 tests clean up even on failures
> #
> # mkdir failing-cleanup &&
> # (
> # cd failing-cleanup &&
> #
> # cat >failing-cleanup.sh <<-EOF &&
> # #!/bin/sh
> #
> # test_description='Failing tests with cleanup commands'
> #
> # # Point to the t/test-lib.sh, which isn't in ../ as usual
> # TEST_DIRECTORY="/home/jojo/git/git/t"
> # . "$TEST_DIRECTORY"/test-lib.sh
> #
> # test_expect_success 'tests clean up even after a failure' '
> # touch clean-after-failure &&
> # test_when_finished rm clean-after-failure &&
> # (exit 1)
> # '
> # test_expect_success 'failure to clean up causes the test to
> fail' '
> # test_when_finished "(exit 2)"
> # '
> # test_done
> #
> # EOF
> #
> # chmod +x failing-cleanup.sh &&
> # test_must_fail ./failing-cleanup.sh >out 2>err &&
> # ! test -s err &&
> # ! test -f "trash
> directory.failing-cleanup/clean-after-failure" &&
> # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF &&
> # > not ok - 1 tests clean up even after a failure
> # > # Z
> # > # touch clean-after-failure &&
> # > # test_when_finished rm clean-after-failure &&
> # > # (exit 1)
> # > # Z
> # > not ok - 2 failure to clean up causes the test to fail
> # > # Z
> # > # test_when_finished "(exit 2)"
> # > # Z
> # > # failed 2 among 2 test(s)
> # > 1..2
> # EOF
> # test_cmp expect out
> # )
> #
> ok 13 - git update-index without --add should fail adding
> ...
> ok 47 - very long name in the index handled sanely
> # still have 1 known breakage(s)
> # failed 1 among remaining 46 test(s)
> 1..47
As mentioned elsethread this works if using bash rather than the system's sh (which is a ksh)
But there are several other failures. After some investigations and experiments I found the following tests to fail with the system
provided grep (for which I had to set GIT_TEST_CMP_USE_COPIED_CONTEXT), but succeed with GNU grep:
t3308 #14, #15, #17and #19
t3310 #10, #12, #14 and #18
t4047 #38 and #39
t4050 #2 and #3
t4116 #3, #4 and #5
t5509 #2
t7401 #18
The following fail with the system provided tar, but succeed with GNU tar:
t0024 #2
t4116 #4,
t5000 #14, #16, #20, #24, #26 and #51
t5001 #2, #6, #10 and #15
The following tests fail with the system provided sh (which is a ksh really), but succeed with bash:
t0000 #12
t0001 #20
t1450 #17 and #18
(t0204 #3 and #8 succeed in sh but fail in bash. They succeed in bash too when /usr/local/bin is in PATH first though, which would
sort the diff and tar problem too, need to investigate why)
t3006 #2 and #3
t3403 #4, #5, #8 and #9
t3404 #2 - #13, #14 - #18, #20 - #41, #44, #46 - #70
t3409 #2 - #5
t3410 #2 and #3
t3411 #2 and #3
t3412 #8, #10 - #12, #15, #17, #23, #25, -26, #28, #29, #31
t3413 #3, #5 - #10, #14, #15
and many more...
The following needs bash and /usr/local/bin first in PATH ("PATH=/usr/local/bin:$PATH make test")
t0204 #3 and #8 (or just sh, see above)
t3032 #11
t3900 #24, #25
t4201 #8
t5000 #14
t5150 #6
I though "SANE_TOOL_PATH=/usr/local/bin" plus "SHELL_PATH=/usr/local/bin/bash" would to fix the all but it does not and instead
brings up some other failures too:
t5521 #2 and #5
t5526 #2, #5, #8, #10, #12, #13, #16 - #19, #21 - #25
t5702 #3
t5800 #2, #3, #5 - #14
t9001 #66
With additionally having "PATH=/usr/local/bin:$PATH" all but one work, so there must be something wrong with SANE_TOOL_PATH?.
The single failure remaining is
t0301 #12 "helper (cache --timeout=1) times out"
I don't understand this at all, neither the -v options nor running it with bash -x helps me in understanding what the issue is.
Bye, Jojo
^ permalink raw reply
* [PATCH] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-22 14:30 UTC (permalink / raw)
To: git
This fixes the vast majority of test failures on HP NonStop.
Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
---
A few more still insist on /usr/local/bin being 1st in PATH and having done that
we're down to one single failing test, t0301 #12 "helper (cache --timeout=1) times out"
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..35380dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
MKDIR_WO_TRAILING_SLASH = YesPlease
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
+
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need ${prefix}/bin in PATH first
+ SHELL_PATH=${prefix}/bin/bash
+ SANE_TOOL_PATH=${prefix}/bin
+ # as of H06.25/J06.14, we might better use this
+ #SHELL_PATH=/usr/coreutils/bin/bash
+ #SANE_TOOL_PATH=/usr/coreutils/bin:${prefix}/bin
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
^ permalink raw reply related
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-22 14:31 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <50854E20.1040303@viscovery.net>
On Mon, Oct 22, 2012 at 3:46 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 10/22/2012 13:50, schrieb Felipe Contreras:
>> On Mon, Oct 22, 2012 at 8:35 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Another thought: In your use-case, isn't it so that it would be an error
>>> that the process exited for whatever reason? I.e., even if it exited with
>>> code 0 ("success"), it would be an error because it violated the protocol?
>>
>> How is that violating the protocol?
>
> Because the helper stops talking too early. But as I said, I actually
> don't know the protocol.
We could use the 'feature done' of fast-import, but this causes
problems because of the way transport-helper uses it:
-> import refs/heads/master
<- exported stuff
<- done
-> import refs/heads/devel
<- exported stuff
<- done
'done' will terminate the fast-import process, so the second exported
stuff won't be processed; the fast-import process is reused.
For some reason remote-testgit doesn't exercise this multiple import
stuff properly, but my remote-hg certainly does, so I can't just say
'done'.
It would be much better if the transport-helper protocol was something
like this:
-> import-begin
<- feature X
<- feature Y
-> import refs/heads/master
<- exported stuff
-> import refs/heads/devel
<- exported stuff
-> import-end
<- done
This would certainly makes things easier for transport-helpers that
support multiple ref selections (like my remote-hg). Maybe I should
add code that does this if certain feature is specified (so it doesn't
break other helpers)
But at least on my tests, even with 'feature done' the crash is not
detected properly, either by the transport-helper, or fast-import.
And also, the msysgit branch does the same check for fast-export,
which actually uses the 'done' feature always, so it should work fine,
but perhaps because of the strange issue with fast-import I just
mentioned, it's not actually detected. I should add tests for this
too.
> I was just infering what I saw in transport-helper.c: get_helper() dup's
> the output of the helper process and stores it in data->out (after
> fdopen()ing on it). (The original file descriptor is handed over to
> fast-import or fast-export.)
>
> Actually, I didn't find a spot where data->out was used except to fclose()
> it. But I take it that there is a reason that it exists and infer that
> further output from the helper is expected by something after fast-import
> or fast-export have exited.
>
> But I may be completely off...
Yes, further output is expected, or at least in theory.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-22 14:41 UTC (permalink / raw)
To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users
In-Reply-To: <5084102A.2010006@initfour.nl>
Herman van Rink <rink@initfour.nl> writes:
> On 10/21/2012 08:32 AM, Junio C Hamano wrote:
>> Herman van Rink <rink@initfour.nl> writes:
>>
>>> Junio, Could you please consider merging the single commit from my
>>> subtree-updates branch? https://github.com/helmo/git/tree/subtree-updates
>> In general, in areas like contrib/ where there is a volunteer area
>> maintainer, unless the change something ultra-urgent (e.g. serious
>> security fix) and the area maintainer is unavailable, I'm really
>> reluctant to bypass and take a single patch that adds many things
>> that are independent from each other.
>
> Who do you see as volunteer area maintainer for contrib/subtree?
> My best guess would be Dave. And he already indicated earlier in the
> thread to be ok with the combined patch as long as you are ok with it.
Let's be clear. Junio owns the project so what he says goes, no
question. I provided some review feedback which I thought would help
the patches get in more easily. We really shouldn't be adding multiple
features in one patch. This is easily separated into multiple patches.
Then there is the issue of testcases. We should NOT have git-subtree go
back to the pre-merge _ad_hoc_ test environment. We should use what the
usptream project uses. That will make mainlining this much easier in
the future.
If Junio is ok with overriding my decisions here, that's fine. But I
really don't understand why you are so hesitant to rework the patches
when it should be realtively easy. Certainly easier than convincing me
they are in good shape currently. :)
-David
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-22 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Herman van Rink, greened, Hilco Wijbenga, Git Users
In-Reply-To: <7vfw57fvtl.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I haven't formed an opinion on the particular change as to how bad
> its collapsing unrelated changes into a single change is. Maybe they
> are not as unrelated and form a coherent whole. Maybe not.
It is difficult for me to tell which is one of the red flags that caused
me to request breaking it up. It's much to hard to review this patch as
it is. It conflates multiple features and bug fixes. It includes
comments to the effect of, "I don't like this but I don't know of a
better way." Part of the reson we do reviews is to have people help out
and find a better way. I don't think people can do that with the way
the patch is currently structured.
> Note that I was not following the thread very closely, so I may have
> misread the discussion. I read his "Unless Junio accepts..." to
> mean "I (dag) still object, but if Junio accepts that patch I object
> to directly, there is nothing I can do about it". That is very
> different from "I am on the fence and cannot decide it is a good
> patch or not. I'll let Junio decide; I am OK as long as he is".
Yopur first reading is the correct one.
-David
^ permalink raw reply
* git daemon test fails
From: Joachim Schmitz @ 2012-10-22 14:48 UTC (permalink / raw)
To: git
Here's one test failing (on HP NonStop, git-1.8.0), which needs to get enable first.
/home/jojo/git/git/t $ PATH=/usr/local/bin:$PATH GIT_TEST_GIT_DAEMON=true bash ./t5570-git-daemon.sh
ok 1 - setup repository
ok 2 - create git-accessible bare repository
ok 3 - clone git repository
[946798748] Connection from 127.0.0.1:1569
[946798748] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[946798748] Request upload-pack for '/repo.git'
[577699972] [946798748] Disconnected
ok 4 - fetch changes via git protocol
[275710128] Connection from 127.0.0.1:1570
[275710128] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[275710128] Request upload-pack for '/repo.git'
[577699972] [275710128] Disconnected
not ok 5 - remote detects correct HEAD # TODO known breakage
ok 6 - prepare pack objects
ok 7 - fetch notices corrupt pack
[611254461] Connection from 127.0.0.1:1571
[611254461] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[611254461] Request upload-pack for '/repo_bad2.git'
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: unable to find 8a64388133550192054d8f512739602b36fdd015
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: refs/heads/master does not point to a valid object!
[611254461] error: non-monotonic index ./objects/pack/pack-a8625557c4445f4dac0b3b70b03f0a619d8edbff.idx
[611254461] error: refs/heads/other does not point to a valid object!
[611254461] error: git upload-pack: git-pack-objects died with error.
[611254461] fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
[577699972] [611254461] Disconnected (with error)
ok 8 - fetch notices corrupt idx
[711917757] Connection from 127.0.0.1:9908
[711917757] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[711917757] Request upload-pack for '/nowhere.git'
[711917757] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/nowhere.git' does not appear to be a git repository
[577699972] [711917757] Disconnected (with error)
ok 9 - clone non-existent
[779026621] Connection from 127.0.0.1:9909
[779026621] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[779026621] Request receive-pack for '/repo.git'
[779026621] 'receive-pack': service not enabled for '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git'
[577699972] [779026621] Disconnected (with error)
ok 10 - push disabled
[846135485] Connection from 127.0.0.1:9910
[846135485] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[846135485] Request upload-pack for '/repo.git'
[846135485] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git' does not appear to be a git repository
[577699972] [846135485] Disconnected (with error)
ok 11 - read access denied
[913244349] Connection from 127.0.0.1:9911
[913244349] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[913244349] Request upload-pack for '/repo.git'
[913244349] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/repo.git': repository not exported.
[577699972] [913244349] Disconnected (with error)
ok 12 - not exported
[1013907645] Connection from 127.0.0.1:9912
[1013907645] Extended attributes (21 bytes) exist <host=127.0.0.1:5570>
[1013907645] Request upload-pack for '/nowhere.git'
[1013907645] '/home/jojo/git/git/t/trash directory.t5570-git-daemon/repo/nowhere.git' does not appear to be a git repository
[577699972] [1013907645] Disconnected (with error)
not ok - 13 clone non-existent
# test_remote_error 'no such repository' clone nowhere.git
ok 14 - push disabled
ok 15 - read access denied
ok 16 - not exported
# still have 1 known breakage(s)
# failed 1 among remaining 15 test(s)
1..16
So one test fails.
But in real live here on HP NonStop "git clone" fails for any repository larger than a certain size (56k?) and it fails on the
daemon side (as e.g. a "git clone git://Gitgub/com/git/git.git" works just fine)
$ git clone git://localhost/some-repo.git
Cloning into 'some-repo'...
remote: warning: no threads support, ignoring --threads
remote: Counting objects: 485, done.
remote: Compressing objects: 100% (472/472), done. <<<< here it sits forever or until a timeout hits (if one is configured)
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
If I allow upload-archive, I get some 47k downloaded, then it hangs (and doesn't get killed by a timeout, so that "git-daemon
--timeout" only affects upload-pack apparently?)
Also it is always only a tar file, regardless whether I request zip, tar or tar.gz.
Any ideas anyone?
Bye, Jojo
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-22 14:47 UTC (permalink / raw)
To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users
In-Reply-To: <508459B3.6030403@initfour.nl>
Herman van Rink <rink@initfour.nl> writes:
> The problem is that I don't have the time to split all these out. Dag
> has indicated that he does not have the time either.
I would have the time to review and integrate separate patches. I do
not have time to unwrap the ball of wax and ensure the quality of each
feature and bug fix. That is the responsibility of the submitter. You
can't expect reviewers to do your work for you. I'm not being harsh, it
is simply the reality of how things work in every project I've been
involved with.
> This single ball of wax was already an alternative to the 'messy' merge
> history it had accumulated. The result of merging from dozens of github
> forks with numerous levels of parallel/contra-productive whitspace fixes.
Yes, we don't really want that history. You have a single patch now. A
series of git rebase -i + git add -i should make it easy to separate it
into patches for each feature and bug fix, as I suggested previously.
It really, really shouldn't be that hard unless the code is atrocious.
-David
^ permalink raw reply
* The config include mechanism doesn't allow for overwriting
From: Ævar Arnfjörð Bjarmason @ 2012-10-22 15:55 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jeff King, Junio C Hamano
I was hoping to write something like this:
[user]
name = Luser
email = some-default@example.com
[include]
path = ~/.gitconfig.d/user-email
Where that file would contain:
[user]
email = local-email@example.com
But when you do that git prints:
$ git config --get user.email
some-default@example.com
error: More than one value for the key user.email: local-email@example.com
I couldn't find information in either the commt that introduced the
feature or the documentation explaining whether this was the intent or
not.
I think config inclusion is much less useful when you can't clobber
previously assigned values.
^ permalink raw reply
* git BUG
From: Коньков Евгений @ 2012-10-22 16:28 UTC (permalink / raw)
To: git
Hi, git
I have get git bug while merging branches.
the farm has branch one year old. say b1
I have develop some feature in this year so I start new branch
git checkout master
git checkout -b b2
I get task to develop feature b1. b1 require changes in b2
git checkout b1
git merge b2
git checkout --theirs
git commit
after some time I need new code from master
git merge master
after this merge I notice that some code, that was developed in b2, is
disappeared despite on it was merged into b1
so I start to merge it again:
git merge b2
No results. So I decide to do some testing. I go to b2
git checkout b2
make changes into file on b2:
diff --git a/lib/SRS/Domain.pm b/lib/SRS/Domain.pm
index 8fa1b1a..23a9429 100644
--- a/lib/SRS/Domain.pm
+++ b/lib/SRS/Domain.pm
@@ -2804,6 +2804,7 @@ sub can_renew_state {
sub zone {
my ( $self ) = @_;
+
load_class 'SRS::Comm::Zone::Domain';
return
I have add one empty line to subroutine that have developed in b2.
git commit
git checkout b1
git merge b2
and I get conflict:
+++ b/lib/SRS/Domain.pm
@@@ -2830,24 -2801,20 +2830,29 @@@ sub can_renew_state
=cut
-sub zone {
- my ( $self ) = @_;
+sub can_cancel_transin {
+ my $self = shift;
++<<<<<<< HEAD
+ return if $self->{freeze_date};
+ return unless $self->{create_method} eq 'trans' && $self->{state} eq 'N';
++=======
+
+ load_class 'SRS::Comm::Zone::Domain';
++>>>>>>> yandex_mail_new_api
- return
- SRS::Comm::Zone::Domain->new(
- dname => $self->{dname},
- service => $self,
- );
+ my ( $pos_id ) = dbh_rw->selectrow_array(
+ 'SELECT bi.pos_id FROM billitems bi JOIN bills b ON b.bill_id = bi.bill_id WHERE service_id =
+ undef,
+ $self->{service_id}, $self->{user_id}
+ );
+
+ return $pos_id;
}
-=back
+=item cancel_transin
+
+Ф-ция отмены переноса
=cut
As you can see conflict at 'can_cancel_transin' subroutine
but I do changes in 'zone' subroutine
Please help to resolve that CONFLICT and return code from b2 to be
alive again in b1.
And, if you can, please explain why this occur
--
С уважением,
Коньков Евгений
Программист
Регистратор доменных имен REG.RU
Телефон: +38 (097) 7654-676
www.reg.ru
___________________
Sincerely yours,
Konkov Eugen
Developer
Accredited domain Registrar REG.RU, LLC.
Phone: +38 (097) 7654-676
www.reg.ru/en/
mailto:kes@reg.ru
^ permalink raw reply related
* merging branches
From: Коньков Евгений @ 2012-10-22 16:33 UTC (permalink / raw)
To: git
Hi, Git.
While merging branches I get conflicts in files that I have not touch.
Why they occour??
My suggestion is that that files that was automerged GIT counts as
they were modified by me, so next automerge to those files fill FAIL.
If so, how I can escape from that CONFLICT situation?
--
С уважением,
Коньков Евгений
Программист
Регистратор доменных имен REG.RU
Телефон: +38 (097) 7654-676
www.reg.ru
___________________
Sincerely yours,
Konkov Eugen
Developer
Accredited domain Registrar REG.RU, LLC.
Phone: +38 (097) 7654-676
www.reg.ru/en/
mailto:kes@reg.ru
^ permalink raw reply
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-22 17:12 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <CAMP44s1m9eVqqrgJFuWOBa3DCZAzAqpVwG8Nxn-6MbXWbF_2fw@mail.gmail.com>
On Mon, Oct 22, 2012 at 4:31 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> -> import-begin
> <- feature X
> <- feature Y
> -> import refs/heads/master
> <- exported stuff
> -> import refs/heads/devel
> <- exported stuff
> -> import-end
> <- done
>
> This would certainly makes things easier for transport-helpers that
> support multiple ref selections (like my remote-hg). Maybe I should
> add code that does this if certain feature is specified (so it doesn't
> break other helpers)
Never mind this, it's possible to do the same by assuming that all the
imports will be together, and finished by a line feed, so the code can
do:
if import
do import-begin stuff
while import
import stuff
do import-end stuff
Of course, this could break if for some reason transport-helper
changes, but that seems unlikely.
> But at least on my tests, even with 'feature done' the crash is not
> detected properly, either by the transport-helper, or fast-import.
Never mind this either; I was forcing the error before exporting that
feature. See the code at the end.
> And also, the msysgit branch does the same check for fast-export,
> which actually uses the 'done' feature always, so it should work fine,
> but perhaps because of the strange issue with fast-import I just
> mentioned, it's not actually detected. I should add tests for this
> too.
I have added tests for this, and the failure is detected reliably...
but only with remote-testgit, not with my remote-hg, and I've no idea
what is different.
I've tried everything, and yet a SIGPIPE is detected only with
remote-testgit, not with my code, and they both exit the same way, and
at the same time, and fast-export exits the main function (apparently
a process can finish with SIGPIPE after main?)
I have no idea what's going on, so I don't know if we need any extra
code in transport-helper at all.
Any ideas?
Here is what I have so far:
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index 5f3ebd2..b8707e6 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -159,6 +159,11 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
+ print "feature done"
+
+ if os.getenv("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
@@ -172,6 +177,9 @@ def do_export(repo, args):
if not repo.gitdir:
die("Need gitdir to export")
+ if os.getenv("GIT_REMOTE_TESTGIT_FAILURE"):
+ die('Told to fail')
+
update_local_repo(repo)
changed = repo.importer.do_import(repo.gitdir)
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
index e7dc668..00b0cd3 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t/t5800-remote-helpers.sh
@@ -145,4 +145,16 @@ test_expect_failure 'push new branch with old:new
refspec' '
compare_refs clone HEAD server refs/heads/new-refspec
'
+test_expect_success 'proper failure checks for fetching' '
+ export GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ (cd localclone && ! git fetch) 2> errors &&
+ grep -q "Error while running fast-import" errors
+'
+
+test_expect_success 'proper failure checks for pushing' '
+ export GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ (cd localclone && ! git push --all) 2> errors &&
+ grep -q "Error while running fast-export" errors
+'
+
test_done
--
Felipe Contreras
^ permalink raw reply related
* [PATCH] git-submodule add: Record branch name in .gitmodules
From: W. Trevor King @ 2012-10-22 16:34 UTC (permalink / raw)
To: Git; +Cc: W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
This removes a configuration step if you're trying to setup Ævar's
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
workflow from
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
If you're not using that workflow, I see no harm in recording the
branch used to determine the original submodule commit.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 3 ++-
git-submodule.sh | 4 ++++
t/t7400-submodule-basic.sh | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..b9f437f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -207,7 +207,8 @@ OPTIONS
-b::
--branch::
- Branch of repository to add as submodule.
+ Branch of repository to add as submodule. The branch name is
+ recorded in .gitmodules for future reference.
-f::
--force::
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..fd15a54 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -366,6 +366,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch "$branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..5031e2a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
+ test "$(git config -f .gitmodules submodule.submod-branch.branch)" = initial &&
git submodule init
) &&
--
1.8.0.2.g09b91ca
^ 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