Re: [PATCH] transport-helper: check when helpers fail
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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
On 10/21/2012 08:51 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@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
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] transport-helper: check when helpers fail
On Mon, Oct 22, 2012 at 8:35 AM, Johannes Sixt j.s...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff support for the Eiffel language?
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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-send-email: use compose-encoding for Subject
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 krzys...@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 nob...@example.com \
+ --to=nob...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: diff support for the Eiffel language?
On Mon, Oct 22, 2012 at 1:58 PM, Ulrich Windl ulrich.wi...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] grep: remove tautological check
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/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: diff support for the Eiffel language?
Am 10/22/2012 15:06, schrieb Ævar Arnfjörð Bjarmason: On Mon, Oct 22, 2012 at 1:58 PM, Ulrich Windl ulrich.wi...@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 *.rcdiff=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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git submodule for a local branch?
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 signature.asc Description: OpenPGP digital signature
signing commits with openssl/PKCS#11
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
merge --no-commit not able to report stats more verbosely?
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) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] transport-helper: check when helpers fail
Am 10/22/2012 13:50, schrieb Felipe Contreras: On Mon, Oct 22, 2012 at 8:35 AM, Johannes Sixt j.s...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test
Joachim Schmitz j...@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 ./t-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 2err # ! 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: t #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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix 'make test' for HP NonStop
This fixes the vast majority of test failures on HP NonStop.
Signed-off-by: Joachim Schmitz j...@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 = ;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] transport-helper: check when helpers fail
On Mon, Oct 22, 2012 at 3:46 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 10/22/2012 13:50, schrieb Felipe Contreras: On Mon, Oct 22, 2012 at 8:35 AM, Johannes Sixt j.s...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@initfour.nl writes: On 10/21/2012 08:32 AM, Junio C Hamano wrote: Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Junio C Hamano gits...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git daemon test fails
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subtree in Git
Herman van Rink r...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] transport-helper: check when helpers fail
On Mon, Oct 22, 2012 at 4:31 PM, Felipe Contreras
felipe.contre...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-submodule add: Record branch name in .gitmodules
From: W. Trevor King wk...@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 ava...@gmail.com Date: Fri May 21 16:10:10 2010 + 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 wk...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] transport-helper: check when helpers fail
On Mon, Oct 22, 2012 at 7:12 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Oct 22, 2012 at 4:31 PM, Felipe Contreras
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?
Must be a timing issue:
sh -c 'echo hello' | sh -c 'exit 1' - no signal
sh -c 'echo hello' | /usr/bin/false - SIGPIPE
I can trigger it by adding an extra delay:
This works:
test_expect_success 'proper failure checks for pushing 1' '
export GIT_REMOTE_TESTGIT_FAILURE=1
(cd localclone ! git push --all) 2 errors
grep -q Error while running fast-export errors
'
This doesn't:
test_expect_success 'proper failure checks for pushing 2' '
export GIT_REMOTE_TESTGIT_FAILURE=1
export GIT_REMOTE_TESTGIT_SLEEPY=1
(cd localclone ! git push --all) 2 errors
grep -q Error while running fast-export errors
'
This does:
test_expect_success 'proper failure checks for pushing 3' '
export GIT_REMOTE_TESTGIT_FAILURE=1
export GIT_REMOTE_TESTGIT_SLEEPY=1
(cd localclone ! git push --all) 2 errors
grep -q Told to fail errors
'
So, depending on your luck, transport-helper might or might display an
error, it will exit at the right place nonetheless, because of:
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, Debug: Remote helper quit.\n);
exit(128);
}
Not ideal, but I guess it's not a big deal.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/8] longest_ancestor_length(): require prefix list entries to be normalized
Am 21.10.2012 07:57, schrieb Michael Haggerty: Move the responsibility for normalizing the prefixes passed to longest_ancestor_length() to its caller. In t0060, only test longest_ancestor_lengths using normalized paths: remove empty entries and non-absolute paths, strip trailing slashes from the paths, and remove tests that thereby become redundant. t0060 does not pass on Windows with this change. Bash's path mangling strikes again, but the real reason for the failure is that test-path-util does not normalize its input before it calls into longest_ancestor_length(). It is not sufficient to reduce the test cases to normalized ones, because due to path mangling on Windows they are turned into unnormalized paths (with backslashes instead of forward slashes). I suggest to export the new normalize_ceiling_entry() and use it from test-path-util. Then don't change or remove existing tests. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote-testgit: properly check for errors
'feature done' was missing, which allowed fast-import exit properly, and
transport-helper to continue checking for refs and what not when in fact
the remote-helper died.
Let's enable that, and make sure the error paths are triggered.
Now transport-helper correctly detects the errors from fast-import,
unfortunately, not from fast-export because it might finish before
detecting a SIGPIPE. This means transport-helper will quit silently and
the user will not see any errors, which is bad. Hopefully the helper
will print the error before dying anyway, so not all is lost.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit.py | 8
t/t5800-remote-helpers.sh | 21 +
2 files changed, 29 insertions(+)
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.environ.get(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.environ.get(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..446cc8e 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t/t5800-remote-helpers.sh
@@ -145,4 +145,25 @@ 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' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1
+ export GIT_REMOTE_TESTGIT_FAILURE
+ cd localclone
+ test_must_fail git fetch 21 | \
+ grep Error while running fast-import
+ )
+'
+
+# We sleep to give fast-export a chance to catch the SIGPIPE
+test_expect_failure 'proper failure checks for pushing' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1
+ export GIT_REMOTE_TESTGIT_FAILURE
+ GIT_REMOTE_TESTGIT_SLEEPY=1
+ export GIT_REMOTE_TESTGIT_SLEEPY
+ cd localclone
+ test_must_fail git push --all 21 | \
+ grep Error while running fast-export
+ )
+'
+
test_done
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-testgit: properly check for errors
On Mon, Oct 22, 2012 at 1:56 PM, Felipe Contreras felipe.contre...@gmail.com wrote: 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 There's not enough context for me to see in which part of the code this is, import or export? If you advertise 'feature done', shouldn't you also print 'done' when you finish writing the fast-export stream? If that's already the case feel free to ignore me :) -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The config include mechanism doesn't allow for overwriting
On Mon, Oct 22, 2012 at 05:55:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
I was hoping to write something like this:
[user]
name = Luser
email = some-defa...@example.com
[include]
path = ~/.gitconfig.d/user-email
Where that file would contain:
[user]
email = local-em...@example.com
The intent is that it would work as you expect, and produce
local-em...@example.com.
But when you do that git prints:
$ git config --get user.email
some-defa...@example.com
error: More than one value for the key user.email:
local-em...@example.com
Ugh. The config code just feeds all the values sequentially to the
callback. The normal callbacks within git will overwrite old values,
whether from earlier in the file, from a file with lower priority (e.g.,
/etc/gitconfig versus ~/.gitconfig), or from an earlier included. Which
you can check with:
$ git var GIT_AUTHOR_IDENT
Luser local-em...@example.com 1350936694 -0400
But git-config takes it upon itself to detect duplicates in its
callback. Which is just silly, since it is not something that regular
git would do. git-config should behave as much like the internal git
parser as possible.
I think config inclusion is much less useful when you can't clobber
previously assigned values.
Agreed. But I think the bug is in git-config, not in the include
mechanism. I think I'd like to do something like the patch below, which
just reuses the regular config code for git-config, collects the values,
and then reports them. It does mean we use a little more memory (for the
sake of simplicity, we store values instead of streaming them out), but
the code is much shorter, less confusing, and automatically matches what
regular git_config() does.
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
---
builtin/config.c | 111 ---
1 file changed, 38 insertions(+), 73 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d6a066b..72cb0a8 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -16,7 +16,6 @@ static int do_not_match;
static int use_key_regexp;
static int do_all;
static int do_not_match;
-static int seen;
static char delim = '=';
static char key_delim = ' ';
static char term = '\n';
@@ -110,12 +109,19 @@ static int show_config(const char *key_, const char
*value_, void *cb)
return 0;
}
-static int show_config(const char *key_, const char *value_, void *cb)
+struct strbuf_list {
+ struct strbuf *items;
+ int nr;
+ int alloc;
+};
+
+static int collect_config(const char *key_, const char *value_, void *cb)
{
+ struct strbuf_list *values = cb;
+ struct strbuf *buf;
char value[256];
const char *vptr = value;
int must_free_vptr = 0;
- int dup_error = 0;
int must_print_delim = 0;
if (!use_key_regexp strcmp(key_, key))
@@ -126,12 +132,15 @@ static int show_config(const char *key_, const char
*value_, void *cb)
(do_not_match ^ !!regexec(regexp, (value_?value_:), 0, NULL, 0)))
return 0;
+ ALLOC_GROW(values-items, values-nr + 1, values-alloc);
+ buf = values-items[values-nr++];
+ strbuf_init(buf, 0);
+
if (show_keys) {
- printf(%s, key_);
+ strbuf_addstr(buf, key_);
must_print_delim = 1;
}
- if (seen !do_all)
- dup_error = 1;
+
if (types == TYPE_INT)
sprintf(value, %d, git_config_int(key_, value_?value_:));
else if (types == TYPE_BOOL)
@@ -153,16 +162,12 @@ static int show_config(const char *key_, const char
*value_, void *cb)
vptr = ;
must_print_delim = 0;
}
- seen++;
- if (dup_error) {
- error(More than one value for the key %s: %s,
- key_, vptr);
- }
- else {
- if (must_print_delim)
- printf(%c, key_delim);
- printf(%s%c, vptr, term);
- }
+
+ if (must_print_delim)
+ strbuf_addch(buf, key_delim);
+ strbuf_addstr(buf, vptr);
+ strbuf_addch(buf, term);
+
if (must_free_vptr)
/* If vptr must be freed, it's a pointer to a
* dynamically allocated buffer, it's safe to cast to
@@ -175,20 +180,8 @@ static int get_value(const char *key_, const char *regex_)
static int get_value(const char *key_, const char *regex_)
{
- int ret = CONFIG_GENERIC_ERROR;
- char *global = NULL, *xdg = NULL, *repo_config = NULL;
- const char *system_wide = NULL, *local;
- struct config_include_data inc = CONFIG_INCLUDE_INIT;
- config_fn_t fn;
- void *data;
-
- local = given_config_file;
- if (!local) {
- local = repo_config = git_pathdup(config);
-
tag storage format
I'm doing some testing on a large Git repository and am finding local clones to take a very long time. After some investigation I've determined that the problem is due to a very large number of tags (~38k). Even with hard links, it just takes a really long time to visit that many inodes. As it happens, I don't care for most of these tags and will prune many of them anyway but I expect that over time it will creep back up again. Have others reported this problem before and is there a workaround? Perhaps Git should switch to a single-file block text or binary format once a large number of tags becomes present in a repository. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tag storage format
Uri Moszkowicz u...@4refs.com writes: Perhaps Git should switch to a single-file block text or binary format once a large number of tags becomes present in a repository. This is what git pack-refs (called by git gc) does (by putting the refs in .git/packed-refs). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git-pull: Avoid merge-base on detached head
git pull --rebase does some clever tricks to find the base
for $upstream , but it forgets that we may not have any
branch at all. When this happens, git merge-base reports its
usage help in the middle of an otherwise successful
rebase operation, because git-merge is called with one too
few parameters.
Since we do not need the merge-base trick in the case of a
detached HEAD, detect this condition and bypass the clever
trick and the usage noise.
---
git-pull.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..266e682 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -200,6 +200,7 @@ test true = $rebase {
require_clean_work_tree pull with rebase Please commit or
stash them.
fi
oldremoteref=
+ test -n $curr_branch
. git-parse-remote
remoteref=$(get_remote_merge_branch $@ 2/dev/null)
oldremoteref=$(git rev-parse -q --verify $remoteref)
--
1.8.0.2.ge1a3bdd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-status: show short sequencer state
Recently git-status learned to display the state of the git
sequencer in long form to help the user remember an interrupted
command. This information is also useful in short form to
humans and scripts, but no option is available to boil it down.
Teach git-status to report the sequencer state in short form
using a new --sequencer (-S) switch. Output zero or more
simple state token strings indicating the deduced state of the
git sequencer.
Introduce a common function to determine the current sequencer
state so the regular status function and this short version can
share common code.
Add a substate to wt_status_state to track more detailed
information about a state, such as conflicted or resolved.
Move the am_empty_patch flage out of wt_status_state and into
this new substate.
State token strings which may be emitted and their meanings:
merge a git-merge is in progress
am a git-am is in progress
rebase a git-rebase is in progress
rebase-interactive a git-rebase--interactive is in progress
cherry-picka git-cherry-pick is in progress
bisect a git-bisect is in progress
conflicted there are unresolved conflicts
resolved conflicts have been resolved
editinginteractive rebase stopped to edit a commit
edited interactive rebase edit has been edited
splitting interactive rebase, commit is being split
I also considered adding these tokens, but I decided it was not
appropriate since these changes are not sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
clean
index
modified
untracked
---
Documentation/git-status.txt | 18 ++
builtin/commit.c | 12 +++-
wt-status.c | 128 +++
wt-status.h | 13 -
4 files changed, 146 insertions(+), 25 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..200a8e2 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,24 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+-S::
+--sequence::
+ Show the git sequencer status. This shows zero or more tokens
+ describing the state of several git sequence operations. Each
+ token is separated by a newline.
++
+ merge a git-merge is in progress
+ am a git-am is in progress
+ rebase a git-rebase is in progress
+ rebase-interactive a git-rebase--interactive is in progress
+ cherry-picka git-cherry-pick is in progress
+ bisect a git-bisect is in progress
+ conflicted there are unresolved conflicts
+ resolved conflicts have been resolved
+ editinginteractive rebase stopped to edit a commit
+ edited interactive rebase edit has been edited
+ splitting interactive rebase, commit is being split
+
-u[mode]::
--untracked-files[=mode]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..9706ed9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
+ STATUS_FORMAT_PORCELAIN,
+ STATUS_FORMAT_SEQUENCER
} status_format = STATUS_FORMAT_LONG;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
@@ -454,6 +455,9 @@ static int run_status(FILE *fp, const char *index_file,
const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+ break;
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1156,6 +1160,9 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
N_(show status concisely), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', branch, s.show_branch,
N_(show branch information)),
+ OPT_SET_INT('S', sequence, status_format,
+ N_(show sequencer state),
+ STATUS_FORMAT_SEQUENCER),
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
@@ -1216,6 +1223,9 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_SEQUENCER:
+ wt_sequencer_print(s);
+
Re: [PATCH] remote-testgit: properly check for errors
On Mon, Oct 22, 2012 at 11:01 PM, Sverre Rabbelier srabbel...@gmail.com wrote: On Mon, Oct 22, 2012 at 1:56 PM, Felipe Contreras felipe.contre...@gmail.com wrote: 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 There's not enough context for me to see in which part of the code this is, import or export? Isn't this enough? @@ -159,6 +159,11 @@ def do_import(repo, args): It's import. If you advertise 'feature done', shouldn't you also print 'done' when you finish writing the fast-export stream? If that's already the case feel free to ignore me :) It's already there: http://git.kernel.org/?p=git/git.git;a=blob;f=git-remote-testgit.py#l165 Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
These functions are called in sequencer.c, which is part of
libgit.a. This makes libgit.a potentially require builtin/merge.c for
external git commands.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
I made some unrelated changes in sequencer.c and this problem shown
up. merge-recursive.c is probably not the best place for these
functions. I just don't want to create merge.c for them.
builtin/merge.c | 106 +
cache.h | 3 --
merge-recursive.c | 108 ++
merge-recursive.h | 4 ++
sequencer.c | 2 +-
5 files changed, 115 insertions(+), 108 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 0ec8f0d..a96e8ea 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -628,59 +628,6 @@ static void write_tree_trivial(unsigned char *sha1)
die(_(git write-tree failed to write a tree));
}
-static const char *merge_argument(struct commit *commit)
-{
- if (commit)
- return sha1_to_hex(commit-object.sha1);
- else
- return EMPTY_TREE_SHA1_HEX;
-}
-
-int try_merge_command(const char *strategy, size_t xopts_nr,
- const char **xopts, struct commit_list *common,
- const char *head_arg, struct commit_list *remotes)
-{
- const char **args;
- int i = 0, x = 0, ret;
- struct commit_list *j;
- struct strbuf buf = STRBUF_INIT;
-
- args = xmalloc((4 + xopts_nr + commit_list_count(common) +
- commit_list_count(remotes)) * sizeof(char *));
- strbuf_addf(buf, merge-%s, strategy);
- args[i++] = buf.buf;
- for (x = 0; x xopts_nr; x++) {
- char *s = xmalloc(strlen(xopts[x])+2+1);
- strcpy(s, --);
- strcpy(s+2, xopts[x]);
- args[i++] = s;
- }
- for (j = common; j; j = j-next)
- args[i++] = xstrdup(merge_argument(j-item));
- args[i++] = --;
- args[i++] = head_arg;
- for (j = remotes; j; j = j-next)
- args[i++] = xstrdup(merge_argument(j-item));
- args[i] = NULL;
- ret = run_command_v_opt(args, RUN_GIT_CMD);
- strbuf_release(buf);
- i = 1;
- for (x = 0; x xopts_nr; x++)
- free((void *)args[i++]);
- for (j = common; j; j = j-next)
- free((void *)args[i++]);
- i += 2;
- for (j = remotes; j; j = j-next)
- free((void *)args[i++]);
- free(args);
- discard_cache();
- if (read_cache() 0)
- die(_(failed to read the cache));
- resolve_undo_clear();
-
- return ret;
-}
-
static int try_merge_strategy(const char *strategy, struct commit_list *common,
struct commit_list *remoteheads,
struct commit *head, const char *head_arg)
@@ -762,56 +709,6 @@ static int count_unmerged_entries(void)
return ret;
}
-int checkout_fast_forward(const unsigned char *head, const unsigned char
*remote)
-{
- struct tree *trees[MAX_UNPACK_TREES];
- struct unpack_trees_options opts;
- struct tree_desc t[MAX_UNPACK_TREES];
- int i, fd, nr_trees = 0;
- struct dir_struct dir;
- struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
-
- refresh_cache(REFRESH_QUIET);
-
- fd = hold_locked_index(lock_file, 1);
-
- memset(trees, 0, sizeof(trees));
- memset(opts, 0, sizeof(opts));
- memset(t, 0, sizeof(t));
- if (overwrite_ignore) {
- memset(dir, 0, sizeof(dir));
- dir.flags |= DIR_SHOW_IGNORED;
- setup_standard_excludes(dir);
- opts.dir = dir;
- }
-
- opts.head_idx = 1;
- opts.src_index = the_index;
- opts.dst_index = the_index;
- opts.update = 1;
- opts.verbose_update = 1;
- opts.merge = 1;
- opts.fn = twoway_merge;
- setup_unpack_trees_porcelain(opts, merge);
-
- trees[nr_trees] = parse_tree_indirect(head);
- if (!trees[nr_trees++])
- return -1;
- trees[nr_trees] = parse_tree_indirect(remote);
- if (!trees[nr_trees++])
- return -1;
- for (i = 0; i nr_trees; i++) {
- parse_tree(trees[i]);
- init_tree_desc(t+i, trees[i]-buffer, trees[i]-size);
- }
- if (unpack_trees(nr_trees, t, opts))
- return -1;
- if (write_cache(fd, active_cache, active_nr) ||
- commit_locked_index(lock_file))
- die(_(unable to write new index file));
- return 0;
-}
-
static void split_merge_strategies(const char *string, struct strategy **list,
int *nr, int *alloc)
{
@@ -1424,7 +1321,8 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
}
if
Re: Links broken in ref docs.
So, this is due to the major AWS outage today. git-scm.com is hosted on Heroku and thus on AWS. Heroku is continuing to bring up their database systems in the wake of the massive AWS outage. Once that is back online, git-scm.com will also be back online. As for the git-fetch issue, we'll look into it once Heroku is back online. Scott On Mon, Oct 22, 2012 at 7:34 PM, Mike Norman mknor...@gmail.com wrote: This seems worse. The entire site is now down with an application error. Reporting this out of surprise and just in case the dev on the job has the site cached somehow and can't see the error. Image (hopefully) attached and the message is as appears below, in case the attachment gets stripped. (Tags for convenience and not part of error.) errortext Application Error An error occurred in the application and your page could not be served. Please try again in a few moments. If you are the application owner, check your logs for details. /errortext Hope this helps, Mike Norman On Sun, Oct 21, 2012 at 9:45 PM, Andrew Ardill andrew.ard...@gmail.com wrote: On 21 October 2012 18:31, Mike Norman mknor...@gmail.com wrote: Many links on scm-git.org/docs simply reload the page. For example, all of Sharing and Updating section simply reload the docs page. And tons others. Must be a broken link or routing problem. Repros on FF 14.0.1 and Chrome. Good luck! Including Scott Chacon as he manages this site (to my knowledge). Looking at the request, I am getting a 302: Request URL:http://git-scm.com/docs/git-fetch Request Method:GET Status Code:302 Moved Temporarily Maybe those pages are not done yet? That doesn't seem right as this is simply the reference manual, but perhaps there is something else going on here. On another (related) note, the wayback machine has some very interesting entries for the scm-git.org domain [1] and it seems the /doc directory is not indexed at all. Is this on purpose? Regards, Andrew Ardill [1] http://wayback.archive.org/web/*/http://git-scm.com/* -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] (git commit --patch --message $MESSAGE) disallows hunk editing
Tested against v1.7.12.4 Steps to reproduce: A. cd $DIRTY_WORKING_COPY B. git commit --patch --message $MESSAGE C. Stage this hunk? e Expected behavior: After step C, the hunk opens in the user's editor Actual behavior: After step C, the hunk is selected unedited (as if the user had entered y) AFAICT, this occurs because of the following code in builtin/commit.c:parse_and_validate_options: if (... || message.len || ...) use_editor = 0; ... if (!use_editor) setenv(GIT_EDITOR, :, 1); Because --message is specified, GIT_EDITOR is set to :, which prevents the user from editing hunks, although the intent is most likely to just prevent the user from editing the commit message. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
