* Re: nightly tarballs of git
[not found] <20060914172754.GF8013@us.ibm.com>
@ 2006-09-14 17:51 ` Dave Jones
2006-09-14 19:15 ` Junio C Hamano
0 siblings, 1 reply; 9+ messages in thread
From: Dave Jones @ 2006-09-14 17:51 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: git
On Thu, Sep 14, 2006 at 10:27:54AM -0700, Nishanth Aravamudan wrote:
> Hi Dave,
>
> For simplicities sake when I was running Debian Sarge on a server here,
> I was using your nightly tarballs of git to build a fresh up-to-date
> version on a regular basis. I noticed though, that the tarballs result
> in gits with a version of 1.3.GIT, while the git repository is at
> 1.4.2.1. Is that expected?
No, it isn't. (at least by me).
What the snapshotting script does when cron runs it is just a 'git pull'
on a repo that was cloned a while back when I first set up the snapshotting
script. I could change it to do a fresh clone each time it runs, but
that seems somewhat wasteful when most of the time there's nothing new to pull.
gitsters, any ideas what could be going wrong here ?
The original clone of the repo was just a straight clone of git://git.kernel.org/pub/scm/git/git.git
Dave
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-14 17:51 ` nightly tarballs of git Dave Jones
@ 2006-09-14 19:15 ` Junio C Hamano
2006-09-14 19:36 ` Dave Jones
0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2006-09-14 19:15 UTC (permalink / raw)
To: Dave Jones; +Cc: git, Nishanth Aravamudan
Dave Jones <davej@redhat.com> writes:
> On Thu, Sep 14, 2006 at 10:27:54AM -0700, Nishanth Aravamudan wrote:
> > Hi Dave,
> >
> > For simplicities sake when I was running Debian Sarge on a server here,
> > I was using your nightly tarballs of git to build a fresh up-to-date
> > version on a regular basis. I noticed though, that the tarballs result
> > in gits with a version of 1.3.GIT, while the git repository is at
> > 1.4.2.1. Is that expected?
>
> No, it isn't. (at least by me).
> What the snapshotting script does when cron runs it is just a 'git pull'
> on a repo that was cloned a while back when I first set up the snapshotting
> script. I could change it to do a fresh clone each time it runs, but
> that seems somewhat wasteful when most of the time there's nothing new to pull.
>
> gitsters, any ideas what could be going wrong here ?
> The original clone of the repo was just a straight clone of git://git.kernel.org/pub/scm/git/git.git
When the build procesure assigns the version to the generated
git binary, it does these checks and takes the first one:
- Run "git describe" at the top of the source tree. If it
returns some version (not an error message), use it. This
case should not apply here since we are talking about a
tarball of a working tree, and it does not have a repository.
- See if 'version' file exists at the top of the source tree,
and uses what is recorded there. This file is placed in the
resulting tarball by the "make dist" target of the toplevel
Makefile.
- Otherwise use DEF_VER hardcoded in GIT-VERSION-GEN script.
The 1.4.2 series is shipped with DEF_VER set to v1.4.2.GIT,
so this does not explain why Nashanth sees "1.3.GIT" (or
"v1.3.GIT", if the original report did not copy it right).
I just snarfed your snapshot tarball from a few days ago, and I
do not see any version file there (which indicates that it is
not a product of "make dist"). Interestingly enough DEF_VER is
set to v1.3.GIT in GIT-VERSION-GEN. This line was changed from
v1.3.GIT to v1.4.GIT with commit 41292dd on June 10th and then
updated to v1.4.2.GIT with commit 5a71682 on August 3rd.
So a short conclusion is that the directory you are tarring up
does not have snapshot of my tree.
I would like to understand why. If an automated 'pull' is
failing, that is somewhat worrysome, because I presume you do
not do any development of your own in your snapshot directory
and in that case everything should fast forward. Even if 'pull'
failed somehow, if it is not reporting its failure, it is even
more worrysome.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-14 19:15 ` Junio C Hamano
@ 2006-09-14 19:36 ` Dave Jones
2006-09-14 19:48 ` Jakub Narebski
2006-09-14 20:06 ` Junio C Hamano
0 siblings, 2 replies; 9+ messages in thread
From: Dave Jones @ 2006-09-14 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nishanth Aravamudan
On Thu, Sep 14, 2006 at 12:15:03PM -0700, Junio C Hamano wrote:
> Dave Jones <davej@redhat.com> writes:
> > The original clone of the repo was just a straight clone of git://git.kernel.org/pub/scm/git/git.git
>
> When the build procesure assigns the version to the generated
> git binary, it does these checks and takes the first one:
>
> - Run "git describe" at the top of the source tree. If it
> returns some version (not an error message), use it. This
> case should not apply here since we are talking about a
> tarball of a working tree, and it does not have a repository.
On the server this is running on, the returns v1.3.3-g7f7e6ea
> - See if 'version' file exists at the top of the source tree,
> and uses what is recorded there. This file is placed in the
> resulting tarball by the "make dist" target of the toplevel
> Makefile.
> - Otherwise use DEF_VER hardcoded in GIT-VERSION-GEN script.
> The 1.4.2 series is shipped with DEF_VER set to v1.4.2.GIT,
> so this does not explain why Nashanth sees "1.3.GIT" (or
> "v1.3.GIT", if the original report did not copy it right).
>
> I just snarfed your snapshot tarball from a few days ago, and I
> do not see any version file there (which indicates that it is
> not a product of "make dist"). Interestingly enough DEF_VER is
> set to v1.3.GIT in GIT-VERSION-GEN. This line was changed from
> v1.3.GIT to v1.4.GIT with commit 41292dd on June 10th and then
> updated to v1.4.2.GIT with commit 5a71682 on August 3rd.
>
> So a short conclusion is that the directory you are tarring up
> does not have snapshot of my tree.
>
> I would like to understand why. If an automated 'pull' is
> failing, that is somewhat worrysome, because I presume you do
> not do any development of your own in your snapshot directory
> and in that case everything should fast forward. Even if 'pull'
> failed somehow, if it is not reporting its failure, it is even
> more worrysome.
I don't recall ever having done anything at all in the dir that
is being snapshotted. So the only thing that should be happening
is the side-effects of the script. Here it is in its entirity..
DATE=`date +%Y-%m-%d`
PROJ="git"
cd ~/git-trees
if [ -d $PROJ ]; then
cd $PROJ
git pull -n
else
git clone -q git://git.kernel.org/pub/scm/git/git.git
cd $PROJ
fi
snap=git-snapshot-$(date +"%Y%m%d")
git-tar-tree HEAD $snap | gzip -9 > $PROJ-$DATE.tar.gz
mv $PROJ-$DATE.tar.gz ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/
rm -f ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-`date +%Y-%m-%d --date="7 days ago"`.tar.gz
ln -sf ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-$DATE.tar.gz ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-latest.tar.gz
#git-fsck-objects --full
I'll save that broken dir away somewhere, and rerun the script
(which as you can see above will make it reclone from scratch).
If you want a copy of the .git of the broken tree I can put that up somewhere too.
Hmm, I just checked the mail cron sent out recently (sadly I don't
have an archive of older mails). It does look a bit strange..
got 49be764e948668341034e121fad5cf07ab079bff
got 415c09ba10a391cec60c939da1722c83df7cd906
* refs/heads/origin: fast forward to branch 'master' of http://www.kernel.org/pub/scm/git/git
from 8a5dbef8ac24bc5a28409d646cf3ff6db0cccb3f to 38529e28a4f465ad5d5f2fa249ca17da680bac5f
Failed to fetch refs/heads/gb/diffdelta from http://www.kernel.org/pub/scm/git/git.git
Interesting. It looks like my original clone was over http.
Another reason to reclone over git: I guess.
Dave
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-14 19:36 ` Dave Jones
@ 2006-09-14 19:48 ` Jakub Narebski
2006-09-14 20:06 ` Junio C Hamano
1 sibling, 0 replies; 9+ messages in thread
From: Jakub Narebski @ 2006-09-14 19:48 UTC (permalink / raw)
To: git
Dave Jones wrote:
> I don't recall ever having done anything at all in the dir that
> is being snapshotted. So the only thing that should be happening
> is the side-effects of the script. Here it is in its entirity..
>
> DATE=`date +%Y-%m-%d`
>
> PROJ="git"
> cd ~/git-trees
> if [ -d $PROJ ]; then
> cd $PROJ
Just in case I would add "git checkout master" here.
> git pull -n
> else
> git clone -q git://git.kernel.org/pub/scm/git/git.git
> cd $PROJ
> fi
> snap=git-snapshot-$(date +"%Y%m%d")
> git-tar-tree HEAD $snap | gzip -9 > $PROJ-$DATE.tar.gz
And what is the HEAD? Perhaps you should say 'origin' here instead?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-14 19:36 ` Dave Jones
2006-09-14 19:48 ` Jakub Narebski
@ 2006-09-14 20:06 ` Junio C Hamano
2006-09-16 17:58 ` Dave Jones
1 sibling, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2006-09-14 20:06 UTC (permalink / raw)
To: Dave Jones; +Cc: git
Dave Jones <davej@redhat.com> writes:
> DATE=`date +%Y-%m-%d`
>
> PROJ="git"
> cd ~/git-trees
> if [ -d $PROJ ]; then
> cd $PROJ
> git pull -n
> else
> git clone -q git://git.kernel.org/pub/scm/git/git.git
> cd $PROJ
> fi
> snap=git-snapshot-$(date +"%Y%m%d")
> git-tar-tree HEAD $snap | gzip -9 > $PROJ-$DATE.tar.gz
If you are using git-tar-tree (which by the way _is_ the right
thing to do) and if you are just taking an upstream snapshot
without doing your own development (which also is the case
here), then you do not even need a working tree in the directory
this script runs. It would save your disk space and time to
check out the updated working tree files.
Perhaps...
#!/bin/sh
URL=git://git.kernel.org/pub/scm/git/git.git
PROJ=git
cd ~/git-trees
if test -d "$PROJ"
then
cd "$PROJ" && git fetch
else
git clone -q -n "$URL" "$PROJ" && cd "$PROJ"
fi || {
echo >&2 Something wicked happend.
exit $?
}
snap=git-snapshot-$(date +"%Y%m%d")
git-tar-tree origin $snap | gzip -9 > $PROJ-$DATE.tar.gz
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-14 20:06 ` Junio C Hamano
@ 2006-09-16 17:58 ` Dave Jones
2006-09-16 18:04 ` Jakub Narebski
2006-09-16 18:09 ` Junio C Hamano
0 siblings, 2 replies; 9+ messages in thread
From: Dave Jones @ 2006-09-16 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Thu, Sep 14, 2006 at 01:06:03PM -0700, Junio C Hamano wrote:
> If you are using git-tar-tree (which by the way _is_ the right
> thing to do) and if you are just taking an upstream snapshot
> without doing your own development (which also is the case
> here), then you do not even need a working tree in the directory
> this script runs. It would save your disk space and time to
> check out the updated working tree files.
>
> Perhaps...
>
> #!/bin/sh
> URL=git://git.kernel.org/pub/scm/git/git.git
> PROJ=git
>
> cd ~/git-trees
> if test -d "$PROJ"
> then
> cd "$PROJ" && git fetch
> else
> git clone -q -n "$URL" "$PROJ" && cd "$PROJ"
> fi || {
> echo >&2 Something wicked happend.
> exit $?
> }
> snap=git-snapshot-$(date +"%Y%m%d")
> git-tar-tree origin $snap | gzip -9 > $PROJ-$DATE.tar.gz
This went well, right up until you checked something in :-)
Generating pack...
Done counting 155 objects.
Result has 126 objects.
Deltifying 126 objects.
0% (1/126) done
1% (2/126) done
2% (3/126) done
3% (4/126) done
4% (6/126) done
5% (7/126) done
6% (8/126) done
7% (9/126) done
8% (11/126) done
9% (12/126) done
10% (13/126) done
11% (14/126) done
12% (16/126) done
13% (17/126) done
14% (18/126) done
15% (19/126) done
16% (21/126) done
17% (22/126) done
18% (23/126) done
19% (24/126) done
20% (26/126) done
21% (27/126) done
22% (28/126) done
23% (29/126) done
24% (31/126) done
25% (32/126) done
26% (33/126) done
27% (35/126) done
28% (36/126) done
29% (37/126) done
30% (38/126) done
31% (40/126) done
32% (41/126) done
33% (42/126) done
34% (43/126) done
35% (45/126) done
36% (46/126) done
37% (47/126) done
38% (48/126) done
39% (50/126) done
40% (51/126) done
41% (52/126) done
42% (53/126) done
43% (55/126) done
44% (56/126) done
45% (57/126) done
46% (58/126) done
47% (60/126) done
48% (61/126) done
49% (62/126) done
50% (63/126) done
51% (65/126) done
52% (66/126) done
53% (67/126) done
54% (69/126) done
55% (70/126) done
56% (71/126) done
57% (72/126) done
58% (74/126) done
59% (75/126) done
60% (76/126) done
61% (77/126) done
62% (79/126) done
63% (80/126) done
64% (81/126) done
65% (82/126) done
66% (84/126) done
67% (85/126) done
68% (86/126) done
69% (87/126) done
70% (89/126) done
71% (90/126) done
72% (91/126) done
73% (92/126) done
74% (94/126) done
75% (95/126) done
76% (96/126) done
77% (98/126) done
78% (99/126) done
79% (100/126) done
80% (101/126) done
81% (103/126) done
82% (104/126) done
83% (105/126) done
84% (106/126) done
85% (108/126) done
86% (109/126) done
87% (110/126) done
88% (111/126) done
89% (113/126) done
90% (114/126) done
91% (115/126) done
92% (116/126) done
93% (118/126) done
94% (119/126) done
95% (120/126) done
96% (121/126) done
97% (123/126) done
98% (124/126) done
99% (125/126) done
100% (126/126) done
Unpacking 126 objects
Total 126, written 126 (delta 93), reused 0 (delta 0)
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/git/git
from 38529e28a4f465ad5d5f2fa249ca17da680bac5f to fc2b2be031f44aef0106cf7f872b750cd90b2253
* refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
not updating.
Something wicked happend.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-16 17:58 ` Dave Jones
@ 2006-09-16 18:04 ` Jakub Narebski
2006-09-16 18:09 ` Junio C Hamano
1 sibling, 0 replies; 9+ messages in thread
From: Jakub Narebski @ 2006-09-16 18:04 UTC (permalink / raw)
To: git
Dave Jones wrote:
> * refs/heads/pu: does not fast forward to branch 'pu' of
> git://git.kernel.org/pub/scm/git/git;
> not updating.
> Something wicked happend.
Did you put '+' before 'pu' line in 'origin' file in remotes?
It should read
Pull:+refs/heads/pu:refs/heads/pu
Alternatively you can give --force option to git-fetch.
See
http://git.or.cz/gitwiki/GitFaq#head-a1f9a3e511e0b866d788d7cb600637a9b976a994
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-16 17:58 ` Dave Jones
2006-09-16 18:04 ` Jakub Narebski
@ 2006-09-16 18:09 ` Junio C Hamano
2006-09-17 0:03 ` Dave Jones
1 sibling, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2006-09-16 18:09 UTC (permalink / raw)
To: Dave Jones; +Cc: git
Dave Jones <davej@redhat.com> writes:
> This went well, right up until you checked something in :-)
>
> Generating pack...
> Done counting 155 objects.
> Result has 126 objects.
> Deltifying 126 objects.
> 0% (1/126) done
> ...
> Unpacking 126 objects
> Total 126, written 126 (delta 93), reused 0 (delta 0)
> * refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/git/git
> from 38529e28a4f465ad5d5f2fa249ca17da680bac5f to fc2b2be031f44aef0106cf7f872b750cd90b2253
> * refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
> not updating.
> Something wicked happend.
You care only about 'master' in that repository anyway, so I
would suggest removing other lines from remotes/origin and have
only these two lines:
URL: git://git.kernel.org/pub/scm/git/git
Pull: refs/heads/master:refs/heads/origin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: nightly tarballs of git
2006-09-16 18:09 ` Junio C Hamano
@ 2006-09-17 0:03 ` Dave Jones
0 siblings, 0 replies; 9+ messages in thread
From: Dave Jones @ 2006-09-17 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sat, Sep 16, 2006 at 11:09:24AM -0700, Junio C Hamano wrote:
> Dave Jones <davej@redhat.com> writes:
>
> > This went well, right up until you checked something in :-)
> >
> > Generating pack...
> > Done counting 155 objects.
> > Result has 126 objects.
> > Deltifying 126 objects.
> > 0% (1/126) done
> > ...
> > Unpacking 126 objects
> > Total 126, written 126 (delta 93), reused 0 (delta 0)
> > * refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/git/git
> > from 38529e28a4f465ad5d5f2fa249ca17da680bac5f to fc2b2be031f44aef0106cf7f872b750cd90b2253
> > * refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
> > not updating.
> > Something wicked happend.
>
> You care only about 'master' in that repository anyway, so I
> would suggest removing other lines from remotes/origin and have
> only these two lines:
>
> URL: git://git.kernel.org/pub/scm/git/git
> Pull: refs/heads/master:refs/heads/origin
Thanks, I updated the repo, and kicked the snapshot script, and
it seems to be doing the right thing again.
Dave
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-09-17 0:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20060914172754.GF8013@us.ibm.com>
2006-09-14 17:51 ` nightly tarballs of git Dave Jones
2006-09-14 19:15 ` Junio C Hamano
2006-09-14 19:36 ` Dave Jones
2006-09-14 19:48 ` Jakub Narebski
2006-09-14 20:06 ` Junio C Hamano
2006-09-16 17:58 ` Dave Jones
2006-09-16 18:04 ` Jakub Narebski
2006-09-16 18:09 ` Junio C Hamano
2006-09-17 0:03 ` Dave Jones
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).