On 2015-10-04 05.37, Jeff King wrote:
> On Sat, Oct 03, 2015 at 11:12:13PM +0200, Torsten Bögershausen wrote:
>
>>> Hmph, Peff's quick-fix passed the original "CoNfIg" in &buf directly
>>> to probe_utf8_pathname_composition() without changing its signature.
>> True, ( I was thinking that the test
On 2015-10-03 18.50, David Turner wrote:
> On Sat, 2015-10-03 at 07:02 +0200, Torsten Bögershausen wrote:
>> On 29.09.15 00:01, David Turner wrote:
>> (Not sure if this is the right thread to report on)
>>
>> In file included from builtin/commit.c:20:
>> ./refs.h:695:16: warning: redefinition of
On Fri, Oct 2, 2015 at 11:44 PM, Felipe Micaroni Lalli
wrote:
> Actually we already use the keyword MINOR for that, exactly as you said.
>
> The suggestion was made because I think it is a common behavior and it
> would be nice to be a meta info to standardize this (today each team
> adopt a diffe
On Sat, Oct 03, 2015 at 11:12:13PM +0200, Torsten Bögershausen wrote:
> > Hmph, Peff's quick-fix passed the original "CoNfIg" in &buf directly
> > to probe_utf8_pathname_composition() without changing its signature.
> True, ( I was thinking that the test did only work on case insensitive FS).
> We
On Sat, Oct 03, 2015 at 11:23:52PM +0100, Roberto Tyley wrote:
> On 28 September 2015 at 19:47, Junio C Hamano wrote:
> > I won't enable it on github.com:gitster/git anyway, so I do not
> > think that is a concern. I thought what people are talking about
> > was to add it on github.com:git/git,
Junio C Hamano writes:
> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:
>>
>> Given this, enabling Travis CI for git/git seems pretty low risk,
>> are there any strong objections to it happening?
>
> I still don't see a reason why git/git needs to be the one that is
> used, when somebody
>
On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:
>
> Given this, enabling Travis CI for git/git seems pretty low risk,
> are there any strong objections to it happening?
I still don't see a reason why git/git needs to be the one that is
used, when somebody
so interested (and I seem to see ver
On 28 September 2015 at 19:47, Junio C Hamano wrote:
> I won't enable it on github.com:gitster/git anyway, so I do not
> think that is a concern. I thought what people are talking about
> was to add it on github.com:git/git, but have I been misreading the
> thread? I do not even own the latter r
On 03.10.15 18:54, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 30.09.15 02:23, Jeff King wrote:
>>> On Tue, Sep 29, 2015 at 04:50:39PM -0700, Michael Blume wrote:
>>>
I see compile errors on my mac:
>>
>> This is my attempt, passing the test, but not fully polished.
>
On 03.10.15 18:50, David Turner wrote:
> On Sat, 2015-10-03 at 07:02 +0200, Torsten Bögershausen wrote:
>> On 29.09.15 00:01, David Turner wrote:
>>>
>> (Not sure if this is the right thread to report on)
>>
>> In file included from builtin/commit.c:20:
>> ./refs.h:695:16: warning: redefinition of
You are right. It could be useful to fix old commits (already pushed)
but it could encourage bad practices. Minor changes should be avoided,
it is an exception, not a rule.
Thank you Fredrik.
On 03/10/2015 15:12, Fredrik Gustafsson wrote:
> On Fri, Oct 02, 2015 at 06:38:46PM -0300, Felipe Micaro
A big comment at the beginning of quote.c is really
related to sq_quote_buf(), so let's move it in front
of this function.
---
quote.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/quote.c b/quote.c
index 890885a..fe884d2 100644
--- a/quote.c
+++ b/quote.c
@@ -4,6
Since 77d604c (Enhanced sq_quote(), 10 Oct 2005), the
comment at the beginning of quote.c is broken.
Let's fix it.
---
quote.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/quote.c b/quote.c
index 7920e18..890885a 100644
--- a/quote.c
+++ b/quote.c
@@ -7,6 +7,7 @@ int quote_path_fully = 1;
On Fri, Oct 02, 2015 at 06:38:46PM -0300, Felipe Micaroni Lalli wrote:
> A minor change (also called "cosmetic") usually is a typo fix, doc
> improvement, a little code refactoring that don't change the behavior etc.
>
> In Wikipedia we can mark an edition as "minor".
>
> It would be nice to have
On Mon, Sep 28, 2015 at 06:02:18PM -0400, David Turner wrote:
> Add tests for the database backend.
>
> Signed-off-by: David Turner
> ---
> t/t1460-refs-be-db.sh| 1103
> ++
> t/t1470-refs-be-db-reflog.sh | 353 ++
> 2 files changed,
Junio C Hamano writes:
> Luke Diamand writes:
>
>> All looks good to me, Ack.
>>
>> One tiny thing perhaps Junio could comment on: the git commit message
>> for 75abe9fa5b39980de27dfc33dd5b4f4b5926f34c, "git-p4: add optional
>> type specifier to gitConfig reader" uses what looks like UTF-8 encod
Luke Diamand writes:
> On 26 September 2015 at 08:54, wrote:
>> From: Lars Schneider
>>
>> diff to v7:
>> * fix commit message line length (thanks Junio)
>> * fix sync command for large file system support (thanks Luke!)
>> * add test case for sync command
>> * rename git-p4.pushLargeFiles to
Ray Donnelly writes:
> In normalize_ceiling_entry(), we test that normalized paths end with
> slash, *unless* the path to be normalized was already the root
> directory.
>
> However, normalize_path_copy() does not even enforce this condition.
Perhaps the real issue to be addressed is the above,
Matthieu Moy writes:
> My take on it:
>
> Implement %(if), %(then) and %(else) atoms. Used as
> %(if)...%(then)...%(end) or %(if)...%(then)...%(else)...%(end). If the
> format string between %(if) and %(then) expands to an empty string, or
> to only whitespaces, then the string following %(then)
Torsten Bögershausen writes:
> On 30.09.15 02:23, Jeff King wrote:
>> On Tue, Sep 29, 2015 at 04:50:39PM -0700, Michael Blume wrote:
>>
>>> I see compile errors on my mac:
>>>
>
> This is my attempt, passing the test, but not fully polished.
Thanks.
> diff --git a/builtin/init-db.c b/builtin/i
On Sat, 2015-10-03 at 07:02 +0200, Torsten Bögershausen wrote:
> On 29.09.15 00:01, David Turner wrote:
> >
> (Not sure if this is the right thread to report on)
>
> In file included from builtin/commit.c:20:
> ./refs.h:695:16: warning: redefinition of typedef 'ref_transaction_free_fn'
> is a C11
On 26 September 2015 at 08:54, wrote:
> From: Lars Schneider
>
> diff to v7:
> * fix commit message line length (thanks Junio)
> * fix sync command for large file system support (thanks Luke!)
> * add test case for sync command
> * rename git-p4.pushLargeFiles to git-p4.largeFilePush for consist
I'm going to have to attach this as a file, git-send-email isn't
working for me; apologies.
On Sat, Oct 3, 2015 at 1:44 PM, Ray Donnelly wrote:
> In normalize_ceiling_entry(), we test that normalized paths end with
> slash, *unless* the path to be normalized was already the root
> directory.
>
>
In normalize_ceiling_entry(), we test that normalized paths end with
slash, *unless* the path to be normalized was already the root
directory.
However, normalize_path_copy() does not even enforce this condition.
Even worse: on Windows, the root directory gets translated into a
Windows directory b
Karthik Nayak writes:
> - if (upstream_is_gone) {
> - if (show_upstream_ref)
> - strbuf_addf(stat, _("[%s: gone]"), fancy.buf);
The old string was translated, and you're replacing it with one which
isn't.
I'm not a big fan of translation, so that change doesn
Karthik Nayak writes:
> diff --git a/ref-filter.c b/ref-filter.c
> index 099acd6..48b06e3 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1133,8 +1133,10 @@ static void populate_value(struct ref_array_item *ref)
> char buf[40];
>
>
Karthik Nayak writes:
> Introduce format_ref_array_item() which will output the details of a
> given ref_array_item as per the given format and quote_style to the
> given strbuf.
Why do you need it in this series and you could do without for tag?
Going through PATCH 8/9, I guess there's somethi
Hello dear gitters,
I've been trying to use git-svn to work with branches. When I merge branch A
into branch B, and then do a dcommit, the change is not pushed to branch B.
I've attached a bash script that demonstrates the issue. I've tested with svn
1.9 and git 2.5.
The problem goes away when
Karthik Nayak writes:
> This adds %(path) and %(path:short) atoms. The %(path) atom will print
> the path of the given ref, while %(path:short) will only print the
> subdirectory of the given ref.
What does "path" mean in this context? How is it different from
%(refname)?
I found the answer bel
Karthik Nayak writes:
> Implement %(if), %(then) and %(else) atoms. Used as
> %(if)..%(then)..%(end) or %(if)..%(then)..%(else)..%(end).
I prefer ... to .., which often means "interval" as in HEAD^^..HEAD.
> If there is an atom with value or string literal after the %(if)
I find this explanati
Am 03.10.2015 um 09:37 schrieb Chris Packham:
On Sat, Oct 3, 2015 at 6:43 AM, Junio C Hamano wrote:
If you want to go interactive from the hook, you'd have to open and
interact with /dev/tty yourself in your hook anyway.
That may be what I have to do, although I have absolutely no idea how.
On Sat, Oct 3, 2015 at 6:43 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Chris Packham writes:
>>
>>> As of git 2.6 this has stopped working and stdin always fails the tty
>>> check.
>>
>> We now run that hook thru run_hook_ve(), which closes the standard
>> input (as the hook is not
On Sat, Oct 3, 2015 at 2:32 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> Add support for %(objectname:short,) which would print the
>> abbreviated unique objectname of given length. When no length is
>> specified 7 is used. The minimum length is 4.
>
> It would have to be "short=", not
On Sat, Oct 3, 2015 at 2:24 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> Implement %(if:equals=) wherein the if condition is only
>> satisfied if the value obtained between the %(if:...) and %(then) atom
>> is the same as the given ''.
>>
>> Similarly, implement (if:notequals=) wherein
On Sat, Oct 3, 2015 at 2:15 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> +static int is_empty(const char * s){
>> + while (*s != '\0') {
>> + if (!isspace(*s))
>> + return 0;
>> + s++;
>> + }
>> + return 1;
>> +}
>
> My knee-jerk r
35 matches
Mail list logo
