On Sat, Feb 6, 2016 at 10:51 AM, Christian Couder
wrote:
> On Sat, Feb 6, 2016 at 4:20 PM, Karthik Nayak wrote:
>> Also the error is reported already in color_parse(...), so seems duplicated.
>>
>> git for-each-ref --format="%(color:sfadf)%(align:middle,30)%(refname)%(end)"
>> error: invalid col
On Sat, Feb 6, 2016 at 10:20 AM, Karthik Nayak wrote:
> On Fri, Feb 5, 2016 at 3:55 AM, Eric Sunshine wrote:
>> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak
>> wrote:
>>> +static void color_atom_parser(struct used_atom *atom, const char
>>> *color_value)
>>> +{
>>> + if (!color_value)
On Sat, Feb 6, 2016 at 9:36 AM, Karthik Nayak wrote:
> On Thu, Feb 4, 2016 at 3:49 AM, Eric Sunshine wrote:
>> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak
>> wrote:
>>> - const char *formatp = strchr(sp, ':');
>>> - if (!formatp || ep < formatp)
>>> -
On Sat, Feb 6, 2016 at 10:15 AM, Karthik Nayak wrote:
> On Sun, Jan 31, 2016 at 11:12 PM, Karthik Nayak wrote:
>> @@ -138,10 +140,9 @@ int parse_ref_filter_atom(const char *atom, const char
>> *ep)
>> * shouldn't be used for checking against the valid_atom
>> *
On Fri, Feb 5, 2016 at 5:52 AM, Eric Sunshine wrote:
> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak wrote:
>> Introduce contents_atom_parser() which will parse the '%(contents)'
>> atom and store information into the 'used_atom' structure based on the
>> modifiers used along with the atom. Als
On Sun, Feb 7, 2016 at 8:46 AM, Eric Sunshine wrote:
> On Sat, Feb 6, 2016 at 7:23 PM, Ramsay Jones
> wrote:
>> If you need to re-roll your 'kn/ref-filter-atom-parsing' branch, could
>> you please squash this (or something like it) into the relevant patch
>> (commit 6613d5f1, "ref-filter: introdu
On Wed, Feb 3, 2016 at 3:44 PM, Jacob Keller wrote:
> Ok so I am not sure we even really need to use "-c" option in
> git-clone considering that we can just use the same flow we do for
> setting core.worktree values. I'll propose a patch with you two Cc'ed,
> which I think fixes the issue. There m
On Sat, Feb 6, 2016 at 7:23 PM, Ramsay Jones
wrote:
> If you need to re-roll your 'kn/ref-filter-atom-parsing' branch, could
> you please squash this (or something like it) into the relevant patch
> (commit 6613d5f1, "ref-filter: introduce parsing functions for each valid
> atom", 31-01-2016).
>
>
Signed-off-by: Ramsay Jones
---
Hi Karthik,
If you need to re-roll your 'kn/ref-filter-atom-parsing' branch, could
you please squash this (or something like it) into the relevant patch
(commit 6613d5f1, "ref-filter: introduce parsing functions for each valid
atom", 31-01-2016).
This evening, (
On Sat, Feb 6, 2016 at 11:10 PM, Johannes Schindelin
wrote:
> Hi Kirill,
>
> On Sat, 6 Feb 2016, Kirill Likhodedov wrote:
>
>> > On 06 Feb 2016, at 17:21 , Johannes Schindelin
>> > wrote:
>> >
>> > This is expected behavior of the Bash you are using. The commands that I
>> > think would reflect
Noticed-by: Ole Tange
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Sun, Feb 7, 2016 at 4:56 AM, Ole Tange wrote:
> If file name too long it should just try to see if it is a reference
> to a revision.
Looks easy enough to fix.
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Hi,
A draft of Git Rev News edition 12 is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-12.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue
git diff first looks for a file, then looks if it is a reference to a
revision. If the file fails due to being too long, the diff fails:
$ git init
$ git diff
'HEAD^
I found no evidence of such behavior in the source code.
Signed-off-by: Matt McCutchen
---
This is based on the maint branch, a08595f.
Documentation/git-clean.txt | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
in
On Fri, Feb 5, 2016 at 5:35 AM, Eric Sunshine wrote:
> On Sun, Jan 31, 2016 at 11:12:54PM +0530, Karthik Nayak wrote:
>> Introduce remote_ref_atom_parser() which will parse the '%(upstream)'
>> and '%(push)' atoms and store information into the 'used_atom'
>> structure based on the modifiers used
On Fri, Feb 5, 2016 at 5:30 AM, Eric Sunshine wrote:
> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak wrote:
>> Introduce optional prefixes "width=" and "position=" for the align atom
>> so that the atom can be used as "%(align:width=,position=)".
>>
>> Add Documentation and tests for the same.
On Fri, 5 Feb 2016, Junio C Hamano wrote:
OK, as Brian said, that use case would need to be in the log message, at
least. I am curious, though, if you can give just a random string to
username, or at least that must match what the underlying authentication
mechanism uses.
Brian, I can see h
Dear Git users,
It is my pleasure to announce that Git for Windows 2.7.1 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.7.0(2) (February 2nd 2016)
New Features
??? Comes with Git 2.7.1.
Bug Fixes
??? Git GUI now starts properly even when th
Hi Kirill,
On Sat, 6 Feb 2016, Kirill Likhodedov wrote:
> > On 06 Feb 2016, at 17:21 , Johannes Schindelin
> > wrote:
> >
> > This is expected behavior of the Bash you are using. The commands that I
> > think would reflect your intentions would be:
> >
> > git init brackets
> > cd bra
On Sat, Feb 6, 2016 at 4:20 PM, Karthik Nayak wrote:
> On Fri, Feb 5, 2016 at 3:55 AM, Eric Sunshine wrote:
>> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak
>> wrote:
>>> Introduce color_atom_parser() which will parse a "color" atom and
>>> store its color in the "used_atom" structure for fur
On Fri, Feb 5, 2016 at 5:18 AM, Eric Sunshine wrote:
> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak wrote:
>> Introduce align_atom_parser() which will parse an 'align' atom and
>> store the required alignment position and width in the 'used_atom'
>> structure for further usage in populate_valu
On Fri, Feb 5, 2016 at 3:55 AM, Eric Sunshine wrote:
> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak wrote:
>> Introduce color_atom_parser() which will parse a "color" atom and
>> store its color in the "used_atom" structure for further usage in
>> populate_value().
>>
>> Signed-off-by: Karthik
On Sun, Jan 31, 2016 at 11:12 PM, Karthik Nayak wrote:
> @@ -138,10 +140,9 @@ int parse_ref_filter_atom(const char *atom, const char
> *ep)
> * shouldn't be used for checking against the valid_atom
> * table.
> */
> - const char *fo
On Sat, Feb 06, 2016 at 02:23:11PM +0100, René Scharfe wrote:
> Am 28.01.2016 um 00:45 schrieb f...@fuz.su:
> >>There is git get-tar-commit-id, which prints the commit ID if it
> >>finds a comment entry which looks like a hexadecimal SHA-1 hash.
> >>It's better than a hex editor at least. :)
> >
>
In "mingw: fix t5601-clone.sh", this developer introduced a new test
executable, test-fake-ssh. Naturally, he forgot to update the .gitignore
file accordingly. This patch fixes that.
Signed-off-by: Johannes Schindelin
---
This is on top of 'next', of course. My apologies that I did not
On Thu, Feb 4, 2016 at 3:49 AM, Eric Sunshine wrote:
> On Sun, Jan 31, 2016 at 12:42 PM, Karthik Nayak wrote:
>> Parsing atoms is done in populate_value(), this is repetitive and
>> hence expensive. Introduce a parsing function which would let us parse
>> atoms beforehand and store the required d
Hi Johannes,
thanks for your answer, but unfortunately it doesn’t help.
> On 06 Feb 2016, at 17:21 , Johannes Schindelin
> wrote:
>
> This is expected behavior of the Bash you are using. The commands that I
> think would reflect your intentions would be:
>
> git init brackets
> cd
Hi Kirill,
On Sat, 6 Feb 2016, Kirill Likhodedov wrote:
> Is it a bug or I just didn’t find the proper way to escape the brackets?
>
> Steps to reproduce:
>
> git init brackets
> cd brackets/
> echo ‘asd’ > bra[ckets].txt
> git add bra\[ckets\].txt
> git commit -m initial
>
Hi Philip,
On Fri, 5 Feb 2016, Philip Oakley wrote:
> From: "Britton Kerin"
> >I upgraded from 2.5 to 2.7 and the branch names went from a light
> > green to dark green, the names of the tags are hard to read now.
> >
> > Is it possible to configure the branch name color in the tree view?
> > --
Am 28.01.2016 um 00:45 schrieb f...@fuz.su:
There is git get-tar-commit-id, which prints the commit ID if it
finds a comment entry which looks like a hexadecimal SHA-1 hash.
It's better than a hex editor at least. :)
This is incredibly fuzzy and can get wrong for a pleothora of reasons.
I hope
I’ve faced a problem that `git show :` returns an error when
contains square brackets.
Interestingly, the problem is reproducible on "GNU bash, version
3.2.57(1)-release (x86_64-apple-darwin15)", but not on "zsh 5.0.7
(x86_64-pc-linux-gnu)”. The problem is also reproducible when called from a
On Fri, Feb 5, 2016 at 6:22 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>
> This is even more strange. Are the current callers broken and some
> sends value==NULL for an option that is not is_bool, resulting in
> a call to quote_c_st
32 matches
Mail list logo
