Re: nightly tarballs of git

git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* 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).