* Re: Challenge of setting up git server (repository). Please help!
From: Deskin Miller @ 2008-11-20 23:08 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <146002.93100.qm@web37908.mail.mud.yahoo.com>
On Thu, Nov 20, 2008 at 02:43:30PM -0800, Gary Yang wrote:
> Many thanks for your explanation. I hope I understand what you said. I deleted /etc/xinetd.d/git-daemon. Then, I tried to git pull. But, I got connection refused. git uses port 9418. Should I request IT Admin to open the port 9418 for me?
You'll need port 9418 open, yes; but since it's an unprivileged port (1024 or
higher), you can use it as a regular user and don't need IT intervention unless you have some firewall set up which they need to override for you.
> git pull git://git.mycompany.com/pub/git/u-boot.git HEAD
> git.mycompany.com[0: 10.66.4.168]: errno=Connection refused
> fatal: unable to connect a socket (Connection refused)
It's possible, and likely simpler, to use git-daemon directly, instead of
having it be managed by inetd; especially for initial debugging, I'd recommend
getting that working before trying to determine if you're having issues with
inetd configuration: to do so, just run git-daemon with all the same arguments
except for --inetd.
You said you deleted the xinetd config, but that's only relevant if your
machine actually uses inetd as its super-server. You should do 'ps -A | grep
inetd' (which will match either inetd or xinetd), and see which one is running.
If it's inetd, you should be all set, and the issue doesn't look like inetd
(assuming you sent it a signal to reload its config file). If on the other
hand xinetd is running, you need to use the xinetd config file, and fix the
server_args to look like the arguments which exist in the inetd file. Again,
you need to signal xinetd at this point to reload its configuration.
Based on the linux kernel version you're reporting, I'm guessing you have some
sort of Red Hat based system, which uses xinetd to the best of my knowledge.
> Another question, I got no output of "netstat | grep 9418". It means no program runs at port 9418 at the public repository machine. Is it correct?
>
> netstat | grep 9418
netstat translates IP addresses to dns names, and ports to service names by
default; so, given the line listed in /etc/services, this will show
'0.0.0.0:git' or something. Also, it lists established connections, not
listening sockets, by default. I'd recommend spending some time with the man
page if you're going to use it to debug your setup.
Deskin Miller
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-20 22:43 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081120221321.GA6349@euler>
Deskin,
Many thanks for your explanation. I hope I understand what you said. I deleted /etc/xinetd.d/git-daemon. Then, I tried to git pull. But, I got connection refused. git uses port 9418. Should I request IT Admin to open the port 9418 for me?
git pull git://git.mycompany.com/pub/git/u-boot.git HEAD
git.mycompany.com[0: 10.66.4.168]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
Another question, I got no output of "netstat | grep 9418". It means no program runs at port 9418 at the public repository machine. Is it correct?
netstat | grep 9418
--- On Thu, 11/20/08, Deskin Miller <deskinm@umich.edu> wrote:
> From: Deskin Miller <deskinm@umich.edu>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Thursday, November 20, 2008, 2:13 PM
> On Thu, Nov 20, 2008 at 01:39:12PM -0800, Gary Yang wrote:
> >
> > I am working on setting up a git server so that people
> can clone, pull and push their code at
> git.mycompany.com/pub/git+project path.
> > However, I am having challenges. For people who setup
> their git servers, please share your experneces with me and
> tell me what I did wrong.
> > I greatly appreciate it.
> >
> > After I made configurations, I ran the command, git
> update-server-info at the public repository machine. But, I
> got the error.
> >
> > git pull http://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > fatal:
> http://git.mycompany.com/pub/git/u-boot.git/info/refs not
> found: did you run git update-server-info on the server?
> >
> > The file /pub/git/u-boot.git/info/refs dose exist.
> >
> > cat /pub/git/u-boot.git/info/refs
> > 87ee4576c4c31b7046fe2bbbdf309eaba5c3f346
> refs/heads/master
> >
> > My question:
> >
> > Is the contet of /pub/git/u-boot.git/hooks/post-update
> correct? Should I change "exec
> git-update-server-info" to "exec git
> update-server-info"?
> >
> > cat /pub/git/u-boot.git/hooks/post-update
> > #!/bin/sh
> > #
> > # An example hook script to prepare a packed
> repository for use over
> > # dumb transports.
> > #
> > # To enable this hook, rename this file to
> "post-update".
> > exec git-update-server-info
> >
> > I tried and changed "exec
> git-update-server-info" to "exec git
> update-server-info" in
> /pub/git/u-boot.git/hooks/post-update. But, I still got same
> error.
> > git pull http://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > fatal:
> http://git.mycompany.com/pub/git/u-boot.git/info/refs not
> found: did you run git update-server-info on the server?
> >
> > Which one is correct? "exec
> git-update-server-info" or "exec git
> update-server-info"? Eventhogh none of them working.
> >
> > Below are my settings:
> >
> > grep 9418 /etc/services
> > git 9418/tcp # Git
> Version Control System
> >
> >
> > grep git /etc/inetd.conf
> > git stream tcp nowait nobody
> /usr/local/libexec/git-core/git-daemon git-daemon --inetd
> --export-all /pub/git
> >
> >
> > cat /etc/xinetd.d/git-daemon
> > # default: off
> > # description: The git server offers access to git
> repositories
> > service git
> > {
> > disable = no
> > type = UNLISTED
> > port = 9418
> > socket_type = stream
> > wait = no
> > user = nobody
> > server =
> /usr/local/libexec/git-core/git-daemon
> > server_args = --inetd --export-all
> --base-path=/pub/git
> > log_on_failure += USERID
> > }
> >
> >
> > I am running git at Linux box:
> > uname -a
> > Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7
> 13:56:44 EST 2007 x86_64 GNU/Linux
> >
> > Are there anything wrong? Please let me know.
>
> You tried to fetch from a http url, but your settings make
> no mention of
> running a web server. git-update-server-info is only
> relevant in the context
> of using a web server to serve git repositories via the
> same http protocol as
> is used by web servers everywhere. git-daemon, on the
> other hand, which is
> what you show configured here, is used to serve git
> repositories via a git://
> url. Its configuration has no effect on whether using http
> to fetch a git
> repository will work or not.
>
> Either use a git:// url to fetch the project, or set up a
> web server which
> serves stuff under /pub/git.
>
> I'll also mention that you appear to have configuration
> for both inetd and
> xinetd, which are two generally mutually-exclusive
> 'super-servers'; and
> furthermore, your configurations are inconsistent in the
> arguments they pass to
> git-daemon: it looks like, were you to replace http:// with
> git://, the inetd
> config would work as listed, while xinetd would not.
>
> Hope that helps,
> Deskin Miller
>
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Asheesh Laroia @ 2008-11-20 22:04 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <829533.97868.qm@web37906.mail.mud.yahoo.com>
On Thu, 20 Nov 2008, Gary Yang wrote:
> I am working on setting up a git server so that people can clone, pull
> and push their code at git.mycompany.com/pub/git+project path. However,
> I am having challenges. For people who setup their git servers, please
> share your experneces with me and tell me what I did wrong. I greatly
> appreciate it.
Have you tried just using gitosis? It's very nice.
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
is what I read to get started.
Keep in mind you can't clone a git repository with no commits.
-- Asheesh.
--
You look tired.
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Junio C Hamano @ 2008-11-20 22:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git, Shawn O. Pearce
In-Reply-To: <fcaeb9bf0811200726x1f2956c6k6f2ca16543a0fbc@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>> Yes, I also dislike the subtlety, but my "obvious" idea was something
>> like:
>>
>> for i in 1 2 sub/1 sub/2; do
>> touch $i
>> done
>>
>> which just seemed clunky. But:
>>
>>
>> > - touch 1 2 sub/1 sub/2 &&
>> > + touch ./1 ./2 sub/1 sub/2 &&
>>
>>
>> this is less clunky, and I have confirmed that it solves the problem. I
>> just wasn't clever enough to think of it in the first place. ;)
>
> Thanks for catching. The last half also has the same problem. Another
> way is maybe just stay away for those numbers, naming the files by
> ... Just wonder if we could have some ways to automatically
> catch this kind of bug in the future.
A tool to do so essentially amounts to coming up with a set of POSIX
command line tools that know and flag all the known bugs broken platform
tools have, at the same time producing a reasonable end result so that it
can continue running and detecting more portability issues in the scripts.
Using dash as the shell helps to catch use of constructs outside POSIX,
running various GNU tools with POSIXLY_CORRECT=YesPlease may have similar
effects, but quirks specific to particular platforms like the above is
fundamentally hard to check. Running autobuilder farms like Jeff does is
probably the best thing we can do.
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Deskin Miller @ 2008-11-20 22:13 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <829533.97868.qm@web37906.mail.mud.yahoo.com>
On Thu, Nov 20, 2008 at 01:39:12PM -0800, Gary Yang wrote:
>
> I am working on setting up a git server so that people can clone, pull and push their code at git.mycompany.com/pub/git+project path.
> However, I am having challenges. For people who setup their git servers, please share your experneces with me and tell me what I did wrong.
> I greatly appreciate it.
>
> After I made configurations, I ran the command, git update-server-info at the public repository machine. But, I got the error.
>
> git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
> fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
>
> The file /pub/git/u-boot.git/info/refs dose exist.
>
> cat /pub/git/u-boot.git/info/refs
> 87ee4576c4c31b7046fe2bbbdf309eaba5c3f346 refs/heads/master
>
> My question:
>
> Is the contet of /pub/git/u-boot.git/hooks/post-update correct? Should I change "exec git-update-server-info" to "exec git update-server-info"?
>
> cat /pub/git/u-boot.git/hooks/post-update
> #!/bin/sh
> #
> # An example hook script to prepare a packed repository for use over
> # dumb transports.
> #
> # To enable this hook, rename this file to "post-update".
> exec git-update-server-info
>
> I tried and changed "exec git-update-server-info" to "exec git update-server-info" in /pub/git/u-boot.git/hooks/post-update. But, I still got same error.
> git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
> fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
>
> Which one is correct? "exec git-update-server-info" or "exec git update-server-info"? Eventhogh none of them working.
>
> Below are my settings:
>
> grep 9418 /etc/services
> git 9418/tcp # Git Version Control System
>
>
> grep git /etc/inetd.conf
> git stream tcp nowait nobody /usr/local/libexec/git-core/git-daemon git-daemon --inetd --export-all /pub/git
>
>
> cat /etc/xinetd.d/git-daemon
> # default: off
> # description: The git server offers access to git repositories
> service git
> {
> disable = no
> type = UNLISTED
> port = 9418
> socket_type = stream
> wait = no
> user = nobody
> server = /usr/local/libexec/git-core/git-daemon
> server_args = --inetd --export-all --base-path=/pub/git
> log_on_failure += USERID
> }
>
>
> I am running git at Linux box:
> uname -a
> Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 GNU/Linux
>
> Are there anything wrong? Please let me know.
You tried to fetch from a http url, but your settings make no mention of
running a web server. git-update-server-info is only relevant in the context
of using a web server to serve git repositories via the same http protocol as
is used by web servers everywhere. git-daemon, on the other hand, which is
what you show configured here, is used to serve git repositories via a git://
url. Its configuration has no effect on whether using http to fetch a git
repository will work or not.
Either use a git:// url to fetch the project, or set up a web server which
serves stuff under /pub/git.
I'll also mention that you appear to have configuration for both inetd and
xinetd, which are two generally mutually-exclusive 'super-servers'; and
furthermore, your configurations are inconsistent in the arguments they pass to
git-daemon: it looks like, were you to replace http:// with git://, the inetd
config would work as listed, while xinetd would not.
Hope that helps,
Deskin Miller
^ permalink raw reply
* Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-20 21:39 UTC (permalink / raw)
To: git
I am working on setting up a git server so that people can clone, pull and push their code at git.mycompany.com/pub/git+project path.
However, I am having challenges. For people who setup their git servers, please share your experneces with me and tell me what I did wrong.
I greatly appreciate it.
After I made configurations, I ran the command, git update-server-info at the public repository machine. But, I got the error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
The file /pub/git/u-boot.git/info/refs dose exist.
cat /pub/git/u-boot.git/info/refs
87ee4576c4c31b7046fe2bbbdf309eaba5c3f346 refs/heads/master
My question:
Is the contet of /pub/git/u-boot.git/hooks/post-update correct? Should I change "exec git-update-server-info" to "exec git update-server-info"?
cat /pub/git/u-boot.git/hooks/post-update
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".
exec git-update-server-info
I tried and changed "exec git-update-server-info" to "exec git update-server-info" in /pub/git/u-boot.git/hooks/post-update. But, I still got same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
Which one is correct? "exec git-update-server-info" or "exec git update-server-info"? Eventhogh none of them working.
Below are my settings:
grep 9418 /etc/services
git 9418/tcp # Git Version Control System
grep git /etc/inetd.conf
git stream tcp nowait nobody /usr/local/libexec/git-core/git-daemon git-daemon --inetd --export-all /pub/git
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
I am running git at Linux box:
uname -a
Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 GNU/Linux
Are there anything wrong? Please let me know.
^ permalink raw reply
* Re: fatal: did you run git update-server-info on the server? mv post-update.sample post-update
From: Gary Yang @ 2008-11-20 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811201204300.30769@pacific.mpi-cbg.de>
I ran the command, git update-server-info at the public repository machine. But, I still got the same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
The file /pub/git/u-boot.git/info/refs do exist.
cat /pub/git/u-boot.git/info/refs
87ee4576c4c31b7046fe2bbbdf309eaba5c3f346 refs/heads/master
My question:
Is the contet of /pub/git/u-boot.git/hooks/post-update correct? Should I change "exec git-update-server-info" to "exec git update-server-info"?
cat /pub/git/u-boot.git/hooks/post-update
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".
exec git-update-server-info
I tried and changed "exec git-update-server-info" to "exec git update-server-info" in /pub/git/u-boot.git/hooks/post-update. But, I still got same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
Which one is correct? "exec git-update-server-info" or "exec git update-server-info"? Eventhogh none of them working.
Below are my settings:
grep 9418 /etc/services
git 9418/tcp # Git Version Control System
grep git /etc/inetd.conf
git stream tcp nowait nobody /usr/local/libexec/git-core/git-daemon git-daemon --inetd --export-all /pub/git
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
I am running git at Linux box:
uname -a
Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 GNU/Linux
Are there anything wrong? Please let me know.
--- On Thu, 11/20/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Subject: Re: fatal: did you run git update-server-info on the server? mv post-update.sample post-update
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Thursday, November 20, 2008, 3:05 AM
> Hi,
>
> On Wed, 19 Nov 2008, Gary Yang wrote:
>
> > I did not run post-update at public repository
> manually. Do I need to
> > run it for the very first time?
>
> You need to run it when you installed the hook _after_
> seeing the message
> "did you run...".
>
> Ciao,
> Dscho
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] Updated Swedish translation (514t0f0u).
From: Shawn O. Pearce @ 2008-11-20 19:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Peter Krefting, Git Mailing List, Mikael Magnusson
In-Reply-To: <49257790.5010105@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Peter Krefting wrote:
>>
>>>> +msgid "Blame History Context Radius (days)"
>>>> +msgstr "Historikkontextradie för klandring (dagar)"
>>> At least a 100 points in scrabble for "historikkontextradie". How about
>>> "Historikradie för klandring (dagar)"?
>>
>> I struggled with this one. I still haven't got the faintest clue what
>> it is all about, but I have changed it as you suggested...
>
> I *think* it's about how many days to go back when viewing blame output
> for the selected file. Shawn, can you enlighten us here?
Yes, exactly. It tells git-gui what to pass to gitk. When you are in
the blame viewer you can open a "gitk --since=$d.days $commit -- $path"
window and $d is the property this message names.
--
Shawn.
^ permalink raw reply
* Re: git and mtime
From: Joey Hess @ 2008-11-20 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0811201223300.19665@iabervon.org>
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
On Thu, 20 Nov 2008, Roger Leigh wrote:
> Except in this case I'm storing the content of *tarballs* (along with
> pristine-tar). I'm committing exactly what's in the tarball with
> no changes (this is a requirement). I can't change the source prior
> to commit.
Note that pristine-tar will work no matter what the mtimes or other file
metadata are, none of that affects generation of deltas or regeneration
of tarballs from them.
Also, the source you commit does not really have to be identical to
what's in the tarball. (Despite what it may say in the man page. ;-)
A larger delta will be generated if something is different.
So, three possible approaches:
1. Run make or whatever you need to do before running pristine-tar,
and put up with a larger delta.
2. Before building, you could use pristine-tar to extract the original
tarball, and then have a program examine that tarball, and reset the
mtimes in your build tree to match the mtimes of files in it.
(Or you could duplicate the info with metastore -m, which could be
restored quicker.)
3. Store uncompressed tarballs in git, so that they will pack
efficiently, and use pristine-gz to regenerate the pristine .tar.gz.
Only mentioned because this could be more space efficient than option
#1, if the pristine-tar deltas get too large.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] sha1_file: avoid bogus "file exists" error message
From: Joey Hess @ 2008-11-20 18:56 UTC (permalink / raw)
To: Git List
This avoids the following misleading error message:
error: unable to create temporary sha1 filename ./objects/15: File exists
mkstemp can fail for many reasons, one of which, ENOENT, can occur if
the directory for the temp file doesn't exist. create_tmpfile tried to
handle this case by always trying to mkdir the directory, even if it
already existed. This caused errno to be clobbered, so one cannot tell
why mkstemp really failed, and it truncated the buffer to just the
directory name, resulting in the strange error message shown above.
Note that in both occasions that I've seen this failure, it has not been
due to a missing directory, or bad permissions, but some other, unknown
mkstemp failure mode that did not occur when I ran git again. This code
could perhaps be made more robust by retrying mkstemp, in case it was a
transient failure.
Signed-off-by: Joey Hess <joey@kitenet.net>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..927fb64 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2231,7 +2231,7 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
memcpy(buffer, filename, dirlen);
strcpy(buffer + dirlen, "tmp_obj_XXXXXX");
fd = mkstemp(buffer);
- if (fd < 0 && dirlen) {
+ if (fd < 0 && dirlen && errno == ENOENT) {
/* Make sure the directory exists */
memcpy(buffer, filename, dirlen);
buffer[dirlen-1] = 0;
--
1.5.6.5
^ permalink raw reply related
* Re: New converstion tool: svn2git.py
From: Daniel Barkalow @ 2008-11-20 18:49 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: git
In-Reply-To: <20081119191320.GA20870@arctrix.com>
On Wed, 19 Nov 2008, Neil Schemenauer wrote:
> Hi,
>
> I'm working on a tool to do conversions from SVN to git using a SVN
> dump. It's in early development but perhaps some people would be
> interested in it:
>
> http://python.ca/nas/python/svn2git.py
>
> I would like to improve it so that it intelligently converts SVN
> branches and tags into git branches (when possible). The basic idea
> is to map SVN paths into git branches, e.g. trunk -> master,
> branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
> SVN dump actions like:
>
> Node-path: branches/foo
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk
>
> need to be detected and the commit needs to performed with the
> correct parent. One complication is that SVN can create a branch or
> tag from anywhere, for example, the action
>
> Node-path: tags/bar
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk/subdir
>
> would create tags/bar based on revision 3 of trunk/subdir. There
> doesn't seem to be a good way to convert that into git. I was
> thinking that the tags-bar branch in that case would have no parent.
Probably the best thing in git would be to have the parent of the initial
commit on that branch be revision 3 of trunk; it will look like a big
rename of everything from subdir/* into the project root directory, which
is essentially what happened.
> Would git still efficently pack that or would you end up with extra
> blobs?
git will only ever store a single copy of identical file contents,
regardless of anything at all. Furthermore, when making a pack, git
compresses everything in the pack against everything else in the pack. Its
heuristics also ignore the leading directory names in guessing which blobs
are likely to help in compression (because there's a good chance that
anything named "Makefile" anywhere is useful in compressing anything else
named "Makefile").
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git and mtime
From: Matthias Kestenholz @ 2008-11-20 18:36 UTC (permalink / raw)
To: Roger Leigh; +Cc: Andreas Ericsson, Christian MICHON, git
In-Reply-To: <20081120151925.GE6023@codelibre.net>
On 20.11.2008, at 16:19, Roger Leigh wrote:
>>
>> Then write a hook for it. You agree that for most users this will be
>> totally insane, and yet you request that it's added in a place where
>> everyone will have to pay the performance/diskspace penalty for it
>> but only a handful will get any benefits. That's patently absurd.
>
> The cost is tiny. The extra space would be smaller than a single
> SHA1 hash.
No, the cost is huge. The SHA-1 for the tree with _exactly the same
contents_ will be different, just because f.e you applied a patch one
second earlier than I did, and that's completely insane. Git is purely
a content tracker as has been said numerous times on this mailing
list, and that is for good reasons. If the tree entries change just
because some timestamps are different, the CPU time needed to
generate a diff will grow by a big amount of time.
Atempts to add additional information to the basic git objects have
failed several times, and yours will probably fail too since there are
numerous reasons why you do _not_ want a timestamp in the tree
_and_ there are several workarounds for your problem, which at
least in my opinion seem much less insane than adding timestamps...
>> Especially since there are such easy workarounds that you can put in
>> place yourself instead.
>
^ permalink raw reply
* Re: [PATCH v2] Document levenshtein.c
From: Johannes Schindelin @ 2008-11-20 18:31 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Samuel Tardieu, Junio C Hamano, Git List
In-Reply-To: <1227201710.22668.2.camel@ld0161-tx32>
Hi,
On Thu, 20 Nov 2008, Jon Loeliger wrote:
> On Thu, 2008-11-20 at 14:27 +0100, Johannes Schindelin wrote:
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> > + * This implementation allows the costs to be weighted:
> > + *
> > + * - w (as in "sWap")
> > + * - s (as in "Substition")
> > + * - a (for insertion, AKA "Add")
> > + * - d (as in "Deletion")
> > + *
>
> I'm not sure what "Substition" is besides a misspelling.
It is a msipeling.
Thanks,
Dscho
^ permalink raw reply
* Re: git and mtime
From: Daniel Barkalow @ 2008-11-20 17:59 UTC (permalink / raw)
To: Roger Leigh; +Cc: Christian MICHON, git
In-Reply-To: <20081120112708.GC22787@ravenclaw.codelibre.net>
On Thu, 20 Nov 2008, Roger Leigh wrote:
> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
> > On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > > Would it be possible for git to store the mtime of files in the tree?
> > >
> > > This would make it possible to do this type of work in git, since it's
> > > currently a bit random as to whether it works or not. This only
> > > started when I upgraded to an amd64 architecture from powerpc32,
> > > I guess it's maybe using high-resolution timestamps.
> > >
> >
> > beside the obvious answer it comes back often as a request, it is
> > possible in theory to create a shell script which, for each file
> > present in the sandbox in the current branch, would find the mtime of
> > the last commit on that file (quite an expensive operation) and apply
> > it.
>
> Surely this is only expensive because you're not already storing the
> information in the tree; if it was there, it would be (relatively)
> cheap? You could even compare the old and new trees to see if you
> needed to touch a file at all.
>
> > You should store mostly content of source files. You should do a make
> > in your first cloned repo at least once before committing anything to
> > the repo. That's what I did and I saved days...
>
> Except in this case I'm storing the content of *tarballs* (along with
> pristine-tar). I'm committing exactly what's in the tarball with
> no changes (this is a requirement). I can't change the source prior
> to commit.
Can you store the tarballs in the repository, instead of the contents of
the tarballs? The tarballs will contain the dates you want, and you can
obviously get tar to set the timestamps the way you want. (Then you add a
higher-level Makefile that knows how to unpack the tarball to a directory,
maintaining the timestamps, patch anything you're changing, and run make
in that directory.)
That is to say, from your perspective, the sources include the upstream
distributed tarballs, but the individual files in upstream tarballs aren't
source files for you, since you can't (by policy) modify them (within the
pristine tarball). If you want to change the sources of the packaged
project, you add a patch file to do it, rather than simply changing the
source (which, as you say, you're required not to do).
Git really wants to store the inputs to your workflow, each of which might
change independently. That's why the files in your work tree have
timestamps based on when they came to be in your work tree (get set to the
current time whenever git puts different content there, and leaves them
unchanged if their contents don't change when moving from commit to
commit). The "sources" in your workflow are a different set of files from
the sources in the project, and git really wants *your* repository to
match *your* workflow and not the workflow of the upstream project, when
you're acting as a packager rather than an upstream developer.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] Document levenshtein.c
From: Sverre Rabbelier @ 2008-11-20 17:48 UTC (permalink / raw)
To: Jon Loeliger
Cc: Johannes Schindelin, Samuel Tardieu, Junio C Hamano, Git List
In-Reply-To: <1227201710.22668.2.camel@ld0161-tx32>
On Thu, Nov 20, 2008 at 18:21, Jon Loeliger <jdl@freescale.com> wrote:
> Were these supposed to be examples or definitions?
> The first looks like a definition by example.
> I'm not sure what "Substition" is besides a misspelling.
> Is it the definition "Substitution"? Or was it an
> example "Substitition" poorly spelled?
> The final two look like straight definitions.
Err, I'm pretty sure it's documenting the parameters?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: René Scharfe @ 2008-11-20 17:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491DE6CC.6060201@op5.se>
Andreas Ericsson schrieb:
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?
Fine with me.
Thanks,
René
^ permalink raw reply
* Re: [PATCH v2] Document levenshtein.c
From: Jon Loeliger @ 2008-11-20 17:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Samuel Tardieu, Junio C Hamano, Git List
In-Reply-To: <alpine.DEB.1.00.0811201426100.30769@pacific.mpi-cbg.de>
On Thu, 2008-11-20 at 14:27 +0100, Johannes Schindelin wrote:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> + * This implementation allows the costs to be weighted:
> + *
> + * - w (as in "sWap")
> + * - s (as in "Substition")
> + * - a (for insertion, AKA "Add")
> + * - d (as in "Deletion")
> + *
Were these supposed to be examples or definitions?
The first looks like a definition by example.
I'm not sure what "Substition" is besides a misspelling.
Is it the definition "Substitution"? Or was it an
example "Substitition" poorly spelled?
The final two look like straight definitions.
Thanks,
jdl
^ permalink raw reply
* Re: Whats happening with git-notes?
From: Jeff King @ 2008-11-20 16:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tim Ansell, git
In-Reply-To: <alpine.DEB.1.00.0811201410320.30769@pacific.mpi-cbg.de>
On Thu, Nov 20, 2008 at 02:12:54PM +0100, Johannes Schindelin wrote:
> The same goes on here. I wanted to take Peff's idea -- that hadn't
> occurred to me back when I tried to help Johan with his notes idea --
> which is to read in the whole notes tree into a singleton when needed, and
> incorporate it into my existing test framework.
>
> Maybe I'll find time later today.
In case you do work on it, let me quickly communicate the two thoughts I
have had since the GitTogether (and you can feel free to ignore them,
but I want to try to say them before you code something differently,
so you at least have the _choice_ of ignoring them. :) ).
One is some thoughts on naming, which I already articulated here:
http://article.gmane.org/gmane.comp.version-control.git/100402
The other is on speeding up tree lookup. I think the "notes as a git
tree" is sound, but as we obviously realized, somewhat slow. So the
"speeding up notes" code is really about "speeding up tree lookup". And
while it would be nice for pack v4 to fix this for free, I don't think
we want to wait for that. And I think the "build a hash on the fly"
approach that I posted earlier is a sensible way to go.
_But_ where I think we should differ from that patch is that any notes
speedup should really be about a generic interface for speeding up tree
lookup. That is, it should come in the generic form of:
void tree_study(struct tree_study_context *c, struct tree *tree);
void tree_study_lookup(struct tree_study_context *c, const char *name);
where "tree_study" spends some cycles to make "tree_study_lookup" much
faster. And obviously most tree lookups wouldn't want to make this
tradeoff, but there may be a few other places that look in the same tree
several times, and we can benchmark them to see if they benefit. And if
and when faster non-studied tree lookup comes about, we can adjust the
tree studying algorithm easily.
-Peff
^ permalink raw reply
* Re: Whats happening with git-notes?
From: Jeff King @ 2008-11-20 16:39 UTC (permalink / raw)
To: Tim Ansell; +Cc: git
In-Reply-To: <1227183162.23155.32.camel@vaio>
On Thu, Nov 20, 2008 at 11:12:42PM +1100, Tim Ansell wrote:
> I was just wondering what is happening with git notes stuff? I really
> like the idea of being able to annotate commits with various
> information.
It's on my todo list, but I doubt I will get to it for at least another
week. For what was said since then, try this thread:
http://thread.gmane.org/gmane.comp.version-control.git/100533
and this message from another thread:
http://article.gmane.org/gmane.comp.version-control.git/100402
-Peff
^ permalink raw reply
* Media repositories and memory usage
From: Nguyen Thai Ngoc Duy @ 2008-11-20 16:19 UTC (permalink / raw)
To: Git Mailing List, Tim Ansell
Hi,
There is another aspect I did not see Tim mention in his slides:
memory usage with large blobs. Git has tradition of loading the whole
blob in memory for easy manipulation. It could consume a lot of memory
in large blob case (and particularly worse in mingw port because it
does not support mmap).
I see these operations that need access to blobs:
1. checkout blobs
2. checkin blobs
3. diff/delta blobs
Diffing blobs should be avoided any way for large blobs. Checking in
blobs does not require lots of memory. I'm working on checkout case to
reduce memory footprint. Is there any other case that will need full
blob in memory?
PS. For checkout/checkin case, if you do any conversion, full blob in
memory is still needed. But I guess that is rare for large blobs.
--
Duy
^ permalink raw reply
* Re: git and mtime
From: Samuel Tardieu @ 2008-11-20 15:56 UTC (permalink / raw)
To: martin f krafft; +Cc: Roger Leigh, git
In-Reply-To: <20081120135956.GA29789@piper.oerlikon.madduck.net>
>>>>> "martin" == martin f krafft <madduck@madduck.net> writes:
martin> I know you will hate me, but I think the solution here is to
martin> fix the toolchain and make those build dependencies required.
I agree with martin here. Your planned solution of not rebuilding the
files if the tools are not present may lead to serious problems if the
user modifies the source files and happens not to have the tools
around.
Moreover, requiring the build dependencies would allow you to drop the
generated files from the repository and rebuild them in your packaging
(source or binary) process.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Nguyen Thai Ngoc Duy @ 2008-11-20 15:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20081120153252.GA7374@coredump.intra.peff.net>
On 11/20/08, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 20, 2008 at 10:26:48PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > Thanks for catching. The last half also has the same problem. Another
>
>
> I'm not sure what you mean by "the last half also has the same problem";
> with the patch I posted (or Junio's patch) the test works fine for me.
Sorry for the confusion. I meant the second half of the series,
implementing UI interface for sparce checkout, which is not in pu yet.
--
Duy
^ permalink raw reply
* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 15:37 UTC (permalink / raw)
To: Roger Leigh; +Cc: Christian MICHON, git
In-Reply-To: <20081120151925.GE6023@codelibre.net>
Roger Leigh wrote:
> On Thu, Nov 20, 2008 at 03:50:49PM +0100, Andreas Ericsson wrote:
>> Roger Leigh wrote:
>>> On Thu, Nov 20, 2008 at 02:06:13PM +0100, Andreas Ericsson wrote:
>>>> Roger Leigh wrote:
>>>>> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
>>>>>> On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
>>>>>>> Would it be possible for git to store the mtime of files in the tree?
>>>>>>>
>>>>>>> This would make it possible to do this type of work in git, since it's
>>>>>>> currently a bit random as to whether it works or not. This only
>>>>>>> started when I upgraded to an amd64 architecture from powerpc32,
>>>>>>> I guess it's maybe using high-resolution timestamps.
>>>>>>>
>>>> Caring about meta-data the way you mean it would mean that
>>>>
>>>> git add foo.c; git commit -m "kapooie"; touch foo.c; git status
>>>>
>>>> would show "foo.c" as modified. How sane is that?
>>> I've never come close to suggesting we do anything so insane.
>>>
>>> What I am suggesting is that on add/commit, the inode metadata
>>> be recorded in the tree (like we already store perms), so that
>>> it can be (**optionally**) reused/restored on checkout.
>>>
>>> Whether it's stored in the tree or not is a separate concern from
>>> whether to *use* it or not. For most situations, it won't be
>>> useful, as has been made quite clear from all of the replies, and I
>>> don't disagree with this. However, for some, the ability to have
>>> this information to hand to make use of would be invaluable.
>>>
>> Then write a hook for it. You agree that for most users this will be
>> totally insane, and yet you request that it's added in a place where
>> everyone will have to pay the performance/diskspace penalty for it
>> but only a handful will get any benefits. That's patently absurd.
>
> The cost is tiny. The extra space would be smaller than a single
> SHA1 hash.
>
>> Especially since there are such easy workarounds that you can put in
>> place yourself instead.
>
>
>>> There have been quite a few suggestions to look into using hooks,
>>> and I'll investigate this. However, I do have some concerns
>>> about *where* I would store this "extended tree" data, since it
>>> is implicitly tied to a single tree object, and I wouldn't
>>> want to store it directly as content.
>> Store it as a blob targeted by a lightweight tag named
>> "metadata.$sha1" and you'll have the easiest time in the world when
>> writing the hooks. Also, the tags won't be propagated by default,
>> which is a good thing since your timestamps/uid's whatever almost
>> certainly will not work well on other developers repositories.
>
> And yet the fact that it won't propagate makes it totally useless:
> all the other people using the repo won't get the extra metadata
> that will prevent build failures. Having the extra data locally
> is nice, but not exactly what I'd call a solution. The whole point
> of what I want is to have it as an integral part of the repo.
>
Then make it signed tags and ship them along.
Or do this properly and simply put in your buildsystem that some
targets never need to be rebuilt. That's (by far) the simplest
solution.
On a sidenote, I fail to see how the pre-generated stuff can avoid
getting updated unless also the sources for that stuff was updated,
in which case either of the following is true:
a) You really do need to rebuild, because upstream fucked up.
b) The pre-generated stuff should *also* be checked out and get new
timestamps.
Either way, to me it sounds like your buildsystem needs some love.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and mtime
From: Kyle Moffett @ 2008-11-20 15:33 UTC (permalink / raw)
To: Roger Leigh; +Cc: Andreas Ericsson, Christian MICHON, git
In-Reply-To: <20081120151925.GE6023@codelibre.net>
On Thu, Nov 20, 2008 at 10:19 AM, Roger Leigh <rleigh@codelibre.net> wrote:
> And yet the fact that it won't propagate makes it totally useless:
> all the other people using the repo won't get the extra metadata
> that will prevent build failures. Having the extra data locally
> is nice, but not exactly what I'd call a solution. The whole point
> of what I want is to have it as an integral part of the repo.
Easiest way is typically something like this in the makefile:
docbook_version = $(shell docbook2man --version 2>/dev/null)
ifneq "$docbook_version",""
mymanpage.1:
## Real docbook build rules here
else
mymanpage.1:
if [ -e $@ ]; then \
echo "No 'docbook' installed, using pregenerated man
pages" >&2 ; \
else \
echo "Pregenerated manpages are missing and no docbook
found!" >&2 ; \
exit 1 ; \
fi
endif
Such stuff will take an order of magnitude less time than trying to
patch GIT to preserve metadata that most projects don't want
preserved. You may also find it's easier to just comment out the
documentation build rules if you are always guaranteeing that the docs
have been compiled.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Jeff King @ 2008-11-20 15:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <fcaeb9bf0811200726x1f2956c6k6f2ca16543a0fbc@mail.gmail.com>
On Thu, Nov 20, 2008 at 10:26:48PM +0700, Nguyen Thai Ngoc Duy wrote:
> Thanks for catching. The last half also has the same problem. Another
I'm not sure what you mean by "the last half also has the same problem";
with the patch I posted (or Junio's patch) the test works fine for me.
> way is maybe just stay away for those numbers, naming the files by
> alphabet. Just wonder if we could have some ways to automatically
> catch this kind of bug in the future.
Dscho suggested something similar. I would be happy if somebody wrote a
portability lint that found problems in shell constructs and calling
conventions of tools. In practice, though, I think it ends up being
quite hard to catalog all of the quirks of every platform (and
certainly, I would never have thought that this would break -- as it
was, after it _did_ break I had to sit scratching my head wondering how
that piece of code could be wrong).
So I think a simpler approach makes sense: write tests that make sure
the system is doing what you want, and then run those tests periodically
in the environments that you care about checking. When it breaks, you
know there is a problem. :) And that is exactly how this bug was caught.
-Peff
^ 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