* Re: parsecvs and unnamed branches
From: Pavel Roskin @ 2006-06-17 3:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606162002x508ec6ccjbc36e4220ca44fd6@mail.gmail.com>
Hi, Jon!
On Fri, 2006-06-16 at 23:02 -0400, Jon Smirl wrote:
> My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
>
> Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
>
> Error: branch cycle
> *** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
> *** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
Obviously, memory corruption. Valgrind is likely to help, but it may
take 50 hours rather than 5. It may still be worth it. Make sure to
use the latest version of Valgrind and compile parsecvs without
optimization with full debug information. If you can get debug info for
libc, install it (on Fedora: "yum install glibc-debuginfo").
> /lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
> parsecvs[0x804dec8]
You see, even some libc symbols can be found, but parsecvs is opaque.
That's why debug information is useful. Make sure to keep the sources
around for debugging.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-17 3:02 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1150496362.6983.34.camel@neko.keithp.com>
My parsecvs job died after 5 hours of CPU time. Does this tell you anything?
Pack pack-e28915a5ea09143a9139e84e24534ed888bf1c45 created
Error: branch cycle
*** glibc detected *** parsecvs: munmap_chunk(): invalid pointer: 0x0a820198 ***
*** glibc detected *** parsecvs: corrupted double-linked list: 0x45b1e158 ***
======= Backtrace: =========
/lib/libc.so.6[0x45a502c6]
/lib/libc.so.6[0x45a5235a]
/lib/libc.so.6(calloc+0x8d)[0x45a539a1]
/lib/ld-linux.so.2[0x459db1ba]
/lib/ld-linux.so.2[0x459d6f8a]
/lib/ld-linux.so.2[0x459d91e1]
/lib/ld-linux.so.2[0x459e2204]
/lib/ld-linux.so.2[0x459de7b9]
/lib/ld-linux.so.2[0x459e1d0a]
/lib/libc.so.6[0x45ae9c3e]
/lib/ld-linux.so.2[0x459de7b9]
/lib/libc.so.6(__libc_dlopen_mode+0x55)[0x45ae9dc9]
/lib/libc.so.6[0x45ac90f6]
/lib/libc.so.6(backtrace+0x109)[0x45ac9295]
/lib/libc.so.6[0x45a4aa61]
/lib/libc.so.6(__libc_free+0x179)[0x45a554f0]
parsecvs[0x804dec8]
parsecvs[0x804df1e]
parsecvs[0x804ccce]
/lib/libc.so.6(__libc_start_main+0xdc)[0x45a03724]
parsecvs[0x8049cc1]
======= Memory map: ========
08048000-08065000 r-xp 00000000 09:01 4052384
/home/jonsmirl/workspace/parsecvs/parsecvs
08065000-08067000 rw-p 0001c000 09:01 4052384
/home/jonsmirl/workspace/parsecvs/parsecvs
08067000-459c9000 rw-p 08067000 00:00 0 [heap]
459d1000-459ea000 r-xp 00000000 03:06 4243239 /lib/ld-2.4.so
459ea000-459eb000 r--p 00018000 03:06 4243239 /lib/ld-2.4.so
459eb000-459ec000 rw-p 00019000 03:06 4243239 /lib/ld-2.4.so
459ee000-45b1b000 r-xp 00000000 03:06 4243241 /lib/libc-2.4.so
45b1b000-45b1d000 r--p 0012d000 03:06 4243241 /lib/libc-2.4.so
45b1d000-45b1e000 rw-p 0012f000 03:06 4243241 /lib/libc-2.4.so
45b1e000-45b21000 rw-p 45b1e000 00:00 0
45b23000-45b25000 r-xp 00000000 03:06 4243258 /lib/libdl-2.4.so
45b25000-45b26000 r--p 00001000 03:06 4243258 /lib/libdl-2.4.so
45b26000-45b27000 rw-p 00002000 03:06 4243258 /lib/libdl-2.4.so
45c6e000-45c80000 r-xp 00000000 03:06 1782100 /usr/lib/libz.so.1.2.3
45c80000-45c81000 rw-p 00011000 03:06 1782100 /usr/lib/libz.so.1.2.3
46497000-46499000 r-xp 00000000 03:06 4244426 /lib/libcom_err.so.2.1
46499000-4649a000 rw-p 00001000 03:06 4244426 /lib/libcom_err.so.2.1
4649c000-464ab000 r-xp 00000000 03:06 4244425 /lib/libresolv-2.4.so
464ab000-464ac000 r--p 0000e000 03:06 4244425 /lib/libresolv-2.4.so
464ac000-464ad000 rw-p 0000f000 03:06 4244425 /lib/libresolv-2.4.so
464ad000-464af000 rw-p 464ad000 00:00 0
464bb000-465da000 r-xp 00000000 03:06 4244427 /lib/libcrypto.so.0.9.8a
465da000-465ed000 rw-p 0011e000 03:06 4244427 /lib/libcrypto.so.0.9.8a
465ed000-465f0000 rw-p 465ed000 00:00 0
465f2000-465f5000 r-xp 00000000 03:06 1785207 /usr/lib/libkrb5support.so.0.0
465f5000-465f6000 rw-p 00002000 03:06 1785207 /usr/lib/libkrb5support.so.0.0
465f8000-4666b000 r-xp 00000000 03:06 1788263 /usr/lib/libkrb5.so.3.2
4666b000-4666d000 rw-p 00073000 03:06 1788263 /usr/lib/libkrb5.so.3.2
4666f000-46687000 r-xp 00000000 03:06 1788264 /usr/lib/libgssapi_krb5.so.2.2
46687000-46688000 rw-p 00017000 03:06 1788264 /usr/lib/libgssapi_krb5.so.2.2
4668a000-466ae000 r-xp 00000000 03:06 1788262 /usr/lib/libk5crypto.so.3.0
466ae000-466af000 rw-p 00024000 03:06 1788262 /usr/lib/libk5crypto.so.3.0
467e0000-46821000 r-xp 00000000 03:06 4244428 /lib/libssl.so.0.9.8a
46821000-46825000 rw-p 00040000 03:06 4244428 /lib/libssl.so.0.9.8a
84400000-84421000 rw-p 84400000 00:00 0
84421000-84500000 ---p 84421000 00:00 0
84518000-84523000 r-xp 00000000 03:06 4244801
/lib/libgcc_s-4.1.1-20060525.so.1
84523000-84524000 rw-p 0000a000 03:06 4244801
/lib/libgcc_s-4.1.1-20060525.so.1
84538000-85438000 rw-p 84538000 00:00 0
854bc000-856bc000 rw-p 854bc000 00:00 0
8577f000-86b7f000 rw-p 8577f000 00:00 0
86bc1000-86dc1000 rw-p 86bc1000 00:00 0
86e65000-88465000 rw-p 86e65000 00:00 0
884e8000-893e8000 rw-p 884e8000 00:00 0
893e9000-896e9000 rw-p 893e9000 00:00 0
896ea000-89bea000 rw-p 896ea000 00:00 0
89c2c000-89f2c000 rw-p 89c2c000 00:00 0
89f4d000-8a14d000 rw-p 89f4d000 00:00 0
8a16e000-8a76e000 rw-p 8a16e000 00:00 0
8a76f000-8af6f000 rw-p 8a76f000 00:00 0
8b056000-8b156000 rw-p 8b056000 00:00 0
8b177000-8b477000 rw-p 8b177000 00:00 0
8b478000-8b978000 rw-p 8b478000 00:00 0
8b979000-8ba79000 rw-p 8b979000 00:00 0
8ba9a000-8bc9a000 rw-p 8ba9a000 00:00 0
8bd1e000-8c11e000 rw-p 8bd1e000 00:00 0
8c11f000-8c41f000 rw-p 8c11f000 00:00 0
8c420000-8c520000 rw-p 8c420000 00:00 0
8c582000-8c682000 rw-p 8c582000 00:00 0
8c683000-8d383000 rw-p 8c683000 00:00 0
8d426000-8d5260Aborted
[jonsmirl@jonsmirl parsecvs]$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* git-1.4.0 make problems
From: Michael Somos @ 2006-06-17 2:18 UTC (permalink / raw)
To: git
I downloaded the git-1.4.0.tar.bz2 recently and encountered a few problems.
1) The untar process creates a stray file "pax_global_header".
I am using GNU tar v1.13.22 and I get this message :
======================================================================
> tar jxf ~/u/source/git-1.4.0.tar.bz2
tar: pax_global_header: Unknown file type 'g', extracted as normal file
======================================================================
2) The make install process ignores the "prefix=..." argument. I have
to comment out one line for this :
======================================================================
> diff Makefile git-1.4.0/
94c94
< #prefix = $(HOME)
---
> prefix = $(HOME)
======================================================================
3) The make has a problem with "expat" include and libararies.
I have to add more lines to the Makefile to handle this like some
of the other include and libraries :
======================================================================
351,358c351
< endif
<
< ifndef NO_EXPAT
< ifdef EXPATDIR
< # This is still problematic -- gcc does not always want -R.
< ALL_CFLAGS += -I$(EXPATDIR)/include
< EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat
< else
---
> ifndef NO_EXPAT
360c353
< endif
---
> endif
======================================================================
Other than that, it installed okay. I will have to read the docs and
use it to see how it goes otherwise.
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-17 1:23 UTC (permalink / raw)
To: git, Juergen Ruehle
In-Reply-To: <17555.21858.292000.494454@lapjr.intranet.kiel.bmiag.de>
On Sat, Jun 17, 2006 at 03:05:38AM +0200, Juergen Ruehle wrote:
>Christopher Faylor writes:
> > I also meant to ask if there was an i is nonzero after the call to the
> > rename() above? If so, what was the errno? If not, it is a huge
> > problem if rename is reporting that it is able to rename a file but is
> > not actually doing it.
>
>After some testing the conclusion is that it's not lying, but only
>failing in interesting ways on my (and seemingly also Niklas') system:
>
> - rename on NTFS succeeds (and returns 0)
>
> - rename on FAT32 succeeds if target does not exist (and returns 0)
>
> rename on FAT32 fails if target exists with EACCESS
>
> (manual mv on commandline works)
>
> - rename on a network share always hangs for a while and then fails
> with EBUSY (even if target does not exist)
>
> (share served by XP, tested both NTFS and FAT32)
>
> (manual mv still works)
>
>Various combinations of server, ntsec, and smbntsec didn't seem to
>make a difference; /etc/{passwd,group} have been freshly created.
Thanks. I really appreciate the details. I've passed them on to the
last person to touch the rename code.
cgf
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Juergen Ruehle @ 2006-06-17 1:02 UTC (permalink / raw)
To: Niklas Frykholm, git
In-Reply-To: <17554.48926.852000.679014@lapjr.intranet.kiel.bmiag.de>
Juergen Ruehle writes:
> The following hack is a workaround, but is probably not safe.
Please just ignore it, it only helps on FAT32 partitions. Sorry for
the confusion.
jr
^ permalink raw reply
* Re: Porcelain specific metadata under .git?
From: Shawn Pearce @ 2006-06-17 0:43 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
In-Reply-To: <44900A2F.7050704@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Jakub Narebski wrote:
> >Andreas Ericsson wrote:
> >
> >
> >>Shawn Pearce wrote:
> >>
> >>>I already assume/know that refs/heads and refs/tags are completely
> >>>off-limits as they are for user refs only.
> >>>
> >>>I also think the core GIT tools already assume that anything
> >>>directly under .git which is strictly a file and which is named
> >>>entirely with uppercase letters (aside from "HEAD") is strictly a
> >>>temporary/short-lived state type item (e.g. COMMIT_MSG) used by a
> >>>Porcelain.
> >>>
> >>>But is saying ".git/refs/eclipse-workspaces" is probably able to
> >>>be used for this purpose safe? :-)
> >>>
> >>
> >>.git/eclipse/whatever-you-like
> >>
> >>would probably be better. Heads can be stored directly under .git/refs
> >>too. Most likely, nothing will ever be stored under ./git/eclipse by
> >>either core git or the current (other) porcelains though.
> >
> >
> >I think if it is a ref, which one wants to be visible to git-fsck (and
> >git-prune), it should be under .git/refs.
> >
>
> Yes, but I understood him to mean "it's a tree-sha" instead of a
> branch/head thing, which would mean it doesn't fit the .git/refs
> definition of ref.
Sorry for the late response to this but I've been busy with real
work for the past few days and have not been able to get around to
fun work. :-)
Yes, its a tree-sha. There's no point in generating a commit for
this tree as it is serving a purpose similar to the index in core
GIT. It is a tree which represents the current directory state,
or something recently near to it anyway. Not enough information
exists to warrant building a commit however, nor is there really
any suitable parent for such a commit. Ditto with a tag.
I'm planning on periodically performing a write-tree of the current
working directory whenever Eclipse has notified the team provider of
tracked resources being modified, with the write-tree occuring no
more frequently then a user set threshold, or whenever the project
is closed or the workbench is shutdown.
I figure that if the user hasn't re-modified an already "known to
be changed" (due to different stat data) file in the last 5 minutes
and we haven't written a tree out (for any reason) in the last 15
minutes then maybe we should generate a tree right now as the user
is likely to commit one soon. Generating a tree in the background
on a low priority thread while the user is busy thinking will make
commits "go faster", especially if all I need to do is generate the
commit object itself as the tree is already made. :-)
It also just makes things easier, as I need the diff-tree code
anyway so making use of that to also track the working directory
just seems to make sense.
I want it under .git/refs as I don't really want my in progress
tree to go away due to a prune issued by the user. At least not
until I have a different tree stored there anyway.
So I'm going to store them under .git/refs/eclipse/some-path.
--
Shawn.
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: Linus Torvalds @ 2006-06-17 0:22 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Goo GGooo, linux-kernel, git
In-Reply-To: <44931AFD.4070809@zytor.com>
On Fri, 16 Jun 2006, H. Peter Anvin wrote:
>
> Perhaps we shouldn't rely on stderr, and instead have a backchannel as part of
> the protocol itself.
Absolutely. I'm just irritated at myself for not going that way in the
first place, but when I originally wrote it, I had my eyes on other
issues, and the nice status updates got added later..
Linus
^ permalink raw reply
* Re: Collecting cvsps patches
From: Junio C Hamano @ 2006-06-16 23:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e6v7vr$ila$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Yann Dirson wrote:
>
>> On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
>>> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>>>
>>> > http://ydirson.free.fr/soft/git/cvsps.git
>>>
>>> I think you need to chmod +x hooks/post-update
>>>
>>> and then run 'git-update-server-info'.
>>
>> Unfortunately, I only have FTP access to push to this site, so I have
>> to run git-update-server-info myself, and occasionally forget. I'll
>> have to bring up-to-date my old cg-ftppush script some day :)
>
> Or extend git to allow push/pull also via ftp?
Patches welcome.
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: Junio C Hamano @ 2006-06-16 23:21 UTC (permalink / raw)
To: David Kowis; +Cc: git
In-Reply-To: <1150494975.DBA8A55@be12.dngr.org>
David Kowis <dkowis@shlrm.org> writes:
>>> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
>>> Author: David Kowis <dkowis@kain.org>
>>> Date: Fri Jun 16 12:20:08 2006 -0500
>>>
>>> this is a multi
>>>
>>> line comment
>>> with three lines
>>>
>>>
>>> I'm using git 1.4.0. It added a blank line in there...
>>
>> Actually, this is an odd but intended behaviour ;-).
>
> Why is this behaviour intended? Just because I'm curoius. :)
You are not alone; sorry for the terse and confusing initial
response (I am just back from a long flight, finished
unpacking and quite tired).
At the lowest level of git that defines the object format, a
commit object consists of structural header in fixed format,
followed by any binary blob you feed git-commit-tree from the
standard input. I do not recall the details of the
implementation offhand, but we _might_ chomp at the first NUL
and if we did so I may say it is a bug -- commit-tree should not
care what "the log message" part consists of.
It is however quite a different story when it comes to the
higher level tools that come with git. The log summarize
facilities to let humans interact with the commits expect that a
commit log message consists of a one-line "summary", a blank
line, and then the body of the message. These "log listers" are:
. git log --pretty=oneline
. gitk
. gitweb
. gitview
. git shortlog
The "one-line summary plus body of the message" has a strong
correlation with how we communicate patches via e-mail. You do
not start a sentence on the "Subject: " header and continue on
to the body of the message, starting the body halfway of the
sentence. Instead, you try to make sure you write something
sensible by itself on the "Subject: " header to help the
recipient when later scanning for it among bunch of messages,
and you write a full paragraph that you can understand without
reading the subject line first. The following commands that
deal with e-mailed patches expect you to follow that convention:
. git am
. git applymbox
. git format-patch
Now, answer to your question why rebase bahaves that way are
because:
(1) I was lazy and reused the e-mailed patch machinery to
implement it, although rebase is something that _should_
work at a level closer to the core level than the human
level (e.g. it should be able to commute a patch that
affects binary content changes -- which it does).
(2) The user should be following the convention to make the
output from the log listers reasonable anyway, so the only
people who are harmed by reusing the e-mailed patch
machinery were people who did not finish a short-and-sweet
summary sentence on the first line, and it is better to
train users to do so anyway.
Having said that, I would say it is a bug. We should be able to
rebase, cherry-pick and/or rebase a patch with an arbitrary
binary garbage in the commit log message (I think the latter two
command do). But because of the reason (2) above, it is very
low on my priority to change it.
^ permalink raw reply
* Re: Lazy clone ideas
From: Elrond @ 2006-06-16 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <e6e1jm$tes$1@sea.gmane.org>
Jakub Narebski <jnareb <at> gmail.com> writes:
>
> I've started new thread for lazy clone ideas,
> splitting from "Figured out how to get Mozilla into git"
[...]
I like the lazy clone idea, I think, I said that earlier.
> > This would probably require Eric Biederman's "direct access to blob"
> > patches, I guess, in order to be feasible.
Are those patches allowing the git: protocol to request a list of objects
directly? (Like my "remote git-cat-file" request?)
What's the status of the patch?
> And it would need place to store URI from where to doenload objects
> on-demand: perhaps 'remote alternatives'?
Yep, that would be the next step.
Having direct access to blobs would be needed first though.
Elrond
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: Junio C Hamano @ 2006-06-16 22:52 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git, Linus Torvalds
In-Reply-To: <44931AFD.4070809@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Perhaps we shouldn't rely on stderr, and instead have a backchannel as
> part of the protocol itself.
Concurred. This was one of the thing I was planning to do
anyway.
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-16 22:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606161539t2485e3b3xa9f2852a4d2fc18f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On Fri, 2006-06-16 at 18:39 -0400, Jon Smirl wrote:
> There is a branch label for SeaMonkey_M8_BRANCH:1.36.0.4 that does
> seems to correspond to anything. Could that be the missing tag?
There's no particular reason to believe it should be; remember that
every file gets a 'magic branch' tag whenever you create a branch in the
repository, but only files with commits along that branch ever see the
revision tree information related to it, so you can expect to see many
branch tags without associated branch revisions in any particular ,v
file. Looking at the commits along 1.3.2, they don't seem particularily
related to the SeaMonkey_M8 branch.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.17-rc6-mm2
From: bert hubert @ 2006-06-16 22:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Goo GGooo, linux-kernel, git
In-Reply-To: <Pine.LNX.4.64.0606152335130.5498@g5.osdl.org>
On Thu, Jun 15, 2006 at 11:39:35PM -0700, Linus Torvalds wrote:
> Except they only work over ssh, where we have a separate channel (for
> stderr), and with the native git protocol all that nice status work just
> gets flushed to /dev/null :(
It won't help passing firewalls one bit, but you might consider using SCTP
with multiple datastreams for this - theoretically :-)
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-16 22:39 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1150496362.6983.34.camel@neko.keithp.com>
On 6/16/06, Keith Packard <keithp@keithp.com> wrote:
> On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:
> > I'm getting thousands of messages about unnamed branches and even
> > 'unnamed branch from master-UNNAMED-BRANCH'.
> >
> > How do you get unnamed branches into CVS, are these check-in errors or
> > are people actually working on unnamed branches? Or is parsecvs not
> > finding all of the branch info?
>
> branch names rely on a special 'branch tag' in the "symbols" section of
> the CVS file, but actual branches are flagged directly in the revision
> list. I don't know how it happens, but ,v files often end up with
> branches in the revision tree which haven't an associated tag. Go
> figure.
>
> For example, in the top level mozilla/Makefile.in,v file, you'll see a
> branch from version 1.36 with an initial commit 1.36.2.1. Using the
> wacky CVS branch revision numbering scheme, there should be an
> associated tag for version 1.36.0.2 (yes, the last two digits are
> flipped). But, none is present in the file.
There is a branch label for SeaMonkey_M8_BRANCH:1.36.0.4 that does
seems to correspond to anything. Could that be the missing tag?
>
> The reverse situation also occurs, with tags for branches that have no
> revisions in the file. This case makes sense -- until you make a change
> in a file along a branch, there will be no other record in the file of
> where the branch came from.
>
> I'd love to figure out a better mechanism for merging these nameless
> branches into the resulting repository, but I don't know how to
> correlate unnamed branches in one file with unnamed branches in other
> files.
>
> The current scheme of making up a fixed name and hoping that there
> aren't multiple unmamed branches from the same root is probably fraught
> with peril.
>
> --
> keith.packard@intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEky5qQp8BWwlsTdMRAvI1AJ4nXKyzeupTDarXI+yM0zvuHaCoTQCdEBYC
> Kl7lEHIJgi5Tk24quc9FZyM=
> =FA7H
> -----END PGP SIGNATURE-----
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-16 22:30 UTC (permalink / raw)
To: Niklas Frykholm, git, Juergen Ruehle
In-Reply-To: <20060616221014.GA22181@trixie.casa.cgf.cx>
On Fri, Jun 16, 2006 at 06:10:14PM -0400, Christopher Faylor wrote:
>On Fri, Jun 16, 2006 at 04:24:30PM +0200, Juergen Ruehle wrote:
>>Niklas Frykholm writes:
>> > I'm trying to use cygwin git (compiled from the 1.4.0 tarball) to create
>> > repository on a windows network share, but I get an error message.
>> >
>> > $ cd //computer/git/project
>> > $ git init-db
>> > defaulting to local storage area
>> > Could not rename the lock file?
>>
>>cygwin's rename seems to be capable of overwriting an existing target
>>only on NTFS. The following hack is a workaround, but is probably not
>>safe.
>
>Actually, Cygwin's rename has a specific check to make sure that the
>file is deleted. It tries very hard to do things the right way but if
>your samba server doesn't return the correct error code then it is
>possible that it could be confused.
>diff --git a/lockfile.c b/lockfile.c
>index 2346e0e..5e78211 100644
>--- a/lockfile.c
>+++ b/lockfile.c
>@@ -48,6 +48,7 @@ int commit_lock_file(struct lock_file *l
> strcpy(result_file, lk->filename);
> i = strlen(result_file) - 5; /* .lock */
> result_file[i] = 0;
>+ unlink(result_file);
> i = rename(lk->filename, result_file);
> lk->filename[0] = 0;
> return i;
I also meant to ask if there was an i is nonzero after the call to the
rename() above? If so, what was the errno? If not, it is a huge
problem if rename is reporting that it is able to rename a file but is
not actually doing it.
cgf
(cygwin maintainer)
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-16 22:28 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1150496362.6983.34.camel@neko.keithp.com>
On 6/16/06, Keith Packard <keithp@keithp.com> wrote:
> On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:
> > I'm getting thousands of messages about unnamed branches and even
> > 'unnamed branch from master-UNNAMED-BRANCH'.
> >
> > How do you get unnamed branches into CVS, are these check-in errors or
> > are people actually working on unnamed branches? Or is parsecvs not
> > finding all of the branch info?
>
> branch names rely on a special 'branch tag' in the "symbols" section of
> the CVS file, but actual branches are flagged directly in the revision
> list. I don't know how it happens, but ,v files often end up with
> branches in the revision tree which haven't an associated tag. Go
> figure.
>
> For example, in the top level mozilla/Makefile.in,v file, you'll see a
> branch from version 1.36 with an initial commit 1.36.2.1. Using the
> wacky CVS branch revision numbering scheme, there should be an
> associated tag for version 1.36.0.2 (yes, the last two digits are
> flipped). But, none is present in the file.
I was reading the CVS manual and it talks about magic branch number as
being the ones with zero in them. Doesn't go into a lot of detail.
Apparently they are autogenerated internally.
http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging#Magic_branch_numbers
>
> The reverse situation also occurs, with tags for branches that have no
> revisions in the file. This case makes sense -- until you make a change
> in a file along a branch, there will be no other record in the file of
> where the branch came from.
>
> I'd love to figure out a better mechanism for merging these nameless
> branches into the resulting repository, but I don't know how to
> correlate unnamed branches in one file with unnamed branches in other
> files.
>
> The current scheme of making up a fixed name and hoping that there
> aren't multiple unmamed branches from the same root is probably fraught
> with peril.
>
> --
> keith.packard@intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEky5qQp8BWwlsTdMRAvI1AJ4nXKyzeupTDarXI+yM0zvuHaCoTQCdEBYC
> Kl7lEHIJgi5Tk24quc9FZyM=
> =FA7H
> -----END PGP SIGNATURE-----
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: parsecvs and unnamed branches
From: Keith Packard @ 2006-06-16 22:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, git
In-Reply-To: <9e4733910606161444i2f996096sbd1f9b3f3ff3a32d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote:
> I'm getting thousands of messages about unnamed branches and even
> 'unnamed branch from master-UNNAMED-BRANCH'.
>
> How do you get unnamed branches into CVS, are these check-in errors or
> are people actually working on unnamed branches? Or is parsecvs not
> finding all of the branch info?
branch names rely on a special 'branch tag' in the "symbols" section of
the CVS file, but actual branches are flagged directly in the revision
list. I don't know how it happens, but ,v files often end up with
branches in the revision tree which haven't an associated tag. Go
figure.
For example, in the top level mozilla/Makefile.in,v file, you'll see a
branch from version 1.36 with an initial commit 1.36.2.1. Using the
wacky CVS branch revision numbering scheme, there should be an
associated tag for version 1.36.0.2 (yes, the last two digits are
flipped). But, none is present in the file.
The reverse situation also occurs, with tags for branches that have no
revisions in the file. This case makes sense -- until you make a change
in a file along a branch, there will be no other record in the file of
where the branch came from.
I'd love to figure out a better mechanism for merging these nameless
branches into the resulting repository, but I don't know how to
correlate unnamed branches in one file with unnamed branches in other
files.
The current scheme of making up a fixed name and hoping that there
aren't multiple unmamed branches from the same root is probably fraught
with peril.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cygwin git and windows network shares
From: Christopher Faylor @ 2006-06-16 22:10 UTC (permalink / raw)
To: Niklas Frykholm, git, Juergen Ruehle
In-Reply-To: <17554.48926.852000.679014@lapjr.intranet.kiel.bmiag.de>
On Fri, Jun 16, 2006 at 04:24:30PM +0200, Juergen Ruehle wrote:
>Niklas Frykholm writes:
> > I'm trying to use cygwin git (compiled from the 1.4.0 tarball) to create
> > repository on a windows network share, but I get an error message.
> >
> > $ cd //computer/git/project
> > $ git init-db
> > defaulting to local storage area
> > Could not rename the lock file?
>
>cygwin's rename seems to be capable of overwriting an existing target
>only on NTFS. The following hack is a workaround, but is probably not
>safe.
Actually, Cygwin's rename has a specific check to make sure that the
file is deleted. It tries very hard to do things the right way but if
your samba server doesn't return the correct error code then it is
possible that it could be confused.
cgf
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: David Kowis @ 2006-06-16 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j3gdc7t.fsf@assigned-by-dhcp.cox.net>
On Fri, 16 Jun 2006 16:55, Junio C Hamano wrote:
> David Kowis <dkowis@shlrm.org> writes:
>
>> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
>> Author: David Kowis <dkowis@kain.org>
>> Date: Fri Jun 16 12:20:08 2006 -0500
>>
>> this is a multi
>>
>> line comment
>> with three lines
>>
>>
>> I'm using git 1.4.0. It added a blank line in there...
>
> Actually, this is an odd but intended behaviour ;-).
Why is this behaviour intended? Just because I'm curoius. :)
-- David Kowis - mobile
^ permalink raw reply
* parsecvs and unnamed branches
From: Jon Smirl @ 2006-06-16 21:44 UTC (permalink / raw)
To: git
I'm getting thousands of messages about unnamed branches and even
'unnamed branch from master-UNNAMED-BRANCH'.
How do you get unnamed branches into CVS, are these check-in errors or
are people actually working on unnamed branches? Or is parsecvs not
finding all of the branch info?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* What's in cvsps.git
From: Yann Dirson @ 2006-06-16 21:44 UTC (permalink / raw)
To: GIT list; +Cc: cvsps, David D. Kilzer, Marcus Crafter
In-Reply-To: <20060611122746.GB7766@nowhere.earth>
I have now added all patches gathered from here, as well as those in
the current Debian package. Still have to dig other distros.
Note the log-length limit increment is being superceded by a dynamic
allocation patch.
Repo URL: http://ydirson.free.fr/soft/git/cvsps.git
==============================
* master has:
Alexander Litvinov:
Handle cvs repo with modules
Anand Kumria:
FreeBSD isn't evil - just misguided
David D. Kilzer:
cvsps: should ignore TRUNK branch if it exists in log
Dynamically allocate the log buffer to prevent warning messages
Linus Torvalds:
Increase log-length limit to 64kB
Improve handling of file collisions in the same patchset
Fix branch ancestor calculation
Pavel Roskin:
Use __linux__ conditional, not LINUX.
Use INADDR_NONE instead of -1 to check inet_addr() result
Roberto C. Sanchez:
Diff opts typo fix.
Yann Dirson:
Call cvs with -q flag when fetching the log
Dependency handling
* to-check additionally has:
Linus Torvalds:
Make time ordering less important than revision ordering
* dev branches still have incomplete stuff, so I don't list it
here.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Collecting cvsps patches
From: Yann Dirson @ 2006-06-16 21:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Mansfield, Pavel Roskin, GIT list, cvsps
In-Reply-To: <Pine.LNX.4.64.0606130841200.5498@g5.osdl.org>
On Tue, Jun 13, 2006 at 08:47:15AM -0700, Linus Torvalds wrote:
>
> On Tue, 13 Jun 2006, Yann Dirson wrote:
> >
> > I have setup a Q&D page at
> > http://ydirson.free.fr/en/software/scm/cvsps.html to link to.
> >
> > I'll expand it later with more information.
>
> Will you be able to set up gitweb on that site, perhaps?
No, CGI's on this hosting platform are restricted to ISP-provided
ones.
Do you think it would be adequate to have this repo hosted on
kernel.org ?
> Also, I guess that patch I posted in the "cvsps wierdness" thread (yeah,
> yeah, bad spelling, but it wasn't me who started the thread) should
> probably be added, since it fixed at least one test-case.
>
> Although it should probably get more testing with a bigger and more
> real-life repository..
Added, in the to-check branch. At least the idea is sound.
Anyway, there are quite a number of hairy repos out there, which
appear to cause problem to cvsps. I'll see if I can identify more
problems precisely - I have already collected a handful of them to
http://bugs.debian.org/cvsps.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Collecting cvsps patches
From: Jakub Narebski @ 2006-06-16 21:31 UTC (permalink / raw)
To: git
In-Reply-To: <20060616212334.GN7766@nowhere.earth>
Yann Dirson wrote:
> On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
>> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>>
>> > http://ydirson.free.fr/soft/git/cvsps.git
>>
>> I think you need to chmod +x hooks/post-update
>>
>> and then run 'git-update-server-info'.
>
> Unfortunately, I only have FTP access to push to this site, so I have
> to run git-update-server-info myself, and occasionally forget. I'll
> have to bring up-to-date my old cg-ftppush script some day :)
Or extend git to allow push/pull also via ftp?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: Junio C Hamano @ 2006-06-16 21:25 UTC (permalink / raw)
To: David Kowis; +Cc: git
In-Reply-To: <4492E8F9.4000106@shlrm.org>
David Kowis <dkowis@shlrm.org> writes:
> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
> Author: David Kowis <dkowis@kain.org>
> Date: Fri Jun 16 12:20:08 2006 -0500
>
> this is a multi
>
> line comment
> with three lines
>
>
> I'm using git 1.4.0. It added a blank line in there...
Actually, this is an odd but intended behaviour ;-).
^ permalink raw reply
* Re: Collecting cvsps patches
From: Yann Dirson @ 2006-06-16 21:23 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <e6jj39$6ua$1@sea.gmane.org>
On Mon, Jun 12, 2006 at 11:27:37AM +0000, Anand Kumria wrote:
> On Mon, 12 Jun 2006 00:42:05 +0200, Yann Dirson wrote:
>
> > http://ydirson.free.fr/soft/git/cvsps.git
>
> I think you need to chmod +x hooks/post-update
>
> and then run 'git-update-server-info'.
Unfortunately, I only have FTP access to push to this site, so I have
to run git-update-server-info myself, and occasionally forget. I'll
have to bring up-to-date my old cg-ftppush script some day :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ 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