* 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
* Re: 2.6.17-rc6-mm2
From: H. Peter Anvin @ 2006-06-16 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Goo GGooo, linux-kernel, git
In-Reply-To: <Pine.LNX.4.64.0606152335130.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> Actually, the really irritating thing is that we actually generate all
> these nice status updates, which just makes pulling and cloning a lot more
> comfortable, because you actually see what is going on, and what to
> expect.
>
> 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 :(
>
> Dang. It's literally the most irritating part of the thing: the protocol
> itself is exactly the same whether you go over ssh:// or over git://, but
> that visual information about what is going on is missing, and it's
> surprisingly important from a usability standpoint.
>
Perhaps we shouldn't rely on stderr, and instead have a backchannel as part of the
protocol itself. After all, the protocol already does packetization, so all it needs is a
reliable way to pick out the error/status packets; we could even combine that with a
machine-readable code (like SMTP et al) that could get interpreted by the other side as
needed.
-hpa
^ permalink raw reply
* Re: Autoconf/Automake
From: Petr Baudis @ 2006-06-16 20:42 UTC (permalink / raw)
To: Yann Dirson; +Cc: Johannes Schindelin, Phil Richards, git
In-Reply-To: <20060616201715.GM7766@nowhere.earth>
Dear diary, on Fri, Jun 16, 2006 at 10:17:15PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:
> > > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > > > As for now, I fail to see why the current system is not adequate for git!
> > >
> > > I can reassure you, gazillions of people still fail to see why cvs is
> > > not adequate for their project. And the ratio of devs in the
> > > corporate world not knowning git to those not knowning cvs is far
> > > superior to 2. And everyone here knows cvs is not more adequate than
> > > git for so many tasks :)
> >
> > You know as well as I that this comparison is unfair. I am _NOT_ a
> > corporate person. I hope that you do not judge me as a complete airhead.
>
> Well, I have to apologize - especially after looking closer at the
> current Makefile. I think I understand now why autoconf was suggested
> in the first place, but it what it would achieve would mostly moving
> the ifdef's to configure.ac, which would not be such a gain anyway.
Except that then I don't need to bother manually adding NO_EXPAT to the
makefile on all systems I compile git on.
Yes, it's not a huge bother per se, but since almost all other
non-obscure projects do figure these things out automagically, git kind
of stands out negatively here. "Wah, it needs me tweak the Makefile to
be able to compile it."
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Autoconf/Automake
From: Yann Dirson @ 2006-06-16 20:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Phil Richards, git
In-Reply-To: <Pine.LNX.4.63.0606160053560.7480@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:
> > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > > As for now, I fail to see why the current system is not adequate for git!
> >
> > I can reassure you, gazillions of people still fail to see why cvs is
> > not adequate for their project. And the ratio of devs in the
> > corporate world not knowning git to those not knowning cvs is far
> > superior to 2. And everyone here knows cvs is not more adequate than
> > git for so many tasks :)
>
> You know as well as I that this comparison is unfair. I am _NOT_ a
> corporate person. I hope that you do not judge me as a complete airhead.
Well, I have to apologize - especially after looking closer at the
current Makefile. I think I understand now why autoconf was suggested
in the first place, but it what it would achieve would mostly moving
the ifdef's to configure.ac, which would not be such a gain anyway.
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: Running parse cvs
From: Johannes Schindelin @ 2006-06-16 19:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, git, Keith Packard
In-Reply-To: <Pine.LNX.4.64.0606161220360.5498@g5.osdl.org>
Hi,
On Fri, 16 Jun 2006, Linus Torvalds wrote:
> Valgrind is da bomb.
Now you are officially on the NSA black list.
^ permalink raw reply
* Re: Running parse cvs
From: Linus Torvalds @ 2006-06-16 19:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: git, Keith Packard
In-Reply-To: <9e4733910606161147m403a3f36r6657bd7b620958f3@mail.gmail.com>
On Fri, 16 Jun 2006, Jon Smirl wrote:
>
> I am running the latest parsecvs from your git tree. I am hitting a quick gpf.
If it's really quick, run it under valgrind. It will slow down things
enormously, but if it happens early on, you won't care, and it will
generally give a much better reason for why the problem happened than the
glibc malloc debugger will.
Ie just
valgrind --tool=memcheck parsecvs ..
should do it.
Valgrind is da bomb.
Linus
^ 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