* Re: pread() over NFS (again) [1.5.5.4]
From: Christian Holtje @ 2008-06-26 21:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20080626210556.GZ11793@spearce.org>
On Jun 26, 2008, at 5:05 PM, Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>> Christian Holtje <docwhat@gmail.com> wrote:
>>>> I have read all the threads on git having trouble with pread()
>>>> and I
>>>> didn't see anything to help.
>>> ...
>>>> Receiving objects: 100% (253/253), 5.27 MiB | 9136 KiB/s, done.
>>>> fatal: cannot pread pack file: No such file or directory
>>>> fatal: index-pack failed
>>>>
>>>> The end of the strace looks like so:
>>>> pread(3, "", 205, 1373) = 0
>>>> write(2, "fatal: cannot pread pack file: N"..., 57) = 57
>>>
>>> Hmmph. So pread for a length of 205 can return 0 on NFS? Is this
>>> a transient error? If so, perhaps a patch like this might help:
> ...
>>> The file shouldn't be short unless someone truncated it, or there
>>> is a bug in index-pack. Neither is very likely, but I don't think
>>> we would want to retry pread'ing the same block forever.
>>
>> I don't think we would want to retry even once. Return value of 0
>> from
>> pread is defined to be an EOF, isn't it?
>
> Indeed, it is defined to be EOF, but EOF here makes no sense.
>
> We have a file position we saw once before as the start of a delta.
> We wrote it down to disk. We want to go back and open it up, as
> we have the base decompressed and in memory and need to compute
> the SHA-1 of the object that resides at this offset.
>
> And *wham* we get an EOF. Where there should be data. Where we
> know there is data.
>
> I'm open to the idea that index-pack has a bug, but I doubt it.
> We shovel hundreds of megabytes through that on a daily basis
> across all of the git users, and nobody ever sees it crash out
> with an EOF in the middle of an object it knows to be present.
> Except poor Christian on NFS.
>
> Actually, I think the last time someone reported something like this
> in Git it turned out to be an NFS kernel bug. I didn't quote it
> in my reply to him, but I think he did say this was a linux client,
> linux server.
I did see the threads that talked about NFS, but I couldn't find any
matching messages in the linux kernel mailing list. If someone can
give me a pointer to where this picked up on other mailing lists (say,
via a URL) then I'll take that back to IT as a reason to upgrade.
Would it be a bug in the client or server? I'd assume client...
The other NFS/pread() email thread was also a client of linux 2.6.9....
Ciao!
^ permalink raw reply
* Re: [PATCH 1/2] Introduce leaky().
From: Pierre Habouzit @ 2008-06-26 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq1oqbjg.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
On Thu, Jun 26, 2008 at 06:46:43PM +0000, Junio C Hamano wrote:
> The user would also need to worry about not freeing the original
> allocation pointer when something is realloc(3)ed, which means either
> finding the last realloc(3) of the object (that is logically the same, but
> just being extended) and mark the pointer as leaky() after that realloc,
> or unregister the original pointer from leaks before calling realloc and
> register what comes back. It will easily get messy.
Hmm indeed, maybe it isn't such a good idea then.
> By the way, the series queued in your repository still has "s/pring/print/"
> typo in 4/7 and "argv not NULL terminated" comment in 6/7.
I'll fix that and pushed again, without the leaky() series dependency
(I've put in a comment that I'm aware that it's a leak), and with the
two fixes you mention done.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: pread() over NFS (again) [1.5.5.4]
From: Shawn O. Pearce @ 2008-06-26 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Holtje, git
In-Reply-To: <7vskuzq5ix.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Christian Holtje <docwhat@gmail.com> wrote:
> >> I have read all the threads on git having trouble with pread() and I
> >> didn't see anything to help.
> > ...
> >> Receiving objects: 100% (253/253), 5.27 MiB | 9136 KiB/s, done.
> >> fatal: cannot pread pack file: No such file or directory
> >> fatal: index-pack failed
> >>
> >> The end of the strace looks like so:
> >> pread(3, "", 205, 1373) = 0
> >> write(2, "fatal: cannot pread pack file: N"..., 57) = 57
> >
> > Hmmph. So pread for a length of 205 can return 0 on NFS? Is this
> > a transient error? If so, perhaps a patch like this might help:
...
> > The file shouldn't be short unless someone truncated it, or there
> > is a bug in index-pack. Neither is very likely, but I don't think
> > we would want to retry pread'ing the same block forever.
>
> I don't think we would want to retry even once. Return value of 0 from
> pread is defined to be an EOF, isn't it?
Indeed, it is defined to be EOF, but EOF here makes no sense.
We have a file position we saw once before as the start of a delta.
We wrote it down to disk. We want to go back and open it up, as
we have the base decompressed and in memory and need to compute
the SHA-1 of the object that resides at this offset.
And *wham* we get an EOF. Where there should be data. Where we
know there is data.
I'm open to the idea that index-pack has a bug, but I doubt it.
We shovel hundreds of megabytes through that on a daily basis
across all of the git users, and nobody ever sees it crash out
with an EOF in the middle of an object it knows to be present.
Except poor Christian on NFS.
Actually, I think the last time someone reported something like this
in Git it turned out to be an NFS kernel bug. I didn't quote it
in my reply to him, but I think he did say this was a linux client,
linux server.
--
Shawn.
^ permalink raw reply
* Re: commit 'git-send-email: add support for TLS via Net::SMTP::SSL' causes warnings
From: Thomas Rast @ 2008-06-26 21:03 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <200806262248.02866.trast@student.ethz.ch>
I wrote:
>
> and thanks for the fix
Well, actually at second glance your fix is wrong. Putting it in
read_config() means it will be executed the first time around already,
when we read the identity's settings. So with the patch,
$smtp_encryption is set to '' during identity parsing, and any value
set in the global [sendemail] section never takes effect.
Let's do the following instead. Sorry for all the noise.
-- 8< --
git-send-email: prevent undefined variable warnings if no encryption is set
With the previous patch, not configuring any encryption (either on or
off) would leave $smtp_encryption undefined. We simply set it to the
empty string in that case.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-send-email.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 7630720..edb12c2 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -313,6 +313,9 @@ foreach my $setting (values %config_bool_settings) {
${$setting->[0]} = $setting->[1] unless (defined (${$setting->[0]}));
}
+# 'default' encryption is none -- this only prevents a warning
+$smtp_encryption = '' unless (defined $smtp_encryption);
+
# Set CC suppressions
my(%suppress_cc);
if (@suppress_cc) {
--
1.5.6.1.187.g35a8
^ permalink raw reply related
* Re: pread() over NFS (again) [1.5.5.4]
From: Junio C Hamano @ 2008-06-26 20:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Christian Holtje, git
In-Reply-To: <20080626204606.GX11793@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Christian Holtje <docwhat@gmail.com> wrote:
>> I have read all the threads on git having trouble with pread() and I
>> didn't see anything to help.
> ...
>> Receiving objects: 100% (253/253), 5.27 MiB | 9136 KiB/s, done.
>> fatal: cannot pread pack file: No such file or directory
>> fatal: index-pack failed
>>
>> The end of the strace looks like so:
>> pread(3, "", 205, 1373) = 0
>> write(2, "fatal: cannot pread pack file: N"..., 57) = 57
>
> Hmmph. So pread for a length of 205 can return 0 on NFS? Is this
> a transient error? If so, perhaps a patch like this might help:
>
> diff --git a/index-pack.c b/index-pack.c
> index 5ac91ba..737f757 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -309,14 +309,19 @@ static void *get_data_from_pack(struct object_entry *obj)
> unsigned char *src, *data;
> z_stream stream;
> int st;
> + int attempts = 0;
>
> src = xmalloc(len);
> data = src;
> do {
> ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
> - if (n <= 0)
> + if (n <= 0) {
> + if (n == 0 && ++attempts < 10)
> + continue;
> die("cannot pread pack file: %s", strerror(errno));
> + }
> rdy += n;
> + attempts = 0;
> } while (rdy < len);
> data = xmalloc(obj->size);
> memset(&stream, 0, sizeof(stream));
>
>
> The file shouldn't be short unless someone truncated it, or there
> is a bug in index-pack. Neither is very likely, but I don't think
> we would want to retry pread'ing the same block forever.
I don't think we would want to retry even once. Return value of 0 from
pread is defined to be an EOF, isn't it?
^ permalink raw reply
* Re: commit 'git-send-email: add support for TLS via Net::SMTP::SSL' causes warnings
From: Thomas Rast @ 2008-06-26 20:48 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List
In-Reply-To: <DF091369-1771-4405-8705-BDBC59C7E48A@sb.org>
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
Kevin Ballard wrote:
> Your recent commit to next (f6bebd1) causes warnings when no form of
> encryption is specified. Specifically, lines 755 and 765 reference
> $smtp_encryption, but when no encryption is given at all this variable
> is undefined.
Sorry for the oversight on my part, and thanks for the fix! :-)
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: pread() over NFS (again) [1.5.5.4]
From: Shawn O. Pearce @ 2008-06-26 20:46 UTC (permalink / raw)
To: Christian Holtje; +Cc: git
In-Reply-To: <6F25C1B4-85DE-4559-9471-BCD453FEB174@gmail.com>
Christian Holtje <docwhat@gmail.com> wrote:
> I have read all the threads on git having trouble with pread() and I
> didn't see anything to help.
...
> Receiving objects: 100% (253/253), 5.27 MiB | 9136 KiB/s, done.
> fatal: cannot pread pack file: No such file or directory
> fatal: index-pack failed
>
> The end of the strace looks like so:
> pread(3, "", 205, 1373) = 0
> write(2, "fatal: cannot pread pack file: N"..., 57) = 57
Hmmph. So pread for a length of 205 can return 0 on NFS? Is this
a transient error? If so, perhaps a patch like this might help:
diff --git a/index-pack.c b/index-pack.c
index 5ac91ba..737f757 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -309,14 +309,19 @@ static void *get_data_from_pack(struct object_entry *obj)
unsigned char *src, *data;
z_stream stream;
int st;
+ int attempts = 0;
src = xmalloc(len);
data = src;
do {
ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
- if (n <= 0)
+ if (n <= 0) {
+ if (n == 0 && ++attempts < 10)
+ continue;
die("cannot pread pack file: %s", strerror(errno));
+ }
rdy += n;
+ attempts = 0;
} while (rdy < len);
data = xmalloc(obj->size);
memset(&stream, 0, sizeof(stream));
The file shouldn't be short unless someone truncated it, or there
is a bug in index-pack. Neither is very likely, but I don't think
we would want to retry pread'ing the same block forever.
--
Shawn.
^ permalink raw reply related
* bug related to branches using / in name
From: Simon Holm Thøgersen @ 2008-06-26 19:42 UTC (permalink / raw)
To: git; +Cc: Ingo Molnar
Hi git community
I have a bug report I think is most easily explained by a list of
commands that illustrates the bug.
cd /tmp
mkdir git-bug
cd git-bug
git init
touch foo
git add foo
git commit -a -m '...'
git branch sched
git clone file:///tmp/git-bug /tmp/git-bug-clone
git branch -d sched
git branch sched/urgent
git branch sched/devel
cd /tmp/git-bug-clone
git pull
The last command does not succeed, but produces the following output
error: unable to resolve reference refs/remotes/origin/sched/devel: Not
a directory
>From file:///tmp/git-bug
* [new branch] sched/devel -> origin/sched/devel
error: unable to resolve reference refs/remotes/origin/sched/urgent: Not
a directory
* [new branch] sched/urgent -> origin/sched/urgent
I can work around it by
rm /tmp/git-bug-clone/.git/{,logs/}refs/remotes/origin/sched
but git should take care of this automatically, right?
I'm on git version 1.5.6.
Simon Holm Thøgersen
^ permalink raw reply
* [PATCH] git-send-email: Fix warning triggered by f6bebd12 when no encryption is set
From: Kevin Ballard @ 2008-06-26 20:36 UTC (permalink / raw)
To: git; +Cc: Kevin Ballard, Junio C Hamano, trast
In-Reply-To: <DF091369-1771-4405-8705-BDBC59C7E48A@sb.org>
---
git-send-email.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 60a6551..b93cd40 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -299,6 +299,8 @@ sub read_config {
$smtp_encryption = $enc;
} elsif (Git::config_bool(@repo, "$prefix.smtpssl")) {
$smtp_encryption = 'ssl';
+ } else {
+ $smtp_encryption = '';
}
}
}
--
1.5.6.1.180.g7b731
^ permalink raw reply related
* [PATCH] diff --check: do not discard error status upon seeing a good line
From: Junio C Hamano @ 2008-06-26 20:22 UTC (permalink / raw)
To: git; +Cc: Wincent Colaiuta
"git diff --check" should return non-zero when there was any whitespace
errors but the code only paid attention to the error status of the last
new line in the patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* c1795bb (Unify whitespace checking, 2007-12-13) broke this part of the
code.
diff.c | 8 +++++---
t/t4017-diff-retval.sh | 8 ++++++++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 5262490..f281c5b 100644
--- a/diff.c
+++ b/diff.c
@@ -1150,12 +1150,14 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
char *err;
if (line[0] == '+') {
+ unsigned bad;
data->lineno++;
- data->status = check_and_emit_line(line + 1, len - 1,
+ bad = check_and_emit_line(line + 1, len - 1,
data->ws_rule, NULL, NULL, NULL, NULL);
- if (!data->status)
+ if (!bad)
return;
- err = whitespace_error_string(data->status);
+ data->status |= bad;
+ err = whitespace_error_string(bad);
fprintf(data->file, "%s:%d: %s.\n", data->filename, data->lineno, err);
free(err);
emit_line(data->file, set, reset, line, 1);
diff --git a/t/t4017-diff-retval.sh b/t/t4017-diff-retval.sh
index dc0b712..0d0fb87 100755
--- a/t/t4017-diff-retval.sh
+++ b/t/t4017-diff-retval.sh
@@ -105,4 +105,12 @@ test_expect_success '--check with --no-pager returns 2 for dirty difference' '
'
+
+test_expect_success 'check should test not just the last line' '
+ echo "" >>a &&
+ git --no-pager diff --check
+ test $? = 2
+
+'
+
test_done
--
1.5.6.1.78.gde8d9
^ permalink raw reply related
* commit 'git-send-email: add support for TLS via Net::SMTP::SSL' causes warnings
From: Kevin Ballard @ 2008-06-26 20:19 UTC (permalink / raw)
To: trast; +Cc: Git Mailing List
Your recent commit to next (f6bebd1) causes warnings when no form of
encryption is specified. Specifically, lines 755 and 765 reference
$smtp_encryption, but when no encryption is given at all this variable
is undefined.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: [PATCH] git.el: Don't reset HEAD in git-amend-file.
From: Nikolaj Schumacher @ 2008-06-26 20:17 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87tzfg7gd5.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> wrote:
> Nikolaj Schumacher <n_schumacher@web.de> writes:
>
>> The current implementation of git-amend-file is a little dangerous.
>> While git --amend is atomic, git-amend-file is not.
>>
>> If the user calls it, but doesn't go through with the commit (due to
>> error or choice), git --reset HEAD^ has been called anyway.
>
> That's a feature, even if it's a little dangerous. You have to reset
> HEAD to be able to properly do diffs, refreshes, etc. Maybe there should
> be an easier way to redo the commit if you change your mind, but the
> command would be much less useful without the reset.
You're right, it would be less powerful. But I still think it maps
better to what "git commit --amend" does, i.e. do a few changes and
amend them. No need for diffing against the old head, or even showing
it in the summary. For doing something more complicated I would reset
head, too. So, yes, the command should exist as well. But I'm not
so sure about the name...
As an aside, the current method doesn't work on the initial commit.
regards,
Nikolaj Schumacher
^ permalink raw reply
* Re: [PATCH] Add 'git-p4.allowSubmit' to git-p4
From: Junio C Hamano @ 2008-06-26 19:10 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Jing Xue, git
In-Reply-To: <200806262042.13121.simon@lst.de>
Thanks, both.
^ permalink raw reply
* Re: exit status 141 from git-svn
From: Frederik Hohlfeld @ 2008-06-26 19:07 UTC (permalink / raw)
To: git
In-Reply-To: <g3tlpu$oe9$1@ger.gmane.org>
Michael J Gruber <michaeljgruber+gmane <at> fastmail.fm> writes:
> That seems to be the first piece of information you're giving regarding
> your environment and setup. Giving more may result in getting more
> answers. (I grepped for 141 in the source after your first posting)
> Maybe you can cut'n'paste the actual output of git svn fetch? What's the
> command line you're using, where's the svn repo?
Sorry, but I don't see any interesting piece of information in the output. I've
just assumed that exit status 141 had a well-defined meaning, different from
140, 15 and 999.
The subversion repo is company-internal and cannot be accessed from the outside.
The output (with modified strings to mask out the file names) is:
> git svn fetch
M a/b/c/d
M a/b/c/d
M a/b/c/d
M a/b/c/d
M a/b/c/d
M a/b/c/d
M a/b/c/d
M a/b/c/d
M a/b/c/d
r4934 = abcdefghi[...]jklmnopq (trunk)
Nothing more. I haven't found a verbose switch for "fetch", either.
Thanks for reading
Frederik Hohlfeld
^ permalink raw reply
* Re: git-svn branches creation question
From: Pascal Obry @ 2008-06-26 19:05 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing-List
In-Reply-To: <32541b130806260908m7ca2060bub071da52aa7a33ce@mail.gmail.com>
Avery,
> And creating branches in svn is a single command, even if you don't
> have an svn checkout:
>
> svn cp $SVN/trunk $SVN/branches/whatever
That's what I'm doing as I said in my message.
> So it seems unnecessary to duplicate this feature in git.
Well it would be quite handy to work on Git directly (eventually
off-line) and doing the final "git svn dcommit" to update the subversion
repository and creating the branches if necessary.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH 1/2] Introduce leaky().
From: Junio C Hamano @ 2008-06-26 18:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1214338474-16822-2-git-send-email-madcoder@debian.org>
I looked at the patch (and your updated parseopt series that depends on
this that is queued at madism.org) again, but I have to say I do not like
it, not because I do not want leaks, nor because I do not want explicit
markings. The issue of helping valgrind sessions is worth addressing.
However.
First of all, it is unclear what the semantics of leaky() is. Do you want
to mark all things that will be unreacheable from anywhere in the program
at the end, or do you want to mark all things that we have obtained from
malloc(3) and friends but have not free(3)ed? Without a clear semantics
to use as the guiding principle, it would be hard for people to use this
macro properly to help debugging leaks.
Specifically, how would you envision to handle allocations of objects that
will be reachable from object.c::obj_hash at the program end? We do not
have to (and we should not) mark them using the former semantics, but we
should with the latter semantics.
The user would also need to worry about not freeing the original
allocation pointer when something is realloc(3)ed, which means either
finding the last realloc(3) of the object (that is logically the same, but
just being extended) and mark the pointer as leaky() after that realloc,
or unregister the original pointer from leaks before calling realloc and
register what comes back. It will easily get messy.
By the way, the series queued in your repository still has "s/pring/print/"
typo in 4/7 and "argv not NULL terminated" comment in 6/7.
^ permalink raw reply
* Re: Errors building git-1.5.6 from source on Mac OS X 10.4.11
From: Alex Riesen @ 2008-06-26 18:42 UTC (permalink / raw)
To: Ifejinelo Onyiah; +Cc: git
In-Reply-To: <2eb980790806260148p7713a546k641d96a956e9b0fa@mail.gmail.com>
2008/6/26 Ifejinelo Onyiah <nelo.onyiah@googlemail.com>:
> 2008/6/25 Alex Riesen <raa.lkml@gmail.com>:
>> Ifejinelo Onyiah, Wed, Jun 25, 2008 15:20:39 +0200:
>>>
>>> They all run fine but when I issue the make test command, it dies at
>>> the following:
>>>
>>> % make test
>>>
>>> ... TRUNCATED OUTPUT ...
>>>
>>> *** t2004-checkout-cache-temp.sh ***
>>> * FAIL 1: preparation
>>>
>>
>> If you don't mind helping the investigation a bit, could you please go
>> into the t/ directory and run
>>
>> bash -x t2004-checkout-cache-temp.sh -d -v -i
>>
>> and post the output here?
>
> I ran that command and it seemed to run with no problems. I have
> provided the output in 2 attached text files. I hope that is ok.
could you try the command _without_ "bash -x"?
Like this:
cd t
./t2004-checkout-cache-temp.sh -d -v -i
^ permalink raw reply
* Re: [PATCH] Add 'git-p4.allowSubmit' to git-p4
From: Simon Hausmann @ 2008-06-26 18:42 UTC (permalink / raw)
To: Jing Xue; +Cc: Junio C Hamano, git
In-Reply-To: <20080622181239.GA1855@jabba.hq.digizenstudio.com>
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
On Sunday 22 June 2008 20:12:39 Jing Xue wrote:
> I'm working with a perforce repo using git-p4. There are some config
> files which I need to change locally according to my environment. I'm
> using a 'local' git branch to park these changes. And I want to avoid
> accidentally checking them into p4 just by doing "git p4 submit"
> mindlessly without realizing which branch I'm actually on.
>
> This patch adds a new git config, 'git-p4.allowSubmit', which is a
> whitelist of branch names. "git p4 submit" will only allow submissions
> from local branches on the list. Useful for preventing inadvertently
> submitting from a strictly local branch.
>
> For backward compatibility, if this config is not set at all,
> submissions from all branches are allowed.
>
> Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
Acked-By: Simon Hausmann <simon@lst.de>
Simon
> contrib/fast-import/git-p4 | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index d8de9f6..87ca51e 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -687,6 +687,10 @@ class P4Submit(Command):
> else:
> return False
>
> + allowSubmit = gitConfig("git-p4.allowSubmit")
> + if len(allowSubmit) > 0 and not self.master in
> allowSubmit.split(","): + die("%s is not in git-p4.allowSubmit"
> % self.master)
> +
> [upstream, settings] = findUpstreamBranchPoint()
> self.depotPath = settings['depot-paths'][0]
> if len(self.origin) == 0:
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: how do I merge completely unrelated repositories ?
From: Kelly F. Hickel @ 2008-06-26 18:42 UTC (permalink / raw)
To: Oliver Kullmann, git
In-Reply-To: <20080626161941.GX20723@cs-wsok.swansea.ac.uk>
> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Oliver Kullmann
> Sent: Thursday, June 26, 2008 11:20 AM
> To: git@vger.kernel.org
> Subject: Re: how do I merge completely unrelated repositories ?
>
> Hi,
>
> since a similar question burdens my soul for quite some
> time, I would like to take the opportunity to extend
> the question a bit:
>
> I have around 10 CVS repositories, each with around 5 modules.
> This has developed over time, and now I want to combine them
> all into a single Git repository, with a new directory
> structure introduced.
>
> One possibility would be to convert these 50 CVS modules
> into git repositories, then for each of these git repositories
> introduce the new tree structure (that is, what is relevant
> for this part), move all files to their new location (via
> "git mv"), and finally pull everything in into the common
> repository.
>
> This is all fine, except of the inability to follow the history
> nicely (for example, via gitk I will only see the history
> from the point on where in those temporary git-repositories
> the files have been moved to their new place).
>
> To avoid this break in the history, it would be great if
> cvsimport could already move the files to the right place
> in the directory hierarchy, that is, if an additional
> parameter P could be given, the initial path, and files
> will be imported as P/file. Then I could import everything right away
> into
> the final git repository, without problems with clashes.
> I can't find something like that in the documentation.
>
> Is there perhaps some other possibility?
> It seems easiest to me to do this little bit of surgery
> at the time of the import, before git gets into his
> troubles with hash-values.
>
> thanks!
>
> Oliver
>
>
Oliver,
I wrote a little (314 line) perl script to blend multiple cvsps output
streams together before handing them to git-cvsimport, it seems to work
fine. It should (but I haven't tested it) even still allow the
incremental approach.
Not sure if I should just attach it here (it's not that big, but still),
but if you need/want a copy of "cvsps_blender.pl", just send me an email
and I'll send it out....
-Kelly
^ permalink raw reply
* Re: git svn clone a non-standard repository
From: John Locke @ 2008-06-26 18:39 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4863E01E.9050108@freelock.com>
Sorry to respond to my own post, but this section looks wrong:
John Locke wrote:
>
>
> Now the tricky part: I checked out a new "work" branch, and deleted
> everything in the working copy. Then, 4 steps out of the howto,
> adjusted to pull the particular branch from the current repository
> (instead of an outside one):
>
> git remote add -t dojo -f dojo ./
> git merge -s ours --no-commit dojo-trunk
> git read-tree --prefix=dojo/ -u dojo-trunk
> git commit -m "merge dojo into subdirectory"
... since I added the remotes as svn-remote sections directly in
git-config, I skipped that first line.
I'm going to write this all up on my blog when I get it working correctly...
Cheers,
--
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com
^ permalink raw reply
* [PATCH] test-lib.sh: show git init output when in verbose mode
From: Lea Wiemann @ 2008-06-26 18:35 UTC (permalink / raw)
To: git; +Cc: Lea Wiemann
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
---
I've had a hard-to-spot problem where git would crash due to a missing
library, and this solved it. :) IMHO there's no reason not to show the
git init output when --verbose is given.
(FD 3 and 4 are the streams where verbose output is redirected; in
non-verbose mode they're redirected to /dev/null.)
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a9fc621..8e2849b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -408,7 +408,7 @@ test_create_repo () {
repo="$1"
mkdir "$repo"
cd "$repo" || error "Cannot setup test environment"
- "$GIT_EXEC_PATH/git" init "--template=$GIT_EXEC_PATH/templates/blt/" >/dev/null 2>&1 ||
+ "$GIT_EXEC_PATH/git" init "--template=$GIT_EXEC_PATH/templates/blt/" >&3 2>&4 ||
error "cannot run git init -- have you built things yet?"
mv .git/hooks .git/hooks-disabled
cd "$owd"
--
1.5.6.1.184.g27776.dirty
^ permalink raw reply related
* Re: git svn clone a non-standard repository
From: John Locke @ 2008-06-26 18:29 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g3to0t$35n$1@ger.gmane.org>
Hi, Michael,
Michael J Gruber wrote:
>>
>> moduleA/trunk <- contains trunk development of moduleA
>> moduleA/tags <- empty
>> moduleA/branches <- empty
>> moduleB/trunk
>> moduleB/tags
>> moduleB/branches
>> moduleC/trunk
>> moduleC/tags
>> moduleC/branches
>> moduleD/trunk
>> moduleD/tags
>> moduleD/branches
>
> All of those module?/{tags,branches} are empty, right? I assume
> branches follow the pattern below for tags.
Yup.
>
>> moduleE/trunk <- I don't care about this one...
>> trunk/ <- contains ancient version, not actual trunk
>> tags/1.0.0/moduleA <- contains tagged version of moduleA
>> tags/1.0.0/moduleB <- contains tagged version of moduleB
>> tags/1.0.0/moduleC <- contains tagged version of moduleC
>> tags/1.0.0/moduleD <- contains tagged version of moduleD
>> tags/1.0.1/moduleA
>> tags/1.0.1/moduleB
>> ...
>>
>> So I'd like to set up a git repo that tracks this SVN repository, and
>> allows me to see:
>> moduleA/
>> moduleB/
>> moduleC/
>> moduleD/
>> ... in my checkout, whether I'm on trunk or a tag.
>
> So you want one git repo, reflecting the modules simply by different
> subdirs? I'm afraid that raises similar problems like those I asked
> about in my (yet unanswered) post
>
> http://permalink.gmane.org/gmane.comp.version-control.git/85861
I saw your post, and flagged it to see if anybody answered it, yes it
does seem similar.
>
>> I've started with "git svn clone http://path/to/svn -T moduleA/trunk
>> -t tags -b branches", and it's been sucking down branches for a
>> couple days
>
> This should give you all "modules" (as subsdirs) for all branches and
> tags already. svn branch "branchname" becomes git remote branch
> "branchname", svn tag "tagname" becomes git remote branch "tags/tagname".
> Note that your new git branch trunk will contain the contents of
> "moduleA" only.
That's exactly what happened.
>
>> now, still not done. Can I set up moduleB/moduleC/moduleD as
>> additional remotes in this same repository, and end up with the
>> desired result? Was thinking I would add additional svn sections to
>> .git/config, and then git svn fetch -- will this work, or is there a
>> better way?
>
> If I understand your layout (and "desires") correctly then trunk will
> be your only problem: you want to map "module?/trunk" to subdir
> "module?" of branch "trunk". This is more or less the problem I'm
> facing. Regular expressions (other than the ones for branches and
> tags) in git svn config would solve this.
>
I found in the docs a section on subtrees, and with a bit of trickery, I
think I'm getting what I want, though it's not simple to update. What
I've done so far is change .git/config to:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = http://svn.dojotoolkit.org/src
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
[svn-remote "dojo"]
url = http://svn.dojotoolkit.org/src
fetch = dojo/trunk:refs/remotes/dojo-trunk
[svn-remote "dijit"]
url = http://svn.dojotoolkit.org/src
fetch = dijit/trunk:refs/remotes/dijit-trunk
[svn-remote "dojox"]
url = http://svn.dojotoolkit.org/src
fetch = dojox/trunk:refs/remotes/dojox-trunk
[svn-remote "util"]
url = http://svn.dojotoolkit.org/src
fetch = util/trunk:refs/remotes/util-trunk
... dojo, dijit, dojox, and util correspond to moduleA-D in my previous
example. So I have "svn" for the branches, and separate SVN sections for
the trunk of each module. Then I used git svn fetch
[dojo|dijit|dojox|util] to suck down those as individual branches.
Now the tricky part: I checked out a new "work" branch, and deleted
everything in the working copy. Then, 4 steps out of the howto, adjusted
to pull the particular branch from the current repository (instead of an
outside one):
git remote add -t dojo -f dojo ./
git merge -s ours --no-commit dojo-trunk
git read-tree --prefix=dojo/ -u dojo-trunk
git commit -m "merge dojo into subdirectory"
... repeat for the other modules, and I ended up with my "work" branch
containing the full trunk for all 4 modules.
Now for tracking the original project. According to the howto, you use
this syntax to pull down changes:
git pull -s subtree Bproject master
... when I try git pull -s subtree ./ dojo, I get "Already up to date",
even though I know there are new changes. Still need to mess around with
git svn rebase, I guess, to get the updates working correctly.
Cheers,
--
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com
^ permalink raw reply
* Re: how do I merge completely unrelated repositories ?
From: Asheesh Laroia @ 2008-06-26 18:26 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20080626161941.GX20723@cs-wsok.swansea.ac.uk>
On Thu, 26 Jun 2008, Oliver Kullmann wrote:
> I have around 10 CVS repositories, each with around 5 modules. This has
> developed over time, and now I want to combine them all into a single
> Git repository, with a new directory structure introduced.
I had a similar desire with git-svn; instead, what I do is a
git-filter-branch that renames all the files in the repository.
man git-filter-branch gives you one way to do that; I basically
re-invented that due to not scrolling all the way to the bottom, and run
it every night on the git-svn repo since I want my everything-renamed repo
to be kept as an up-to-date mirror of the svn repo.
That's my idea for you.
-- Asheesh.
--
Fast, cheap, good: pick two.
^ permalink raw reply
* Re: how do I merge completely unrelated repositories ?
From: Oliver Kullmann @ 2008-06-26 16:19 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0806261224020.9925@racer>
Hi,
since a similar question burdens my soul for quite some
time, I would like to take the opportunity to extend
the question a bit:
I have around 10 CVS repositories, each with around 5 modules.
This has developed over time, and now I want to combine them
all into a single Git repository, with a new directory
structure introduced.
One possibility would be to convert these 50 CVS modules
into git repositories, then for each of these git repositories
introduce the new tree structure (that is, what is relevant
for this part), move all files to their new location (via
"git mv"), and finally pull everything in into the common
repository.
This is all fine, except of the inability to follow the history
nicely (for example, via gitk I will only see the history
from the point on where in those temporary git-repositories
the files have been moved to their new place).
To avoid this break in the history, it would be great if
cvsimport could already move the files to the right place
in the directory hierarchy, that is, if an additional
parameter P could be given, the initial path, and files
will be imported as P/file. Then I could import everything right away into
the final git repository, without problems with clashes.
I can't find something like that in the documentation.
Is there perhaps some other possibility?
It seems easiest to me to do this little bit of surgery
at the time of the import, before git gets into his
troubles with hash-values.
thanks!
Oliver
On Thu, Jun 26, 2008 at 12:25:54PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 26 Jun 2008, Miklos Vajna wrote:
>
> > On Thu, Jun 26, 2008 at 11:39:37AM +0200, Christian MICHON <christian.michon@gmail.com> wrote:
> > > How would you do it, since merge will not merge if it cannot find a
> > > common ancestor ?
> >
> > Did you try so?
> >
> > If there are no conflicting paths then a simple
> >
> > git pull /path/to/other/repo.git master
> >
> > or similar should work.
>
> FWIW this is how gitk got into git.git... See 5569bf9b(Do a cross-project
> merge of Paul Mackerras' gitk visualizer). This also was often referred
> to as the "coolest merge ever".
>
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Johannes Schindelin @ 2008-06-26 17:49 UTC (permalink / raw)
To: Avery Pennarun
Cc: Björn Steinbrink, Junio C Hamano, Theodore Tso,
Johannes Sixt, Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <32541b130806260855o691d444bpc0843e5f51639430@mail.gmail.com>
Hi,
On Thu, 26 Jun 2008, Avery Pennarun wrote:
> On 6/26/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > While we are nit-picking: Ted's version does not respect autocrlf,
> > while Junio's does.
>
> Is it intentional that git-show doesn't respect autocrlf, or just an
> oversight?
Funny. I seem to have answered exactly the same question a few days ago.
"git show" is meant to show the contents of an object. It does not
operate on a working directory. It does not even _need_ a working
directory.
So, no, it is _not_ an oversight.
Hth,
Dscho
^ 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