* git-cvsserver wart?
From: Cameron McBride @ 2006-05-25 16:42 UTC (permalink / raw)
To: git
I'm a new git user, so if I'm doing something boneheaed - sharp kicks
are welcome.
For reasons I won't go into, the ability to use cvs clients is darn
near crucial. Although most development is local (where I install /
use git), pulling down the latest updates and pushing up minor changes
via CVS is helpful at remote locations where I don't want to maintain
clients. Git with git-cvsserver makes this very nice. Thanks to
all!
Now, the problem I ran into:
code/ntropy> cvs up
Can't use an undefined value as an ARRAY reference at
/usr/local/bin/git-cvsserver line 761.
closing dbh with active statement handles
cvs [update aborted]: end of file from server (consult above messages if any)
code/ntropy> cvs -v
Concurrent Versions System (CVS) 1.11.1p1 (client/server)
Doing a 'cvs up -dP' (or either of the two individually) seems to work fine.
so, it's an old client, a newer client doesn't have this problem. a
bare 'cvs up' works fine on:
Concurrent Versions System (CVS) 1.11.17 (client/server)
Just to be clear, it appears everything gets updated with the
workaround - but there might be something else amiss, so I thought it
was worth mentioning.
Cameron
p.s. I'm assuming the following statement is harmless (it's always present):
closing dbh with active statement handles
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Jim Meyering @ 2006-05-25 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyixe5g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Otherwise, if make is suspended, or killed with prejudice, or if the
>> system crashes, you could be left with an up-to-date, yet corrupt,
>> generated file.
>
> Thanks. Maybe you would want a "make clean" target for them too
> if you do this. I often use $@+ instead of t$@ so that I can
> say "rm -f *+" there.
I chose a prefix rather than a suffix, so that if git is built on a file
system with unreasonable file name length limitations, the prefix will
distinguish the temporary from the target; in that situation, a suffixed
temporary name could map to the target name.
However, assuming reasonable file name length limits, using a suffix is
generally better, since it works even when the target is an absolute
name. Adding a prefix obviously won't work with an absolute name.
I'm happy to ignore 14-byte(and 8.3)-limited file systems and
go with a suffix, if you still prefer that. New patch coming up.
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Jim Meyering @ 2006-05-25 16:42 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060525194125.9380842a.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> wrote:
> Or just use one tmp file, i.e. ".tmp" instead of t$@.
Argh, no.
That'd fail big time with parallel builds.
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Timo Hirvonen @ 2006-05-25 16:41 UTC (permalink / raw)
To: git; +Cc: jim, git
In-Reply-To: <7vejyixe5g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
> > Otherwise, if make is suspended, or killed with prejudice, or if the
> > system crashes, you could be left with an up-to-date, yet corrupt,
> > generated file.
>
> Thanks. Maybe you would want a "make clean" target for them too
> if you do this. I often use $@+ instead of t$@ so that I can
> say "rm -f *+" there.
>
> > @@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
> > rm -f $@ && ln git$X $@
> >
> > common-cmds.h: Documentation/git-*.txt
> > - ./generate-cmdlist.sh > $@
> > + ./generate-cmdlist.sh > t$@
> > + mv t$@ $@
> >
>
> IOW, like this:
>
> common-cmds.h: Documentation/git-*.txt
> rm -f $@+ $@
> ./generate-cmdlist.sh > $@+
> mv $@+ $@
>
> clean::
> rm -f *+
Or just use one tmp file, i.e. ".tmp" instead of t$@.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Junio C Hamano @ 2006-05-25 16:28 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87hd3e5ixw.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Otherwise, if make is suspended, or killed with prejudice, or if the
> system crashes, you could be left with an up-to-date, yet corrupt,
> generated file.
Thanks. Maybe you would want a "make clean" target for them too
if you do this. I often use $@+ instead of t$@ so that I can
say "rm -f *+" there.
> @@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
> rm -f $@ && ln git$X $@
>
> common-cmds.h: Documentation/git-*.txt
> - ./generate-cmdlist.sh > $@
> + ./generate-cmdlist.sh > t$@
> + mv t$@ $@
>
IOW, like this:
common-cmds.h: Documentation/git-*.txt
rm -f $@+ $@
./generate-cmdlist.sh > $@+
mv $@+ $@
clean::
rm -f *+
^ permalink raw reply
* Re: file name case-sensitivity issues
From: Alex Riesen @ 2006-05-25 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j4c4af3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Wed, May 24, 2006 00:57:04 +0200:
> I'd call that a PEBCAK.
It is not solvable there though.
> If you _know_ you are working on a case challenged filesystem, I
> think the best thing you can do is not to work on a project that
> has files in different cases on such a filesystem.
That is seldom an acceptable suggestion. Besides, how about when you
don't _know_, like when cloning onto an usb-stick mounted with
auto-detection? Will the files with case-different names just
overwrite each other?
^ permalink raw reply
* bogus "fatal: Not a git repository"
From: Linus Torvalds @ 2006-05-25 15:22 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Johannes Schindelin
I was just testing that "git ls-remote" change by Junio, and when you're
not in a git repository, it gives this totally bogus warning. The _target_
obviously has to be a git repository, but there's no reason why you'd have
to be in a local git repo when doing an ls-remote.
The reason is commit 73136b2e8a8ee024320c5ac6a0f14f912432bf03 by Dscho: it
adds calls to git-repo-config in git-parse-remote.sh to get the remote
shorthands etc.
Now, either we should just hide and ignore the error from git-repo-config
(probably bad, because some errors _are_ valid - like git-repo-config
failing due to bad syntax in the config file), or we should just make
git-repo-config quietly handle the case of not being in a git repository.
This does the latter: just quietly accepting (and doing nothing - trying
to set a value will result in the lock-file failing) our lot in life
sounds better than dying with a bogus error message.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/repo-config.c b/repo-config.c
index 127afd7..08fc4cc 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -108,7 +108,8 @@ static int get_value(const char* key_, c
int main(int argc, const char **argv)
{
- setup_git_directory();
+ int nongit = 0;
+ setup_git_directory_gently(&nongit);
while (1 < argc) {
if (!strcmp(argv[1], "--int"))
^ permalink raw reply related
* Re: parsecvs fails
From: Lars Johannsen @ 2006-05-25 14:04 UTC (permalink / raw)
To: git; +Cc: Aneesh Kumar
In-Reply-To: <cc723f590605250432r7dd0b75xe5ff17b11da06e3c@mail.gmail.com>
On (25/05/06 17:02), Aneesh Kumar wrote:
> The tagging used by the repository given below is quiet complex.
> But it can be used as a test case for all the cvs to git converter.
> Even ViewVC and ViewCVS doesn't work with this repository.
>
> Any help in converting it to git ?
>
> rsync -av rsync://ci-linux.cvs.sourceforge.net/cvsroot/ci-linux/ci/
> ci-linux/ci/
>
> -aneesh
Well it seems like most of your ,v files contains tags refering to version 1
and yet the first version in the files is 1.1
So to fix for parsecvs ( and maybe for viewcvs) i think you need to fix
all symbols at 'top of file' for all ,v files. Change from v1 to v1.1
with something like sed ',/@#/s/:1*$/:1.1/;,/@#/s/:1;*$/:1.1;/'
--
Lars
^ permalink raw reply
* [PATCH] Don't write directly to a make target ($@).
From: Jim Meyering @ 2006-05-25 13:32 UTC (permalink / raw)
To: git
Otherwise, if make is suspended, or killed with prejudice, or if the
system crashes, you could be left with an up-to-date, yet corrupt,
generated file.
---
Makefile | 34 ++++++++++++++++++++--------------
1 files changed, 20 insertions(+), 14 deletions(-)
59fd5cb51824364100cacd92f1ca4674853a13a8
diff --git a/Makefile b/Makefile
index dbf19c6..3af3187 100644
--- a/Makefile
+++ b/Makefile
@@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
rm -f $@ && ln git$X $@
common-cmds.h: Documentation/git-*.txt
- ./generate-cmdlist.sh > $@
+ ./generate-cmdlist.sh > t$@
+ mv t$@ $@
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- rm -f $@
+ rm -f $@ t$@
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
- $@.sh >$@
- chmod +x $@
+ $@.sh >t$@
+ chmod +x t$@
+ mv t$@ $@
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
- rm -f $@
+ rm -f $@ t$@
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.perl >$@
- chmod +x $@
+ $@.perl >t$@
+ chmod +x t$@
+ mv t$@ $@
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
- rm -f $@
+ rm -f $@ t$@
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.py >$@
- chmod +x $@
+ $@.py >t$@
+ chmod +x t$@
+ mv t$@ $@
git-cherry-pick: git-revert
- cp $< $@
+ cp $< t$@
+ mv t$@ $@
git-status: git-commit
- cp $< $@
+ cp $< t$@
+ mv t$@ $@
# These can record GIT_VERSION
git$X git.spec \
@@ -653,7 +659,8 @@ install-doc:
### Maintainer's dist rules
git.spec: git.spec.in
- sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
+ sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > t$@
+ mv t$@ $@
GIT_TARNAME=git-$(GIT_VERSION)
dist: git.spec git-tar-tree
@@ -724,4 +731,3 @@ check-docs::
*) echo "no link: $$v";; \
esac ; \
done | sort
-
--
1.3.2
^ permalink raw reply related
* Re: Slow fetches of tags
From: Ralf Baechle @ 2006-05-25 13:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslmz6zah.fsf@assigned-by-dhcp.cox.net>
On Wed, May 24, 2006 at 11:41:26AM -0700, Junio C Hamano wrote:
> > $ git-name-rev 0bcf7932d0ea742e765a40b
> > 0bcf7932d0ea742e765a40b master
> > $ git-name-rev 54e938a80873e85f9c02ab4
> > 54e938a80873e85f9c02ab4 34k-2.6.16.18
> > $ git-name-rev 2d0a9369c540519bab8018e
> > 2d0a9369c540519bab8018e 34k-2.6.16.18~1
> > $ git-name-rev bf3060065ef9f0a8274fc32
> > bf3060065ef9f0a8274fc32 34k-2.6.16.18~2
> > $ git-name-rev 27602bd8de8456ac619b77c
> > 27602bd8de8456ac619b77c 34k-2.6.16.18~3
> >
> > It's sending every object back to the start of history ...
>
> Is this "master" commit 0bcf79 part of v2.6.16.18 history? If
> not, how diverged are you? That is, what does this command tell
> you?
No, the master branch is where the MIPS development happens and it's
tracking Linus' master branch. The fact that I'm talking about this
in context of -stable / v2.6.16.18 is that I started looking into why
things were taking minutes when doing a small fetch from 2.6.16-stable.
It happens just as well with Linus' tree or yet others like Matthias
Urlich's -mm git tree.
> git rev-list b7d0617..master | wc -l
>
> Here, b7d0617 is the name of the commit object that is pointed
> by v2.6.16.18 tag.
$ git rev-list b7d0617..master | wc -l
12845
$ git rev-list master..b7d0617 | wc -l (that is swapped arguments)
173
$
Ralf
^ permalink raw reply
* Re: Slow fetches of tags
From: Ralf Baechle @ 2006-05-25 13:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605241641250.5623@g5.osdl.org>
On Wed, May 24, 2006 at 04:43:02PM -0700, Linus Torvalds wrote:
> Actually, maybe the problem is that Ralf's tree has two roots, because of
> the old CVS history. It might be following the other root down for the
> "have" part, since that one doesn't exist at all in the target and the
> other side will never acknowledge any of it.
>
> I'll play with it.
Interesting idea, so I went to play with it, too. I took a copy of the
tree and deleted all branches except the v2.6.16-stable tracking branch
which I pruned back to v2.6.16.17, then added a new branch starting at
the oldest commit, your initial import of the kernel tree:
$ git branch junk 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
$ git checkout junk
$ seq -f "%05.0f" 1 100 | while read i; do echo $i; echo $i > Makefile;\
git commit -s -m "Blah $i" Makefile; done
So with this I get:
$ git branch
* junk
v2.6.16-stable
$
If I now run
$ strace git-fetch-pack --thin git://www.kernel.org/pub/scm/linux/kernel/\
git/stable/linux-2.6.16.y.git \
refs/heads/master refs/tags/v2.6.16.18 2>&1 | grep have /tmp/xxx
I get:
write(3, "0032have ef686028603c291ba510c66"..., 50) = 50
write(3, "0032have 150384dac99eb263c4385c7"..., 50) = 50
write(3, "0032have 4df3afbfc2d8f6c22d41c63"..., 50) = 50
...
write(3, "0032have db119fba3d9495aa9cd5a63"..., 50) = 50
Where ef686028603c291ba510c66 = junk, 150384dac99eb263c4385c7 = junk~1 ...
db119fba3d9495aa9cd5a63 = junk~99 (first commit on the junk branch).
100 "have" lines upto this point, then:
write(3, "0032have d87319c3e4d908e157a462d"..., 50) = 50
write(3, "0032have 22ddf44d54d0b2326f7b233"..., 50) = 50
write(3, "0032have 90a03936acb1c3400a5833c"..., 50) = 50
write(3, "0032have bf7d8bacaaf241a0f015798"..., 50) = 50
write(3, "0032have a120571fbdfc8f543eea642"..., 50) = 50
write(3, "0032have 42a46c74c4520174b82a60a"..., 50) = 50
write(3, "0032have f66ab685594d49e570b2176"..., 50) = 50
write(3, "0032have 834f514019e01f87657a257"..., 50) = 50
write(3, "0032have 9d395d1961a0eeb9e8b1ef2"..., 50) = 50
write(3, "0032have aa48603d1ba772d0a2b28ab"..., 50) = 50
write(3, "0032have 54e5705fd460c7621a4d73c"..., 50) = 50
write(3, "0032have 37863c8a9b7b0261ec76daa"..., 50) = 50
write(3, "0032have a7603f9099869f9aeebd6c7"..., 50) = 50
write(3, "0032have 623c30d2ae22cd4b8703c77"..., 50) = 50
write(3, "0032have e2c78fb27dd13ab8c778a96"..., 50) = 50
write(3, "0032have dbb676d1214c181e6cde4ce"..., 50) = 50
write(3, "0032have 1ffe5e06461f72b9b6a2569"..., 50) = 50
These are the commits for which this test tree has the tags left:
$ ls .git/refs/tags/
v2.6.16.1 v2.6.16.12 v2.6.16.15 v2.6.16.2 v2.6.16.5 v2.6.16.8
v2.6.16.10 v2.6.16.13 v2.6.16.16 v2.6.16.3 v2.6.16.6 v2.6.16.9
v2.6.16.11 v2.6.16.14 v2.6.16.17 v2.6.16.4 v2.6.16.7
$
And finally:
write(3, "0032have 1da177e4c3f41524e886b7f"..., 50) = 50
which is your Linux-2.6.12-rc2 import.
Ralf
^ permalink raw reply
* [PATCH] Documentation/Makefile: remove extra /
From: Martin Waitz @ 2006-05-25 12:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
As both DESTDIR and the prefix are supposed to be absolute pathnames
they can simply be concatenated without an extra / (like in the main Makefile).
The extra slash may even break installation on Windows.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
Documentation/Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 2a08f59..2b0efe7 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -52,9 +52,9 @@ man1: $(DOC_MAN1)
man7: $(DOC_MAN7)
install: man
- $(INSTALL) -d -m755 $(DESTDIR)/$(man1) $(DESTDIR)/$(man7)
- $(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
- $(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
+ $(INSTALL) -d -m755 $(DESTDIR)$(man1) $(DESTDIR)$(man7)
+ $(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1)
+ $(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7)
#
--
1.3.3.g29c7
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Björn Engelmann @ 2006-05-25 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wuj6wln.fsf@assigned-by-dhcp.cox.net>
> Sorry, I forgot all about hash-objects X-<. It was a convenient
> way to try out new things such as 'gitlink'. Thanks for the
> clarification.
>
> As to unification, I am not sure if there are a lot to unify.
> Everybody starts with type, length and a LF, but after that each
> type has its own format constraints. A grand unified command
> that knows about format constraints of every type under the sun
> does not sound like a good approach. While we have only handful
> types (and I expect things will stay that way) it is not a big
> deal either way, though.
>
Oops, sorry, I forgot that "modular" in C means something else than in
the OO-World...
You are right. Probably it is best to have one tool handle each type.
Actually what I am aiming for is not the internal structure. I am more
concerned about cleaning up the user-interface. When I started learning
git I found it very annoying and inconsistent that there are commands
for creating a tag and a tree in a validated fashion, but the command
for creating blobs was named "git-hash-object -w" and also could create
all other objects without validating them at all. Also, AFAIK there is
currently no way of creating a commit object with validating.
I am well aware that all functionality neccessary already exists. I just
want to prevent people learning git in future to have the same
frustrating experience as I did.
Obviously renaming / moving code around like that would break nearly all
tools build ontop of git. Therefore I would prefer to use aliasing. If
you feel like this would introduce too many unneccessary commands, I
would instead focus on improving the documentation.
Bj
^ permalink raw reply
* parsecvs fails
From: Aneesh Kumar @ 2006-05-25 11:32 UTC (permalink / raw)
To: Git Mailing List
The tagging used by the repository given below is quiet complex.
But it can be used as a test case for all the cvs to git converter.
Even ViewVC and ViewCVS doesn't work with this repository.
Any help in converting it to git ?
rsync -av rsync://ci-linux.cvs.sourceforge.net/cvsroot/ci-linux/ci/ ci-linux/ci/
-aneesh
^ permalink raw reply
* Re: importing cvs logical modules
From: Jakub Narebski @ 2006-05-25 7:02 UTC (permalink / raw)
To: git
In-Reply-To: <93c3eada0605242359k204bfe79vabc323eddfafa5f@mail.gmail.com>
Geoff Russell wrote:
> On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>> On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
>>> The tight linkage is absolutely essential.
>>>
>>> When we tag the system, we
>>> want to tag everything (not individually tag all 300 programs)
>>> so that later we can to branch at that tag. Very few of our
>>
>> Then you want a single git repo/tree/project. The thing is how to work
>> through your mangled CVS history.
>>
>> Two options there...
>>
>> - Don't. Import from after the last directory reorg or from your last
>> interesting release. Keep the cvs tree for people who really want to
>> dig into the past. this has several advantages, as initial checkouts
>> will be faster, import times shorter, less pain overall.
>
> Yes, this is definitely on the shortlist of options.
> If we can't keep all the history, we may as well make
> a clean start. Thanks for the advice.
Well, you can always copy history and graft old CVS history later. Perhaps
when "bind" (or Cogito "bind lite") mature enough...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: importing cvs logical modules
From: Geoff Russell @ 2006-05-25 6:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605242316l4b0a0963m638f7a2e47936000@mail.gmail.com>
On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> > The tight linkage is absolutely essential.
> >
> > When we tag the system, we
> > want to tag everything (not individually tag all 300 programs)
> > so that later we can to branch at that tag. Very few of our
>
> Then you want a single git repo/tree/project. The thing is how to work
> through your mangled CVS history.
>
> Two options there...
>
> - Don't. Import from after the last directory reorg or from your last
> interesting release. Keep the cvs tree for people who really want to
> dig into the past. this has several advantages, as initial checkouts
> will be faster, import times shorter, less pain overall.
Yes, this is definitely on the shortlist of options.
If we can't keep all the history, we may as well make
a clean start. Thanks for the advice.
Cheers,
Geoff.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Junio C Hamano @ 2006-05-25 6:36 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m13beysnb2.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> I clearly would not advertise it. My problem is that I have
> evidence that someone pulled a given sha1 at some point from
> some branch on a given repository. But I don't have that branch.
If that was over rsync (as you mention later), then I would
consider that is an unfortunate unfixable issue. rsync mirrors
are fundamentally unsafe for git -- Linus and I do not keep
saying rsync should be deprecated without good reasons.
There still might be bugs that breaks this guarantee outside
rsync, but if that is the case we should fix it.
I do not want to rehash the thread around Sep 29th 2005 here.
The entry point of that thread is this message:
http://marc.theaimsgroup.com/?l=git&m=112795140820665
and the punch line are these two messages:
http://marc.theaimsgroup.com/?l=git&m=112801874021223
http://marc.theaimsgroup.com/?l=git&m=112802808030710
I did not realize what I was breaking initially. I am not
ashamed of having been wrong, but it was embarrassing ;-).
> If I want
> a copy of your pu branch at some point in the past, but you have
> rebased it since that sha1 was published then there will clearly not
> be a path from any current head to that branch. But if I still have a
> copy of the sha1 I should actually be able to recover the old copy of
> the pu branch from your tree.
Not necessarily. I occasionally prune after rewinding. When my
"pu" branch head does not point at the lost commit, the
repository may or may not have that object you happen to know I
used to have anymore.
>> Now, proving that a given SHA1 is the name of an object that
>> exists in the repository is cheap (has_sha1_file()), but proving
>> that the object is reachable from some of our refs can become
>> quite expensive. That gives this issue a security implication
>> as well -- you can easily DoS the git-daemon that way, for
>> example.
>
> Exactly, which is why I aimed for the cheap test.
But the thing is the cheap test is broken, eh, rather,
propagates brokenness downstream (which is perhaps worse).
^ permalink raw reply
* Re: importing cvs logical modules
From: Martin Langhoff @ 2006-05-25 6:16 UTC (permalink / raw)
To: geoff; +Cc: Junio C Hamano, git
In-Reply-To: <93c3eada0605242302x24ca1272xd7bfc3a677b32845@mail.gmail.com>
On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> The tight linkage is absolutely essential.
>
> When we tag the system, we
> want to tag everything (not individually tag all 300 programs)
> so that later we can to branch at that tag. Very few of our
Then you want a single git repo/tree/project. The thing is how to work
through your mangled CVS history.
Two options there...
- Don't. Import from after the last directory reorg or from your last
interesting release. Keep the cvs tree for people who really want to
dig into the past. this has several advantages, as initial checkouts
will be faster, import times shorter, less pain overall.
- Mangle import to match your reorganizations:
- Generate the cvsps output file
- Duplicate/copy files in the cvs repo so that files are in both
places if you've been mving them around.
- Mangle the cvsps output file from each reorg onwards. This is
nasty, but it will define the history that cvsimport sees.
cheers,
martin
^ permalink raw reply
* Re: importing cvs logical modules
From: Geoff Russell @ 2006-05-25 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslmyzoit.fsf@assigned-by-dhcp.cox.net>
On 5/25/06, Junio C Hamano <junkio@cox.net> wrote:
> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>
> > I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
> >
> > Progs/.git
> > Progs/xxxx
> > Progs/yyyy
> >
> > Does this sound useful to anyone else, or is it already possible?
>
> I would do it like this:
>
> Progs/.git
> Progs/xxxx/.git
> Progs/yyyy/.git
>
> I do not know what you have in Progs/ hierarchy -- if it is just
> scaffolding to house subdirectories and nothing else you may not
> even need Progs/.git repository.
>
> This is a very useful and handy structure, and you do not need
> any tool support once you have these as separate repositories.
> If you want a single distribution point, you can push from these
> separate repositories into separate branches of a single
> distribution point repository [*1*].
>
> One potential disadvantage is that you would not get revision
> linkage between these "modules", but not having tight linkage is
> the point of modular structure, so depending on your workflow it
> probably may not matter.
The tight linkage is absolutely essential.
When we tag the system, we
want to tag everything (not individually tag all 300 programs)
so that later we can to branch at that tag. Very few of our
programs are self contained, they generally make heavy use
of one or more libraries --- which must also be part of the
tree. The full structure should end up looking like:
Top/.git
Libraries/libx
Libraries/liby
Libraries/boost
Libraries/...
Programs/xxx
Programs/yyy
Programs/...
...etc.
When we build a full system, we want to tag that point so
we can know exactly what went into that build.
We used to do it the "other" way.
cvsroot/xxx
cvsroot/yyy
cvsroot/liby
cvsroot/libx
etc
But then when we did a system build, someone always forgot
to tag something. So we got cvs to build a build logical tree
and then cvs was quite happy to tag the lot with one go and
nothing got forgotten. So now we are trying to pull the
lot into git as one big tree.
Cheers,
Geoff.
>
>
> [Footnote]
>
> *1* In fact, my git working area has the "master", "next" or
> "pu" branch checked out in /path/to/work/area/git (and the
> repository is in /path/to/work/area/git/.git directory), and I
> check out the "todo" branch in /path/to/work/area/git/Meta
> directory, with /path/to/work/area/git/Meta/.git directory as
> its repository.
>
>
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 5:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyjpz9a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Can we fix the check in upload-pack.c something like my
>> patch below does? Are there any security implications for
>> doing that?
>
>> Could we just make the final check before dying if (!o) ?
>
> The primary implication is about correctness, so I am reluctant
> to break it without a careful alternative check in place.
>
> The issue is that having a single object in the repository does
> not guarantee that you have everything reachable from it, and we
> need that guarantee. Reachability from the refs is what
> guarantees that.
I don't see why having something reachable from a ref guarantees
that everything is reachable. Given the recent patch that added
a check to make certain a ref actually existed I believe there
is some evidence that trees may become corrupted, and have the
problems you describe.
> We are careful to update the ref at the very end of the transfer
> (fetch/clone or push); so if an object is reachable from a ref,
> then all the objects reachable from that object are available in
> the repository.
In the normal case I agree.
> Imagine http commit walker started fetching tip of upstream into
> your repository and you interrupted the transfer. Objects near
> the tip of the upstream history are available after such an
> interrupted transfer. But a bit older history (but still later
> than what we had before we started the transfer) are not.
>
> We do not update the ref with the downloaded tip object, so that
> we would not break the guarantee. This guarantee is needed for
> feeding clients from the repository later. If you tell your
> clients, after such an interrupted transfer, that you are
> willing to serve the objects near the (new) tip, the clients may
> rightfully request objects that are reachable from these
> objects, some of them you do _not_ have!
I clearly would not advertise it. My problem is that I have
evidence that someone pulled a given sha1 at some point from
some branch on a given repository. But I don't have that branch.
Actually trees mirrored with rsync have similar problems all of
the time when the catch a tree in the middle of an update.
> So this "on demand SHA1" stuff needs to be solved by checking if
> the given object is reachable from our refs in upload-pack,
> instead of the current check to see if the given object is
> pointed by our refs. When upload-pack can prove that the object
> is reachable from one of the refs, it is OK to use it; otherwise
> you should not.
I have a problem with that approach. Suppose the branch I have
evidence something came from is like your pu branch. If I want
a copy of your pu branch at some point in the past, but you have
rebased it since that sha1 was published then there will clearly not
be a path from any current head to that branch. But if I still have a
copy of the sha1 I should actually be able to recover the old copy of
the pu branch from your tree.
> Now, proving that a given SHA1 is the name of an object that
> exists in the repository is cheap (has_sha1_file()), but proving
> that the object is reachable from some of our refs can become
> quite expensive. That gives this issue a security implication
> as well -- you can easily DoS the git-daemon that way, for
> example.
Exactly, which is why I aimed for the cheap test.
There is a reasonable argument that can be made that the branches
represent the policy that you are willing to serve. If you have a
tree and share a common object store with a much lager tree, like
David Woodhouse has set up, I can see such a policy being desirable.
That is an argument I have a much harder time shooting down.
At the same time if it is just a policy question the policy it should
be modifiable with an appropriate configuration directive, or
command line option.
Eric
^ permalink raw reply
* Re: [PATCH] ls-remote fix for rsync:// transport
From: Sean @ 2006-05-25 5:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j4a3f9i.fsf@assigned-by-dhcp.cox.net>
On Wed, 24 May 2006 21:22:17 -0700
Junio C Hamano <junkio@cox.net> wrote:
> I think this would fix the "cloning rsync:// clones repository fine but
> does not check out the working tree" problem.
Nice find, works here.
Sean
^ permalink raw reply
* Re: importing cvs logical modules
From: Junio C Hamano @ 2006-05-25 5:01 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <93c3eada0605242148u4656bc31p96d84a16703f0fe0@mail.gmail.com>
"Geoff Russell" <geoffrey.russell@gmail.com> writes:
> I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
>
> Progs/.git
> Progs/xxxx
> Progs/yyyy
>
> Does this sound useful to anyone else, or is it already possible?
I would do it like this:
Progs/.git
Progs/xxxx/.git
Progs/yyyy/.git
I do not know what you have in Progs/ hierarchy -- if it is just
scaffolding to house subdirectories and nothing else you may not
even need Progs/.git repository.
This is a very useful and handy structure, and you do not need
any tool support once you have these as separate repositories.
If you want a single distribution point, you can push from these
separate repositories into separate branches of a single
distribution point repository [*1*].
One potential disadvantage is that you would not get revision
linkage between these "modules", but not having tight linkage is
the point of modular structure, so depending on your workflow it
probably may not matter.
[Footnote]
*1* In fact, my git working area has the "master", "next" or
"pu" branch checked out in /path/to/work/area/git (and the
repository is in /path/to/work/area/git/.git directory), and I
check out the "todo" branch in /path/to/work/area/git/Meta
directory, with /path/to/work/area/git/Meta/.git directory as
its repository.
^ permalink raw reply
* Re: importing cvs logical modules
From: Jakub Narebski @ 2006-05-25 4:56 UTC (permalink / raw)
To: git
In-Reply-To: <93c3eada0605242148u4656bc31p96d84a16703f0fe0@mail.gmail.com>
Geoff Russell wrote:
> Then to join the git repositories together in the desired way. I think
> this would be generally useful and not just solve my problem.
>
> e.g. Suppose I have 3 git repositories: Progs, xxxx, yyyy
>
> Progs/.git
> xxxx/.git
> yyyy/.git
>
> I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
>
> Progs/.git
> Progs/xxxx
> Progs/yyyy
>
> Does this sound useful to anyone else, or is it already possible?
It is done. TODO branch in git.git repository on kernel.org is pushed to
from *separate* git-todo.git repository. BTW. working are of repositories
can be joined (although it needs entry in .gitignore):
Progs/.git
Progs/TODO/.git
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Slow fetches of tags
From: Junio C Hamano @ 2006-05-25 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vd5e23n5a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It might be worth changing fetch-pack to note that it has sent
> many "have"s after it got an "continue" ACK, and give up early,
> say using a heuristic between the age of the commit that did got
> an ACK and the one we are about to send out as a "have".
I think the right fix for this is to change upload-pack to
traverse reachability chain from the "want" heads as it gets
"have" from the downloader, and stop responding "continue" when
all "want" heads can reach some "have" commits. This would not
prevent it from going down all the way to the root commit if
what is wanted does not have anything to do with what the other
end has (e.g. if you have only my main project branches, and you
ask for html head for the first time), but it would have
prevented Ralf's tree from getting "continue" after he asked
only for v2.6.16.18 tag and said he has 2.6.16.18 commit and its
ancestors. It should not be too difficult to do this, but here
is an alternative, client-side workaround.
-- >8 --
[PATCH] fetch-pack: give up after getting too many "ack continue"
If your repository have more roots than the remote repository
you ask an object for, the remote upload-pack keeps responding
"ack continue" until it fills up its received-have buffer
(currently 256 entries). Usually this is not a problem because
the requester stops traversing the ancestry chain from the commit
it gets "ack continue" for, but this mechanism does not work as
a roadblock when it traverses down the path to the root the
other side does not have.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/fetch-pack.c b/fetch-pack.c
index 8daa93d..8371348 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -18,6 +18,12 @@ #define COMMON_REF (1U << 2)
#define SEEN (1U << 3)
#define POPPED (1U << 4)
+/*
+ * After sending this many "have"s if we do not get any new ACK , we
+ * give up traversing our history.
+ */
+#define MAX_IN_VAIN 256
+
static struct commit_list *rev_list = NULL;
static int non_common_revs = 0, multi_ack = 0, use_thin_pack = 0;
@@ -134,6 +140,8 @@ static int find_common(int fd[2], unsign
int fetching;
int count = 0, flushes = 0, retval;
const unsigned char *sha1;
+ unsigned in_vain = 0;
+ int got_continue = 0;
for_each_ref(rev_list_insert_ref);
@@ -172,6 +180,7 @@ static int find_common(int fd[2], unsign
packet_write(fd[1], "have %s\n", sha1_to_hex(sha1));
if (verbose)
fprintf(stderr, "have %s\n", sha1_to_hex(sha1));
+ in_vain++;
if (!(31 & ++count)) {
int ack;
@@ -200,9 +209,16 @@ static int find_common(int fd[2], unsign
lookup_commit(result_sha1);
mark_common(commit, 0, 1);
retval = 0;
+ in_vain = 0;
+ got_continue = 1;
}
} while (ack);
flushes--;
+ if (got_continue && MAX_IN_VAIN < in_vain) {
+ if (verbose)
+ fprintf(stderr, "giving up\n");
+ break; /* give up */
+ }
}
}
done:
^ permalink raw reply related
* importing cvs logical modules
From: Geoff Russell @ 2006-05-25 4:48 UTC (permalink / raw)
To: git
Hi,
Firstly, the code to automagically
repack a git repository on-the-fly during a big load has solved one of
my problems - thanks, it is great. Unfortunately it has bought me to
showstopper number 2.
- cvs modules.
cvs allows you to define modules which rearrange the physical repository into
a different logical structure. This sounds great and we use it, but it gives
us other headaches because "cvs update" doesn't always do the right
thing with these modules.
Furthermore cvsps doesn't appear to handle this module feature at all and
is tricked into thinking that rearranged directories come from somewhere
else and issues its "file xxx doesn't match strip_path" message.
I have tried to hack cvsps to go around the problem, but without success.
Another alternative that I thought might be easier would be to unload the cvs
repository in clean pieces - each being a git repository. Then to join the
git repositories together in the desired way. I think this would be
generally useful and not just solve my problem.
e.g. Suppose I have 3 git repositories: Progs, xxxx, yyyy
Progs/.git
xxxx/.git
yyyy/.git
I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.
Progs/.git
Progs/xxxx
Progs/yyyy
Does this sound useful to anyone else, or is it already possible?
Cheers,
Geoff Russell.
^ 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