Re: lilycontrib.tcl, was Re: the "r" in "git pull -r"

[Johannes Schindelin]

Hi,

On Tue, 11 Aug 2009, Jonathan Kulp wrote:

> On Tue, Aug 11, 2009 at 7:00 AM, Jonathan Kulp <address@hidden>wrote:
> 
> > On Tue, Aug 11, 2009 at 6:45 AM, Johannes Schindelin <
> > address@hidden> wrote:
> >
> >> >
> >> > So it doesn't give an error, just a warning. But AFAIR I have seen this
> >> > warning on my non-GUI-based checkouts, too, even though everything
> >> > worked fine. BTW, my git version is 1.6.0.4 (the latest one that Ubuntu
> >> > 9.04 has to offer).
> >>
> >> Ouch, I think I know what happened.  Git used your _current_ working
> >> directory as work tree.  So you have some stray LilyPond files lying
> >> around somewhere.
> >>
> >>
> > Aha! That's why I found a bunch of lily files in my $HOME/bin/ directory! I
> > found a lily/ directory inadvertently last night, and now that I look,
> > there's the Documentation, ly, make, stepmake, etc. So the files did get
> > downloaded, just not where expected. Easily fixed...
> >
> >
> Success!
> 
> I chose an amateurish brute-force method but it worked. Here's my revised
> update_lilypond function:
> 
> proc update_lilypond {} {
>        global lily_dir
>        if {![file exists $lily_dir]} {
>                file mkdir $lily_dir
>                cd $lily_dir ; git init
>                git config core.bare false
>                cd $lily_dir ; git remote add -t master \
>                        origin git://repo.or.cz/lilypond.git
>                cd $lily_dir ; git fetch --depth 1
>                cd $lily_dir ; git checkout -b master origin/master
>        } else {
>                cd $lily_dir ; git pull
>        }
> }
> 
> It's possible that the first "cd $lily_dir" would suffice but I wanted to be
> sure without having to experiment.  I know that in some circumstances the
> next lines of scripts or makefiles the succeeding lines are run in the
> working dir rather than the target dir.
> 
> Thanks for the cool script, Johannes. :)

Heh.

I did something similar, except I used --work-tree and therefore could do 
it in one place.  However, I needed the "file mkdir", too, and I had to 
change the "git pull" to a "git fetch" and "git merge" combo.  This is 
something I wanted to do anyway, as I want to have a checkbox that says 
whether you want to rebase all the time, or rather merge.

It probably should use the 'branch.<name>.rebase' config variable, just 
like Git does itself.

Ciao,
Dscho