* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Jeff King @ 2009-01-27 12:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <497EDCB0.8080806@kdbg.org>
On Tue, Jan 27, 2009 at 11:06:40AM +0100, Johannes Sixt wrote:
> - Note that run_command returns the negated exit code, therefore, we must
> negate it again in the call to exit(). Without this t6030 failed. (And
> negative exit codes causes grief on Windows because bash for some reason
> does not recognize that as failure.)
Oops, indeed. And you made me realize that I forgot to run the test
script against this patchset.
However, I'm not sure just negating the exit code is sufficient.
run_command can return codes in the 10000 range for its own internal
errors. We don't want to pass those out through exit, which will
truncate them to 8 bits.
> - The close() calls can overwrite errno.
Good point.
> And since fork() should not (cannot?) fail with ENOENT, it's safe to
> remove the #ifdef __MINGW32__.
Yeah, I thought of that, but I was worried it might make the code a
little bit non-obvious (but it does clean up an ifdef, which is ugly,
too).
Thanks for your feedback. I'll squash in your fixes and repost 2/3 later
today.
-Peff
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Sverre Rabbelier @ 2009-01-27 12:16 UTC (permalink / raw)
To: Ittay Dror; +Cc: Michael J Gruber, git
In-Reply-To: <497EE4E8.8070705@gmail.com>
On Tue, Jan 27, 2009 at 11:41, Ittay Dror <ittay.dror@gmail.com> wrote:
> git: ----v1----v2----v3--v4---v5
> svn: \---v4--v5
>
> so the svn history starts from v3, but the git history remains unchanged.
Create the new branch from v3 then, and use git svn to pull it in.
Then you can do 'git rebase that-svn-branch' on your git branch to put
all commits (not as one big commit) on top of that branch point. Now
you 'git checkout' that-svn-branch and do 'git reset --hard
the-git-branch', which should now consist of
v1--v2--v3--v4(git)--v5(git), etc. If you do 'git svn dcommit' from
the that-svn-branch now it should dcommit to svn each of your git
commits individually. Of course, don't forget to make a backup before
you start messing around :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Mike Ralphson @ 2009-01-27 12:06 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <86myddj6qi.fsf@broadpark.no>
2009/1/27 Kjetil Barvik <barvik@broadpark.no>
> Mike Ralphson <mike.ralphson@gmail.com> writes:
>
> > 2009/1/26 Kjetil Barvik <barvik@broadpark.no>:
> >> Currently inside show_patch_diff() we have and fstat() call after an
> >> ok lstat() call. Since we before the call to fstat() have already
> >> test for the link case with S_ISLNK() the fstat() can be removed.
> >
> > s/have and/have an/ ?
>
> Correct! Will fix. Thanks!
Typo stood out and blinded me to the rest of the grammar... How about:
Currently inside show_patch_diff() we have an fstat() call after an
ok lstat() call. Since before the call to fstat() we have already
tested for the link case with S_ISLNK(), the fstat() can be removed.
'Half-a-job' Mike
^ permalink raw reply
* Re: [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Kjetil Barvik @ 2009-01-27 12:03 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git
In-Reply-To: <e2b179460901270135j6e4cb887radbe664ac98f39f1@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> writes:
> 2009/1/26 Kjetil Barvik <barvik@broadpark.no>:
>> Currently inside show_patch_diff() we have and fstat() call after an
>> ok lstat() call. Since we before the call to fstat() have already
>> test for the link case with S_ISLNK() the fstat() can be removed.
>
> s/have and/have an/ ?
Correct! Will fix. Thanks!
-- kjetil
^ permalink raw reply
* [PATCH] Fix submodule squashing into unrelated commit
From: Johannes Schindelin @ 2009-01-27 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljsxyv58.fsf@gitster.siamese.dyndns.org>
Actually, I think the issue is pretty independent of submodules; when
"git commit" gets an empty parameter, it misinterprets it as a file.
So avoid passing an empty parameter to "git commit".
Actually, this is a nice cleanup, as MSG_FILE and EDIT_COMMIT were mutually
exclusive; use one variable instead
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
We might want to safeguard "git commit", too.
git-rebase--interactive.sh | 9 ++++-----
t/t3404-rebase-interactive.sh | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 002929e..3ac7162 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -373,17 +373,15 @@ do_next () {
pick_one -n $sha1 || failed=t
case "$(peek_next_command)" in
squash|s)
- EDIT_COMMIT=
USE_OUTPUT=output
MSG_OPT=-F
- MSG_FILE="$MSG"
+ EDIT_OR_FILE="$MSG"
cp "$MSG" "$SQUASH_MSG"
;;
*)
- EDIT_COMMIT=-e
USE_OUTPUT=
MSG_OPT=
- MSG_FILE=
+ EDIT_OR_FILE=-e
rm -f "$SQUASH_MSG" || exit
cp "$MSG" "$GIT_DIR"/SQUASH_MSG
rm -f "$GIT_DIR"/MERGE_MSG || exit
@@ -397,7 +395,8 @@ do_next () {
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- $USE_OUTPUT git commit --no-verify $MSG_OPT "$MSG_FILE" $EDIT_COMMIT || failed=t
+ $USE_OUTPUT git commit --no-verify \
+ $MSG_OPT "$EDIT_OR_FILE" || failed=t
fi
if test $failed = t
then
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 6ffb9ad..4becc55 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -484,7 +484,7 @@ test_expect_success 'submodule rebase setup' '
git commit -a -m "Three changes submodule"
'
-test_expect_failure 'submodule rebase -i' '
+test_expect_success 'submodule rebase -i' '
FAKE_LINES="1 squash 2 3" git rebase -i A
'
--
1.6.1.482.g7d54be
^ permalink raw reply related
* Re: Translations [of Documentation] in Git release?
From: Jakub Narebski @ 2009-01-27 11:16 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List, Mike Hommey, Dill, Sverre Rabbelier
In-Reply-To: <Pine.LNX.4.64.0901270800100.26770@ds9.cixit.se>
On Tue, 27 Jan 2009, Peter Krefting wrote:
> Sverre Rabbelier:
>
> > Perhaps the basics can be translated at least, the documents that do
> > not require much change because they represent stable concepts?
>
> I usually start out translating the program output, then manual pages,
> and then, time permitting, documentation.
The problem with translating program output (program messages) in Git
is twofold: fundamental and technical. Fundamental, that program
output is considered API (at least for plumbing commands) and used
when scripting (this might be ameliorated with "I am script" switch
or environmental variable). Technical, because Git is mixture of
programs in C, shell scripts, and Perl scripts, and you have to come
with technical means of translating messages in all three of them.
> Git is a bit special in that regard since "--help" gets hardwired to
> display the manual page, so one can't just translate the help screen.
Not in all cases. Sometimes it shows "long usage". Perhaps that should
be made more consistent?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Alexandre Julliard @ 2009-01-27 11:03 UTC (permalink / raw)
To: Peter Simons; +Cc: git
In-Reply-To: <87tz7mth3g.fsf@write-only.cryp.to>
Peter Simons <simons@cryp.to> writes:
> Other modes, such as message-mode, do support that kind of thing
> correctly, so apparently it is possible to configure what the editor
> considers as a paragraph. Is there some Emacs wizard out there who'd
> be kind enough to improve git-mode accordingly?
You could try something like this:
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 3c37d0d..e314c44 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1331,6 +1331,7 @@ Return the list of files that haven't been handled."
(log-edit-diff-function . git-log-edit-diff)) buffer)
(log-edit 'git-do-commit nil 'git-log-edit-files buffer))
(setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
+ (setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
(setq buffer-file-coding-system coding-system)
(re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-27 10:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <497EE386.5050805@drmicha.warpmail.net>
Michael J Gruber wrote:
> Ittay Dror venit, vidit, dixit 01/27/09 05:10:
>
>> Hi,
>>
>>
>> I'd like to create a branch in a subversion repository so that I can
>> work with git-svn on it.
>>
>>
>> My git repository is already with a history, that I don't want to
>> replicate to subversion, I want to start with subversion having just the
>> latest revision and then continue from there normally (git svn
>> dcommit/rebase).
>>
>>
>> How can I do that?
>>
>
> Create the svn branch (with svn) and "git svn clone". Pull in your git
> branch under a new name (if that is what you want).
> Now, you can e.g. "git merge -s theirs" your other git branch into
> master, git svn rebase and dcommit. Untested, but comes with best wishes ;)
>
but wouldn't that create a revision in svn for each commit in git?
what i want is something like:
git: ----v1----v2----v3--v4---v5
svn: \---v4--v5
so the svn history starts from v3, but the git history remains unchanged.
ittay
> Do you want to discard your existing git history completely?
>
> Cheers,
> Michael
>
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Michael J Gruber @ 2009-01-27 10:35 UTC (permalink / raw)
To: Ittay Dror; +Cc: git
In-Reply-To: <497E8927.1060506@gmail.com>
Ittay Dror venit, vidit, dixit 01/27/09 05:10:
> Hi,
>
>
> I'd like to create a branch in a subversion repository so that I can
> work with git-svn on it.
>
>
> My git repository is already with a history, that I don't want to
> replicate to subversion, I want to start with subversion having just the
> latest revision and then continue from there normally (git svn
> dcommit/rebase).
>
>
> How can I do that?
Create the svn branch (with svn) and "git svn clone". Pull in your git
branch under a new name (if that is what you want).
Now, you can e.g. "git merge -s theirs" your other git branch into
master, git svn rebase and dcommit. Untested, but comes with best wishes ;)
Do you want to discard your existing git history completely?
Cheers,
Michael
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Mike Ralphson @ 2009-01-27 10:10 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
In-Reply-To: <9E98493A-B17A-4905-8BEA-3E0B837961D6@gmail.com>
2009/1/26 Perry Smith <pedzsan@gmail.com>:
> Thanks guys. I picked up coreutils version 7. I didn't
> install them but just moved ginstall over to /usr/local/bin.
>
> A few other comments: I had to add in the --without-tcltk flag. I don't
> have tcl installed but the config did not autodetect that it was not present.
Yup, I usually build with NO_TCLTK=YesPlease in my config.mak, which
you can see from the link Peff posted.
When you said 'out of tree builds' I thought you meant using the AIX
defaults in the Makefile without running ./configure, but it seems
not, you meant is a clone of the tree buildable by itself or are only
release snapshots buildable. Sorry.
./configure is (deliberately) a second-class citizen in the world of
git, and may still get you a slightly suboptimal build compared with
the defaults on platforms such as AIX... e.g. it doesn't test for
performance-related switches such as INTERNAL_QSORT. If you have run
configure, there's some file you need to blow away to get back to a
non-autoconf world... is it config.mak.autogen?
Despite that, your problem with --without-tcltk falling back to wish,
but not falling back if that isn't installed does look like something
we should fix, as per Peff's mail.
> I can't tell if make test is happy or not. The output looks like its happy
> but the exit code is 2.
>
> Below is my "configure" script if anyone is interested.
>
> #!/usr/bin/env bash
>
> export CONFIG_SHELL=/usr/local/bin/bash
> export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
> export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
> export CC=gcc
> echo CONFIG_SHELL set to ${CONFIG_SHELL}
>
> ${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
>
> #
> # Note that to install you need to do:
> # make INSTALL=ginstall install
> # to use GNU's install program
I build with SHELL_PATH={path}/bash as well. If I don't, the test
suite exits after t0000-basic.sh with an unexpected error despite
passing all the tests.
gmake -C t/ all
gmake[1]: Entering directory `/usr/local/src/gitbuild/t'
rm -f -r test-results
gmake aggregate-results-and-cleanup
gmake[2]: Entering directory `/usr/local/src/gitbuild/t'
*** t0000-basic.sh ***
* passed all remaining 40 test(s)
FATAL: Unexpected exit with code 0
gmake[2]: *** [t0000-basic.sh] Error 1
gmake[2]: Leaving directory `/usr/local/src/gitbuild/t'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/usr/local/src/gitbuild/t'
gmake: *** [test] Error 2
Is that what you're seeing? There's many more test scripts than that 8-)
With GIT_SKIP_TESTS='t3900 t3901 t5100.[12] t8005' (to omit some cases
not handled by the version of iconv I have access to on all the AIX
boxes I deploy to) the test suit runs to completion on AIX 5.3 for me.
BTW Are you running AIX's make or GNU make?
Mike
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Johannes Sixt @ 2009-01-27 10:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
Jeff King schrieb:
> JSixt, there are some tweaks to the Windows code to report back the exec
> error. They look obviously correct to me, but I have no box to test
> (even compile test) them on.
Generally, I like this series, in particular since it does not degrade
performance on Windows ;)
But the following is needed in addition.
- Note that run_command returns the negated exit code, therefore, we
must negate it again in the call to exit(). Without this t6030 failed.
(And negative exit codes causes grief on Windows because bash for some
reason does not recognize that as failure.)
- The close() calls can overwrite errno. And since fork() should not
(cannot?) fail with ENOENT, it's safe to remove the #ifdef __MINGW32__.
-- Hannes
diff --git a/git.c b/git.c
index 79a836c..35635d1 100644
--- a/git.c
+++ b/git.c
@@ -414,7 +414,7 @@ static void execv_dashed_external
*/
status = run_command_v_opt(argv, 0);
if (status != -ERR_RUN_COMMAND_EXEC)
- exit(status);
+ exit(-status);
errno = ENOENT; /* as if we called execvp */
argv[0] = tmp;
diff --git a/run-command.c b/run-command.c
index 2437798..b05c734 100644
--- a/run-command.c
+++ b/run-command.c
@@ -187,27 +187,24 @@ int start_command
if (s2 >= 0)
dup2(s2, 2), close(s2);
#endif
if (cmd->pid < 0) {
+ int err = errno;
if (need_in)
close_pair(fdin);
else if (cmd->in)
close(cmd->in);
if (need_out)
close_pair(fdout);
else if (cmd->out)
close(cmd->out);
if (need_err)
close_pair(fderr);
-#ifndef __MINGW32__
- return -ERR_RUN_COMMAND_FORK;
-#else
- return errno == ENOENT ?
+ return err == ENOENT ?
-ERR_RUN_COMMAND_EXEC :
-ERR_RUN_COMMAND_FORK;
-#endif
}
if (need_in)
close(fdin[0]);
else if (cmd->in)
^ permalink raw reply related
* Re: [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Mike Ralphson @ 2009-01-27 9:35 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <1233004637-15112-6-git-send-email-barvik@broadpark.no>
2009/1/26 Kjetil Barvik <barvik@broadpark.no>:
> Currently inside show_patch_diff() we have and fstat() call after an
> ok lstat() call. Since we before the call to fstat() have already
> test for the link case with S_ISLNK() the fstat() can be removed.
s/have and/have an/ ?
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 9:31 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20090127044838.GA735@coredump.intra.peff.net>
Hi,
On Mon, 26 Jan 2009, Jeff King wrote:
> On Mon, Jan 26, 2009 at 07:38:56PM -0800, Linus Torvalds wrote:
>
> > > ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> > > ==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> > > ==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
> > > ==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
> > > ==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
> > > ==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
> >
> > Looks entirely bogus.
> >
> > I suspect that valgrind for some reason doesn't see the writes made by
> > zlib as being initialization, possibly due to some incorrect valgrind
> > annotations on deflate(). We've just totally initialized that whole
> > buffer with deflate().
> >
> > It definitely does not look like a git bug, but a valgrind run issue.
>
> Yes, this is exactly the issue I ran into when doing the valgrind stuff
> a few months ago. I spent several hours looking carefully at the code
> and came to the same conclusion. Anything zlib touches needs to be
> manually suppressed for uninitialized writes (which I _thought_ was
> covered in the suppressions I sent out originally, but maybe they need
> to be tweaked for Dscho's system).
Indeed. I used the "..." wildcard to account for slight differences in
Git's code calling path.
Sorry for the noise,
Dscho
^ permalink raw reply
* Anyone have access to 64-bit Vista?
From: Geoffrey Lee @ 2009-01-27 9:30 UTC (permalink / raw)
To: git
I'm trying to develop for TortoiseGit on a 64-bit Vista SP1 system,
but I'm having trouble registering the shell extensions with explorer.
I'm hoping somebody else here who has access to 64-bit Vista can tell
me if TortoiseGit runs on their machine? I want to find out if this
problem is only affecting my machine.
http://code.google.com/p/tortoisegit/
-Geoffrey Lee
^ permalink raw reply
* Heads up: rebase -i -p will be made sane again
From: Johannes Schindelin @ 2009-01-27 9:29 UTC (permalink / raw)
To: Stephen Haberman, git
Dear list,
I am progressing to a point where I am almost comfortable to send the
patch series; I want to use the thing myself first, and I want to fix a
design bug.
As always, my code is public, but will be rebased frequently. You have
been warned.
BTW I am really sorry for the state I left the --preserve-merges code for
a long time. Originally, it was never meant to be used interactively, and
that shows sorely.
As for the design bug I want to fix: imagine this history:
------A
/ /
/ /
---- B
\ \
\ \
C-----D-----E = HEAD
A, C and D touch the same file, and A and D agree on the contents.
Now, rebase -p A does the following at the moment:
------A-----E' = HEAD
/ /
/ /
---- B
In other words, C is truly forgotten, and it is pretended that D never
happened, either. That is exactly what test case 2 in t3410 tests for
[*1*].
This is insane.
So after my rebase -i -p revamp, this will happen instead: in the
interactive version you will get the script
pick C
merge parents B' original D
pick E
In the non-interactive version -- or if you change nothing, in the
interactive version, too -- this will lead to a conflict while picking C.
As it should.
Ciao,
Dscho
[*1*] The code in t3410 was not really easy to read, even if there was an
explanation what it tried to do, but the test code was inconsitent,
sometimes tagging, sometimes not, sometimes committing with -a, sometimes
"git add"ing first, yet almost repetitive.
In my endeavor not only to understand it, and either fix my code or the
code in t3410, I refactored it so that others should have a much easier
time to understand what it actually does.
^ permalink raw reply
* Re: [Bug] rebase -i squashes submodule changes into unrelated commit
From: Junio C Hamano @ 2009-01-27 9:20 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <7vljsxyv58.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Attempting to rebase three-commit series (two regular changes, followed by
> one commit that changes what commit is bound for a submodule path) to
> squash the first two results in a failure; not just the first two commits
> squashed, but the change to the submodule is also included in the result.
>
> This failure causes the subsequent step to "pick" the change that actually
> changes the submodule to be applied, because there is no change left to be
> applied.
Sorry, an obvious typo is here: s/to be applied,/to fail,/;
^ permalink raw reply
* [Bug] rebase -i squashes submodule changes into unrelated commit
From: Junio C Hamano @ 2009-01-27 9:07 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
Attempting to rebase three-commit series (two regular changes, followed by
one commit that changes what commit is bound for a submodule path) to
squash the first two results in a failure; not just the first two commits
squashed, but the change to the submodule is also included in the result.
This failure causes the subsequent step to "pick" the change that actually
changes the submodule to be applied, because there is no change left to be
applied.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t3404-rebase-interactive.sh | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git c/t/t3404-rebase-interactive.sh w/t/t3404-rebase-interactive.sh
index 2cc8e7a..6ffb9ad 100755
--- c/t/t3404-rebase-interactive.sh
+++ w/t/t3404-rebase-interactive.sh
@@ -462,4 +462,30 @@ test_expect_success 'do "noop" when there is nothing to cherry-pick' '
'
+test_expect_success 'submodule rebase setup' '
+ git checkout A &&
+ mkdir sub &&
+ (
+ cd sub && git init && >elif &&
+ git add elif && git commit -m "submodule initial"
+ ) &&
+ echo 1 >file1 &&
+ git add file1 sub
+ test_tick &&
+ git commit -m "One" &&
+ echo 2 >file1 &&
+ test_tick &&
+ git commit -a -m "Two" &&
+ (
+ cd sub && echo 3 >elif &&
+ git commit -a -m "submodule second"
+ ) &&
+ test_tick &&
+ git commit -a -m "Three changes submodule"
+'
+
+test_expect_failure 'submodule rebase -i' '
+ FAKE_LINES="1 squash 2 3" git rebase -i A
+'
+
test_done
^ permalink raw reply related
* Re: [topgit] shared topic branch
From: Fabien Thomas @ 2009-01-27 7:23 UTC (permalink / raw)
To: git; +Cc: martin f krafft
In-Reply-To: <20090126120049.GA9676@lapse.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
>> I'm testing topgit 0.5 in a shared env. (multiple user working on
>> same
>> patch).
>
> Sorry for the late reply!
Thanks to reply :)
>
>
>> My problem is that when i want to push my local work i'm doing
>> "git push" that will force update the remote branch. The problem
>> is that each time master is not up to date i will push my entire
>> master or topic branch to the remote.
>
> I do not understand what you mean. Could yo please try to give us
> more detail? git push is intended to push all local changes to the
> remote, so I don't understand what your problem is.
I'm new to topgit and to git so maybe there is something i've
misunderstood:
on the git side:
the + will overwrite all remote location branche named with that
pattern ?
on topgit:
i'm just doing patches on two computer (home+work) and i'm pushing on
a central repo to "backup/share my changes"
if i'm not up to date and i start a push with the "+" will overwrite
the central repo with my local branch. (overwrite of my central repo
master branch and my topics)
to "solve" my problem i've replaced the remote section with this:
[remote "origin"]
url = ssh://git@xxx.com
fetch = refs/heads/*:refs/remotes/origin/*
fetch = refs/top-bases/*:refs/remotes/origin/top-bases/*
push = refs/top-bases/*:refs/top-bases/*
push = refs/heads/topic/*:refs/heads/topic/*
is it more clear?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1860 bytes --]
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Peter Krefting @ 2009-01-27 7:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: Mike Hommey, Jakub Narebski, Dill, Sverre Rabbelier
In-Reply-To: <bd6139dc0901261130ic64f767gddc960ebe3dfecf2@mail.gmail.com>
Sverre Rabbelier:
> Perhaps the basics can be translated at least, the documents that do
> not require much change because they represent stable concepts?
I usually start out translating the program output, then manual pages,
and then, time permitting, documentation.
Git is a bit special in that regard since "--help" gets hardwired to
display the manual page, so one can't just translate the help screen.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH v2] contrib git-resurrect: find traces of a branch name and resurrect it
From: Junio C Hamano @ 2009-01-27 6:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: Boyd Stephen Smith Jr., git, Johannes Schindelin
In-Reply-To: <1232973657-31444-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Add a tool 'git-resurrect.sh <branch>' that tries to find traces of
> the <branch> in the HEAD reflog and, optionally, all merge commits in
> the repository. It can then resurrect the branch, pointing it at the
> most recent of all candidate commits found.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> Fixed the -h to upper-case in the short options summaries, and removed
> a stray 'q' in the default assignment of new_name.
I hate to paint bikeshed, but -H "try-hard" looks somewhat unusual doesn't
it? It sounds more like --all (find from all possible sources).
> +. git-sh-setup
> +cd_to_toplevel
Why?
> +search_reflog () {
> + sed -n 's~^\([^ ]*\) .*\tcheckout: moving from '"$1"' .*~\1~p' \
> + < .git/logs/HEAD
> +}
Once you used ". git-sh-setup", use "$GIT_DIR/logs/HEAD". That way, you
can work in a bare repository (and you do not have to cd_to_toplevel,
either, I think).
Oh, don't forget to skip this step if the reflog does not exist.
> +search_reflog_merges () {
> + sed -n 's~^[^ ]* \([^ ]*\) .*\tmerge '"$1"':~\1~p' \
> + < .git/logs/HEAD
> +}
The two commits both point at the HEAD that merges the other branch into,
so this finds a merge commit that has the tip of target branch as its
second parent. Is that really what you want?
> +search_merges () {
> + git rev-list --pretty=tformat:"%h %p:%s" --all |
> + grep "Merge branch.*'$branch'.*into" |
"git merge tr/topic~4" can say "Merge branch 'tr/topic' (early part)".
Also merge into 'master' won't have "into ...".
> + while read sha rest; do
> + parents="$(echo "$rest" | cut -d: -f1)"
> + case "$parents" in
> + *' '*' '*)
> + warn "$branch took part in octopus merge $sha"
> + warn "check manually!"
> + ;;
> + *' '*)
> + echo "$parents" | cut -d' ' -f2
> + ;;
> + esac
> + done
Reading everything down to the root commit sounds like fun. rev-list
gives you the output from newer to older so you may want to break out once
you have found enough candidates.
Anyway, if I were doing this script, I'd write this part like this without
a shell loop:
_x40="[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]"
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
git rev-list --all --grep="Merge branch '$1'" \
--pretty=tformat:"%H %P %s" |
sed -ne "s/^$_x40 $_x40 \($_x40\) Merge .*/\1/p"
^ permalink raw reply
* [RFC/PATCH 3/3] git: use run_command to execute dashed externals
From: Jeff King @ 2009-01-27 6:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
We used to simply try calling execvp(); if it succeeded,
then we were done and the new program was running. If it
didn't, then we knew that it wasn't a valid command.
Unfortunately, this interacted badly with the new pager
handling. Now that git remains the parent process and the
pager is spawned, git has to hang around until the pager is
finished. We install an atexit handler to do this, but that
handler never gets called if we successfully run execvp.
You could see this behavior by running any dashed external
using a pager (e.g., "git -p stash list"). The command
finishes running, but the pager is still going. In the case
of less, it then gets an error reading from the terminal and
exits, potentially leaving the terminal in a broken state
(and not showing the output).
This patch just uses run_command to try running the
dashed external. The parent git process then waits for the
external process to complete and then handles the pager
cleanup as it would for an internal command.
Signed-off-by: Jeff King <peff@peff.net>
---
git.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 45e493d..79a836c 100644
--- a/git.c
+++ b/git.c
@@ -2,6 +2,7 @@
#include "exec_cmd.h"
#include "cache.h"
#include "quote.h"
+#include "run-command.h"
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
@@ -392,6 +393,7 @@ static void execv_dashed_external(const char **argv)
{
struct strbuf cmd = STRBUF_INIT;
const char *tmp;
+ int status;
strbuf_addf(&cmd, "git-%s", argv[0]);
@@ -406,10 +408,14 @@ static void execv_dashed_external(const char **argv)
trace_argv_printf(argv, "trace: exec:");
- /* execvp() can only ever return if it fails */
- execvp(cmd.buf, (char **)argv);
-
- trace_printf("trace: exec failed: %s\n", strerror(errno));
+ /*
+ * if we fail because the command is not found, it is
+ * OK to return. Otherwise, we just pass along the status code.
+ */
+ status = run_command_v_opt(argv, 0);
+ if (status != -ERR_RUN_COMMAND_EXEC)
+ exit(status);
+ errno = ENOENT; /* as if we called execvp */
argv[0] = tmp;
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [RFC/PATCH 2/3] run_command: handle missing command errors more gracefully
From: Jeff King @ 2009-01-27 6:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
When run_command was asked to run a non-existant command,
its behavior varied depending on the platform:
- on POSIX systems, we would fork, and then after the
execvp call failed, we could call die(), which prints a
message to stderr and exits with code 128.
- on Windows, we do a PATH lookup, realize the program
isn't there, and then return ERR_RUN_COMMAND_FORK
The goal of this patch is to make it clear to callers that
the specific error was a missing command. To do this, we
will return the error code ERR_RUN_COMMAND_EXEC, which is
already defined in run-command.h, checked for in several
places, but never actually gets set.
The new behavior is:
- on POSIX systems, we exit the forked process with code
127 (the same as the shell uses to report missing
commands). The parent process recognizes this code and
returns an EXEC error. The stderr message is silenced,
since the caller may be speculatively trying to run a
command. Instead, we use trace_printf so that somebody
interested in debugging can see the error that occured.
- on Windows, we check errno, which is already set
correctly by mingw_spawnvpe, and report an EXEC error
instead of a FORK error
Thus it is safe to speculatively run a command:
int r = run_command_v_opt(argv, 0);
if (r == -ERR_RUN_COMMAND_EXEC)
/* oops, it wasn't found; try something else */
else
/* we failed for some other reason, error is in r */
Signed-off-by: Jeff King <peff@peff.net>
---
run-command.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index db9ce59..2437798 100644
--- a/run-command.c
+++ b/run-command.c
@@ -118,7 +118,9 @@ int start_command(struct child_process *cmd)
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
- die("exec %s failed.", cmd->argv[0]);
+ trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
+ strerror(errno));
+ exit(127);
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
@@ -197,7 +199,13 @@ int start_command(struct child_process *cmd)
close(cmd->out);
if (need_err)
close_pair(fderr);
+#ifndef __MINGW32__
return -ERR_RUN_COMMAND_FORK;
+#else
+ return errno == ENOENT ?
+ -ERR_RUN_COMMAND_EXEC :
+ -ERR_RUN_COMMAND_FORK;
+#endif
}
if (need_in)
@@ -236,9 +244,14 @@ static int wait_or_whine(pid_t pid)
if (!WIFEXITED(status))
return -ERR_RUN_COMMAND_WAITPID_NOEXIT;
code = WEXITSTATUS(status);
- if (code)
+ switch (code) {
+ case 127:
+ return -ERR_RUN_COMMAND_EXEC;
+ case 0:
+ return 0;
+ default:
return -code;
- return 0;
+ }
}
}
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [RFC/PATCH 1/3] git: s/run_command/run_builtin/
From: Jeff King @ 2009-01-27 6:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
There is a static function called run_command which
conflicts with the library function in run-command.c; this
isn't a problem currently, but prevents including
run-command.h in git.c.
This patch just renames the static function to something
more specific and non-conflicting.
Signed-off-by: Jeff King <peff@peff.net>
---
git.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index ecc8fad..45e493d 100644
--- a/git.c
+++ b/git.c
@@ -219,7 +219,7 @@ struct cmd_struct {
int option;
};
-static int run_command(struct cmd_struct *p, int argc, const char **argv)
+static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
{
int status;
struct stat st;
@@ -384,7 +384,7 @@ static void handle_internal_command(int argc, const char **argv)
struct cmd_struct *p = commands+i;
if (strcmp(p->cmd, cmd))
continue;
- exit(run_command(p, argc, argv));
+ exit(run_builtin(p, argc, argv));
}
}
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Jeff King @ 2009-01-27 6:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0901081601240.30769@pacific.mpi-cbg.de>
On Thu, Jan 08, 2009 at 04:07:08PM +0100, Johannes Schindelin wrote:
> Just try this with a submodule that has more changes than fit on a screen:
>
> $ git -p submodule summary
>
> In my tests, it consistently fscks up my console. I wonder if this is
> related to ea27a18(spawn pager via run_command interface).
OK, here is a patch series that fixes the problem:
1/3: git: s/run_command/run_builtin/
2/3: run_command: handle missing command errors more gracefully
3/3: git: use run_command to execute dashed externals
1 is a cleanup, 2 is infrastructure support, and 3 is the actual fix.
There are two potential downsides to the fix:
1. There is an extra fork and a parent process sitting in memory for
dashed externals. This is pretty necessary to any fix, since
something has to wait to do pager cleanup, and we can't rely on the
child to do so.
2. A failed attempt to execute a dashed external results in an extra
fork. For builtins, this has no impact, since they take precedence.
For aliases, though, it means we will do an extra fork before
realizing that there is no dashed external and trying the alias.
We can fix '2' by actually doing the PATH lookup ourselves, and only
calling run_command if we know we have a match. We can also reduce the
impact of both by only doing this multi-process magic if we have spawned
a pager; then only a small subset of invocations needs to pay for it.
I chose not to do the second optimization because it makes the code more
complex and inconsistent (we now have two different ways of doing the
same thing, depending on a seemingly unrelated setting) and fragile
(the pager might not be the only atexit handler installed).
The first (doing PATH lookup ourselves) might make sense, though.
JSixt, there are some tweaks to the Windows code to report back the exec
error. They look obviously correct to me, but I have no box to test
(even compile test) them on.
-Peff
^ permalink raw reply
* Re: [PATCH 08/10] run test suite without dashed git-commands in PATH
From: Matthew Ogilvie @ 2009-01-27 6:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901261201470.14855@racer>
On Mon, Jan 26, 2009 at 12:06:08PM +0100, Johannes Schindelin wrote:
> So maybe I was wrong to assume that this is cvsserver specific, but then,
> you made that mistake rather easy to make.
Yes, in retrospect I probably should have split off patches 6, 7,
8, and maybe 5 (5-7 fix issues that patch 8 exposes in the test suite)
into a separate patch series. When or if a v2 is needed, should
I split them off then?
> > 4. The test-bin-wrapper.sh script does not actually need to set
> > environment variables (GIT_EXEC_DIT and templates) for purposes
> > of this patch. But my thought was that in this form you could
> > run things straight out of the test-bin directory to manually try
> > out new code without needing to actually install a build or mess
> > with the environment variables yourself. It could also be
> > extended to handle other global wrapper needs relatively easily,
> > such as valgrind.
>
> Umm.
>
> You missed the valgrind patch series.
Actually, I'm (poorly) alluding to some comments in the original patch
8 email, where I pointed out an expected conflict with the valgrind
patches. To briefly recap, there are at least 3 possible strategies
of resolving such a conflict, and I'm not sure which makes the most
sense: Keep valgrind design, and extend it with limited bindir
support. Keep limited bindir design and extend it with valgrind
support. Or keep both, and have the runtime setup logic make
them mutually exclusive.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox