On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote:
> On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
> > Antoine's answer is correct. In addition, I'd say that you may want to
> > enable color in the output to make it clearer (the @@ ... @@ part would
> > be colored, but no
On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy
wrote:
> John Keeping writes:
>
>> I wonder if that should be the default. I've advised a lot of people to
>> turn it on and it seems to me that a user is much more likely to go
>> looking for a "turn color off" option than realise that color is an
>
John Keeping writes:
> I wonder if that should be the default. I've advised a lot of people to
> turn it on and it seems to me that a user is much more likely to go
> looking for a "turn color off" option than realise that color is an
> option at all.
I'd love to see this by default, yes. Maybe
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
> Antoine's answer is correct. In addition, I'd say that you may want to
> enable color in the output to make it clearer (the @@ ... @@ part would
> be colored, but not the function name):
>
> git config --global color.ui auto
I wond
Antoine Pelisse writes:
> On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:
>> Thank you for the quick reply.
>> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;"
Antoine's answer is correct. In addition, I'd say that you may want to
enable color in the output to make it clearer (the @
On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:
> Thank you for the quick reply.
> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;"
Oh OK, I see.
Git tries to name the function where the changes take place. This is
purely informative.
In your example, you don't have any function so of
On Wed, May 15, 2013 at 8:23 AM, eric liou wrote:
> The output of git-diff is different from my expectation.
> It may skip some lines of context.
git-diff is using a default of 3 lines of context above and below the changes.
In your example, there is only two lines of context below the change,
so
Phil Hord writes:
> Or maybe --amend should imply --cleanup=whitespace.
I am fairly negative on that.
Such a hidden linkage, even if it is documented, is just one more
thing people need to learn.
It _might_ be interesting (note: I did not say "worthwhile" here) to
think what happens if we scan
On Tue, Feb 19, 2013 at 6:02 AM, Duy Nguyen wrote:
> On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund wrote:
>> On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote:
>>> Hi,
>>>
>>> I wrote a commit message beginning with a hash (#) character, like this:
>>> 'git commit -m "#ifdef " '
>>>
>>>
On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund wrote:
> On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote:
>> Hi,
>>
>> I wrote a commit message beginning with a hash (#) character, like this:
>> 'git commit -m "#ifdef " '
>>
>> Everything went okay when committing, but then I tried 'git c
On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote:
> Hi,
>
> I wrote a commit message beginning with a hash (#) character, like this: 'git
> commit -m "#ifdef " '
>
> Everything went okay when committing, but then I tried 'git commit -amend'
> and without editing the commit message I was to
On 02/19/2013 10:32 AM, David Wade wrote:
> Hi,
>
> I wrote a commit message beginning with a hash (#) character, like
> this: 'git commit -m "#ifdef " '
>
> Everything went okay when committing, but then I tried 'git commit
> -amend' and without editing the commit message I was told I had an
Hi,
I wrote a commit message beginning with a hash (#) character, like this: 'git
commit -m "#ifdef " '
Everything went okay when committing, but then I tried 'git commit -amend' and
without editing the commit message I was told I had an empty commit message.
Is this a problem with my text
13 matches
Mail list logo
