Johannes Schindelin wrote Monday, January 12, 2009 12:45 PM
On Mon, 12 Jan 2009, Trevor Daniels wrote:
Valentin Villenave wrote Sunday, January 11, 2009 6:30 PM
> By the way, one sensible addition to the CG might be to invite Windows
> users to do
>
> git config global.autocrlf = false
>
> o
Hi,
On Mon, 12 Jan 2009, Trevor Daniels wrote:
> Valentin Villenave wrote Sunday, January 11, 2009 6:30 PM
>
> > By the way, one sensible addition to the CG might be to invite Windows
> > users to do
> >
> > git config global.autocrlf = false
> >
> > or something like that (by default under Wi
Valentin Villenave wrote Monday, January 12, 2009 10:05 AM
2009/1/12 Trevor Daniels :
Why should you want to turn this off, Valentin?
Because
a) any decent editor (i.e. other than NotePad) recognizes and knows
how to edit LF EOL-ed documents
b) my opera (and I believe that Lily's source co
2009/1/12 Trevor Daniels :
> Why should you want to turn this off, Valentin?
Because
a) any decent editor (i.e. other than NotePad) recognizes and knows
how to edit LF EOL-ed documents
b) my opera (and I believe that Lily's source code does too) uses only
LF endings
c) so whenever I modified a fi
Valentin Villenave wrote Sunday, January 11, 2009 6:30 PM
By the way, one sensible addition to the CG might be to invite Windows
users to do
git config global.autocrlf = false
or something like that (by default under Windows, git converts all
line endings to crlf)
I'm not sure this is advis
Hi,
On Sun, 11 Jan 2009, Valentin Villenave wrote:
> 2009/1/11 Johannes Schindelin :
>
> > The next Windows Git installer will let the user choose which strategy
> > to take.
>
> Great! You have no idea how much hair I have been pulling out about this
> :-)
Actually, I do, that's why I force
2009/1/11 Johannes Schindelin :
> The next Windows Git installer will let the user choose which strategy to
> take.
Great! You have no idea how much hair I have been pulling out about this :-)
Cheers,
Valentin
___
lilypond-devel mailing list
lilypond
Hi,
On Sun, 11 Jan 2009, Valentin Villenave wrote:
> 2009/1/10 Graham Percival :
>
> > CG! CG! CG! :)
>
> By the way, one sensible addition to the CG might be to invite Windows
> users to do
>
> git config global.autocrlf = false
>
> or something like that (by default under Windows, git conv
2009/1/10 Graham Percival :
> CG! CG! CG! :)
By the way, one sensible addition to the CG might be to invite Windows
users to do
git config global.autocrlf = false
or something like that (by default under Windows, git converts all
line endings to crlf)
Cheers,
Valentin
__
On Sat, Jan 10, 2009 at 06:30:23PM +0100, John Mandereau wrote:
> Neil Puttock a écrit :
>>> Any thoughts on what is wrong or how I can get this patch to apply?
>>
>> It applies OK using `git am'.
>
> BTW git-apply should be used for patches without authoring information,
> i.e. patches not made w
On Sat, Jan 10, 2009 at 11:40 AM, Reinhold Kainhofer
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am Samstag, 10. Januar 2009 20:27:34 schrieb Carl D. Sorensen:
>> On 1/10/09 12:16 PM, "Reinhold Kainhofer" wrote:
>> > Can you maybe attach the file (rather than pasting its contents
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Samstag, 10. Januar 2009 20:27:34 schrieb Carl D. Sorensen:
> On 1/10/09 12:16 PM, "Reinhold Kainhofer" wrote:
> > Can you maybe attach the file (rather than pasting its contents into the
> > mail), so that end-of-line characters are preserved...
>
On 1/10/09 12:16 PM, "Reinhold Kainhofer" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am Samstag, 10. Januar 2009 19:29:31 schrieb Carl D. Sorensen:
>> On 1/10/09 11:24 AM, "John Mandereau" wrote:
>>> Carl D. Sorensen a écrit :
> Are "diff --git a/... b/..." lines broken
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Samstag, 10. Januar 2009 19:29:31 schrieb Carl D. Sorensen:
> On 1/10/09 11:24 AM, "John Mandereau" wrote:
> > Carl D. Sorensen a écrit :
> >>> Are "diff --git a/... b/..." lines broken in the patch you actually
> >>> tried to apply? They should n
On 1/10/09 11:24 AM, "John Mandereau" wrote:
> Carl D. Sorensen a écrit :
>>> Are "diff --git a/... b/..." lines broken in the patch you actually tried to
>>> apply? They should not be broken, I guess.
>>
>> No, they're not broken. It's one line.
>
> Ugh, I'm almost short of ideas; which O
Carl D. Sorensen a écrit :
Are "diff --git a/... b/..." lines broken in the patch you actually tried to
apply? They should not be broken, I guess.
No, they're not broken. It's one line.
Ugh, I'm almost short of ideas; which OS do you use to work with Git? Could
a non-Linux system be confu
On 1/10/09 10:54 AM, "John Mandereau" wrote:
>>> Carl D. Sorensen a écrit :
fatal: git apply: bad git-diff - expected /dev/null on line 46
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run
Carl D. Sorensen a écrit :
fatal: git apply: bad git-diff - expected /dev/null on line 46
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "g
On 1/10/09 10:40 AM, "John Mandereau" wrote:
> Carl D. Sorensen a écrit :
>> fatal: git apply: bad git-diff - expected /dev/null on line 46
>> Patch failed at 0001.
>> When you have resolved this problem run "git am --resolved".
>> If you would prefer to skip this patch, instead run "git am --
Carl D. Sorensen a écrit :
fatal: git apply: bad git-diff - expected /dev/null on line 46
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "g
On 1/10/09 10:22 AM, "Neil Puttock" wrote:
> Hi Carl,
>
> 2009/1/10 Carl D. Sorensen :
>
>> Any thoughts on what is wrong or how I can get this patch to apply?
>
> It applies OK using `git am'.
Thanks for the tip. I hadn't known about git am.
But it still didn't apply properly for me:
Neil Puttock a écrit :
Hi Carl,
2009/1/10 Carl D. Sorensen :
Any thoughts on what is wrong or how I can get this patch to apply?
It applies OK using `git am'.
BTW git-apply should be used for patches without authoring information, i.e.
patches not made with git-format-patch.
Cheers,
Joh
Hi Carl,
2009/1/10 Carl D. Sorensen :
> Any thoughts on what is wrong or how I can get this patch to apply?
It applies OK using `git am'.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilyp
I received the following patch from Patrick McCarty;; From
61917179406f567351d73282ca4ed008b3e4b859 Mon Sep 17 00:00:00 2001
From: Patrick McCarty
Date: Tue, 6 Jan 2009 16:26:22 -0800
Subject: [PATCH] Docs: Add new procedure for barNumberVisibility
* The default value of barNumberVisibility, the
Daniel Tonda wrote:
> Greetings:
>
> Just reporting, that I finally did the pull and here's a surprise, it
> didn't complain!
>
> $ git pull git://git.sv.gnu.org/lilypond.git/ web/master:
> Generating pack...
> Done counting 120 objects.
> Result has 91 objects.
> Deltifying 91 objects.
> 100% (
Greetings:
Just reporting, that I finally did the pull and here's a surprise, it
didn't complain!
$ git pull git://git.sv.gnu.org/lilypond.git/ web/master:
Generating pack...
Done counting 120 objects.
Result has 91 objects.
Deltifying 91 objects.
100% (91/91) done
Unpacking 91 objects
Total 91,
Hi,
On Fri, 5 Jan 2007, John Mandereau wrote:
> Daniel Tonda wrote:
> >
> > Should I do the pull after the modifications?
>
> Yes, and it might tell you that you have to merge.
I don't think that it will tell you that you have to merge: you have no
uncommitted files.
It will realize that you
Daniel Tonda wrote:
> I think this mail got lost somewhere, so I'm re-sending.
Sorry, it was "lost" in my private mailbox, I overlooked it. Please send
future translation updates only to this list.
> After talking to Franciso where he agreed that the titles were
> misunderstood i modified the in
I think this mail got lost somewhere, so I'm re-sending.
===
After talking to Franciso where he agreed that the titles were
misunderstood i modified the index file and the did:
$ git-update-index es/index.html
$ git-commit -m "message"
$ git format-patch H
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
>
> > Or, you use the script git-hunk-commit.bash which I posted. Which
> > reminds me: I wanted to rewrite it for you so it is more
> > non-brand-new-bash friendly.
>
> :)
>
> that's really nice, but actually re
Johannes Schindelin escreveu:
>> shows the diff of the change that he just introduced
>
> Okay. But you mean
>
> $ git commit --dry file1 file2...
>
> or
>
> $ git commit --dry -a
Well, --dry would be usable both with -a and file1, file2.
I agree with Jakub that --diff might be a better name
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> I'm not saying git-diff should be inconvenient, but rather that it gives
> a newbie more confidence if
>
> git commit --dry
>
> shows the diff of the change that he just introduced
Okay. But you mean
$ git commit --dry file1 file2...
or
$
Han-Wen Nienhuys wrote:
> I think it would be more logical to show those diffs as part of
> git-status and perhaps git-commit, eg.
>
> git-commit --dry-run
>
> shows the diff of what would be committed
>
> git-status --diff
>
> shows diffs of modified files in the working tree.
>
> This
Johannes Schindelin escreveu:
> The thing is: it is so darned convenient. In 99% of calling "git diff" you
> do not have a modified staging area. It is still fresh, and all your
> changes are in the working directory only.
>
> Then you can say
>
> $ git diff
>
> to see what you have changed. (
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
> > The nice thing for me about Git: you never lose anything. Unless you say
> > "git prune" (in which case you really should know what you are doing), you
> > do not lose (committed) data.
> >
> > Now, I promised
Johannes Schindelin escreveu:
> The nice thing for me about Git: you never lose anything. Unless you say
> "git prune" (in which case you really should know what you are doing), you
> do not lose (committed) data.
>
> Now, I promised to tell you what to do if all the files seem modified. Did
>
> cvs co blah blah (which I simply copy and paste from savannah anyway)
> while (true) {
>cvs update // get changes that happened overnight
>vi foo/bar/baz.txt // or whatever editing commands you do
>make; make web // or whatever testing commands you do
>cvs update
Hi,
On Wed, 6 Dec 2006, Graham Percival wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 5 Dec 2006, Graham Percival wrote:
> >
> > > # Updated but not checked in:
> > > # (will commit)
> > > #
> > > # modified: .gitignore
> > > # modified: Documentation/topdocs/NEW
Hi,
On Wed, 6 Dec 2006, Mats Bengtsson wrote:
> Johannes Schindelin wrote:
> >
> > > It would be nice to have an accompanying "tutorial introduction to
> > > contributing with git" that just goes over the following steps (in their
> > > git equivalent):
> > >
> > >
> > > cvs co blah blah (whi
Johannes Schindelin wrote:
It would be nice to have an accompanying "tutorial introduction to
contributing with git" that just goes over the following steps (in their
git equivalent):
cvs co blah blah (which I simply copy and paste from savannah anyway)
while (true) {
cvs update
Johannes Schindelin wrote:
Hi,
On Tue, 5 Dec 2006, Graham Percival wrote:
# Updated but not checked in:
# (will commit)
#
# modified: .gitignore
# modified: Documentation/topdocs/NEWS.tely
...
This means that you do have modifications in those files. Could you please
try a
Hi,
On Tue, 5 Dec 2006, Graham Percival wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 5 Dec 2006, Graham Percival wrote:
> >
> > > I'm reluctant to post to the git mailing list because I'm completely
> > > willing
> > > to admit that this is probably a stupid luser problem. I nev
Johannes Schindelin wrote:
Hi,
On Tue, 5 Dec 2006, Graham Percival wrote:
I'm reluctant to post to the git mailing list because I'm completely willing
to admit that this is probably a stupid luser problem. I never seriously
I would like to post your mail (anonymized, of course) to the git l
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> Graham Percival escreveu:
> > Han-Wen Nienhuys wrote:
> >> This is interesting. There has been lots of discussion on the git
> >> mailing list, about git being hard to understand, but -it being a
> >> developer's list- little data from actual newb
Hi,
On Tue, 5 Dec 2006, Graham Percival wrote:
> Han-Wen Nienhuys wrote:
> > This is interesting. There has been lots of discussion on the git mailing
> > list, about git being hard to understand, but -it being a developer's list-
> > little data from actual newbie users. Could you take some brie
Graham Percival escreveu:
> Han-Wen Nienhuys wrote:
>> This is interesting. There has been lots of discussion on the git
>> mailing list, about git being hard to understand, but -it being a
>> developer's list- little data from actual newbie users. Could you take
>> some brief notes about what trip
Han-Wen Nienhuys wrote:
This is interesting. There has been lots of discussion on the git mailing list,
about git being hard to understand, but -it being a developer's list- little
data from actual newbie users. Could you take some brief notes about what
tripped you up, and post them?
I'm rel
Hi,
On Wed, 6 Dec 2006, John Mandereau wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 5 Dec 2006, John Mandereau wrote:
> >
> > > I can easily do all common operations (including push), except that I
> > > don't know what should be the best way to merge branches in order to
> > > push them
Johannes Schindelin wrote:
> On Tue, 5 Dec 2006, John Mandereau wrote:
>
> > I can easily do all common operations (including push), except that I
> > don't know what should be the best way to merge branches in order to
> > push them to git.sv.gnu.org (but Erik will certainly tell us in his
>
Hi,
On Tue, 5 Dec 2006, John Mandereau wrote:
> I can easily do all common operations (including push), except that I
> don't know what should be the best way to merge branches in order to
> push them to git.sv.gnu.org (but Erik will certainly tell us in his
> tutorial ;-)
Suppose you have se
Graham Percival wrote:
> OK, I just spent an hour fighting with git with no results. I'm going
> to delete everything and start from scratch.
I've almost never played with git directly, I prefer to use its frontend
cogito, which is as easy to use as cvs (when you've understood git
concepts of co
Mats Bengtsson escreveu:
> If you browse through the git repository on-line, you will see that your
> patches
> are included. However, I note that the starting point for your diff of
that's misleading. I actually applied them, but set Graham to be the author
of that commit
--
Han-Wen Nienhuys
If you browse through the git repository on-line, you will see that your
patches
are included. However, I note that the starting point for your diff of
advanced-notation.itely below didn't include the patch I made to the
same line
4 days ago.
Regarding the use of git, I certainly had to do som
Graham Percival escreveu:
> OK, I just spent an hour fighting with git with no results. I'm going
> to delete everything and start from scratch.
This is interesting. There has been lots of discussion on the git mailing list,
about git being hard to understand, but -it being a developer's list- l
OK, I just spent an hour fighting with git with no results. I'm going
to delete everything and start from scratch.
Could somebody commit these for me? I don't want to lose these (small)
changes.
Cheers,
- Graham
commit 902cc3c383928273b8aedf507158bcce1b7a65e4
Author: Graham Percival <[EMAIL
55 matches
Mail list logo
