Re: SNI (SSL virtual hosts)

On Tue, 4 Jun 2013, Janusz Harkot wrote: valid point, but from what you can find on the web, the only solution provided everywhere was to disable certificate checking… so maybe that's not me, but this is first time someone spent some time to check whats going on :) I don't disagree with that

Re: [PATCH v5 5/7] add tests for rebasing merged history

Am 6/4/2013 19:18, schrieb Junio C Hamano: > Martin von Zweigbergk writes: > >> --- >> +#TODO: make all flavors of rebase use --topo-order >> +test_run_rebase success 'e n o' '' >> +test_run_rebase success 'e n o' -m >> +test_run_rebase success 'n o e' -i > > I do not quite follow this TODO. >

Re: [PATCH v5 5/7] add tests for rebasing merged history

On Tue, Jun 4, 2013 at 10:18 AM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> --- >> +#TODO: make all flavors of rebase use --topo-order >> +test_run_rebase success 'e n o' '' >> +test_run_rebase success 'e n o' -m >> +test_run_rebase success 'n o e' -i > > I do not quite follow thi

Re: [PATCH] Fix `git svn rebase` if top-level HEAD directory exist

On 04.06.2013 11:49, Jeff King wrote: This rationale should probably go in the commit message. Done We prefer patches to be inline in the email; these lines can be dropped, as they are picked up from your email headers. AFAIK Thunderbird brakes spaces, so better safe, than sorry :) Do y

[PATCH] gitweb: fix problem causing erroneous project list

The bug is manifest when running gitweb in a persistent process (e.g. FastCGI, PSGI), and it's easy to reproduce. If a gitweb request includes the searchtext parameter (i.e. s), subsequent requests using the project_list action--which is the default action--and without a searchtext parameter will

Re: [PATCH v5 1/7] add simple tests of consistency across rebase types

On Mon, Jun 3, 2013 at 11:15 PM, Johannes Sixt wrote: > Am 6/4/2013 7:14, schrieb Martin von Zweigbergk: >> On Mon, Jun 3, 2013 at 3:28 PM, Junio C Hamano wrote: + +# checks that the revisions in "$2" represent a linear range with the +# subjects in "$1" +test_linear_range ()

Re: [Administrivia] On ruby and contrib/

On 06/05/2013 02:04 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> * fc/contrib-related (2013-06-03) 4 commits >> - contrib: related: parse committish like format-patch >> - contrib: related: add option to parse from committish >> - contrib: related: add support for multiple patches >

Re: [Administrivia] On ruby and contrib/

On Tue, 4 Jun 2013, Junio C Hamano wrote: Junio C Hamano writes: On Ruby: Assuming "related" is a good idea, to make it as the proper part of the system out of contrib/ when its design review phase is finished, one of these things has to happen: 1. Find a volunteer to rewrite it in one of t

Re: git archive --worktree-attributes doesn't exclude .gitattributes anymore

On Tue, Jun 04, 2013 at 11:18:59PM +0100, Gianfranco Costamagna wrote: > git version 1.8.1.2 > [...] > I tried to put .gitattributes or .git/info/attributes, the file is the > following > http://pastebin.com/irngA1L8 > [...] > The archive gets created, but every file is inside, no exclusions at a

[Administrivia] On ruby and contrib/

Junio C Hamano writes: > * fc/contrib-related (2013-06-03) 4 commits > - contrib: related: parse committish like format-patch > - contrib: related: add option to parse from committish > - contrib: related: add support for multiple patches > - Add new git-related helper to contrib > > Waiting

What's cooking in git.git (Jun 2013, #02; Tue, 4)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We are in the post-1.8.3 cycle. As promised, 'next' has been rewound. A few stalled topics have been ejected and bunch of new topics that have

Re: [PATCH 02/15] for-each-ref: don't print out elements directly

On Wed, Jun 5, 2013 at 6:13 AM, Junio C Hamano wrote: > Ramkumar Ramachandra writes: > >> From: Nguyễn Thái Ngọc Duy >> >> Currently, the entire callchain starting from show_ref() parses and >> prints immediately. This inflexibility limits our ability to extend the >> parser. So, convert the e

Re: [PATCH 02/15] for-each-ref: don't print out elements directly

Ramkumar Ramachandra writes: > From: Nguyễn Thái Ngọc Duy > > Currently, the entire callchain starting from show_ref() parses and > prints immediately. This inflexibility limits our ability to extend the > parser. So, convert the entire callchain to accept a strbuf argument to > write to. Als

Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)

On Tue, Jun 4, 2013 at 8:48 AM, John Keeping wrote: > On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote: >> On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote: >> > On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote: >> > > On Mon, Jun 03, 2013 at 11:23:41PM +0100, Joh

I: git archive --worktree-attributes doesn't exclude .gitattributes anymore

Forgot to mention, also this command doesn't work git archive --worktree-attributes  -v --format tgz -o ../boinc_7.1.7+dfsg.orig.tar.gz -9 --prefix boinc-7.1.7+dfsg/ client_release/7.1/7.1.7 Gianfranco - Messaggio inoltrato - > Da: Gianfranco Costamagna > A: "git@vger.kernel.org"

git archive --worktree-attributes doesn't exclude .gitattributes anymore

git version 1.8.1.2 (please cc me, I'm not subscribed to this list) Hi Developers, I write here because since my ubuntu update (quantal to raring) and git update from 1.7.10.4-1ubuntu1 to 1.8.1.2 my export script doesn't work anymore. I tried to put .gitattributes or .git/info/attributes, the f

Re: [PATCH v3 0/6] git send-email suppress-cc=self fixes

"Michael S. Tsirkin" writes: > All I see in 2/6 is this: > > diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh > index e1a7f3e..f81e5f5 100755 > --- a/t/t9001-send-email.sh > +++ b/t/t9001-send-email.sh > @@ -204,13 +204,15 @@ test_suppress_self_unquoted ()

Re: [PATCH 07/11] t2100: use test_ln_s_add to remove SYMLINKS prerequisite

Johannes Sixt writes: > @@ -62,12 +57,7 @@ test_expect_success 'git update-index to add conflicting > file path2 should fail' > > test_expect_success 'git update-index to add conflicting symlink path3 > should fail' ' > > - if test_have_prereq SYMLINKS > - then > - ln -

Re: What's cooking in git.git (May 2013, #09; Wed, 29)

On Tue, Jun 04, 2013 at 11:39:25PM +0200, Jens Lehmann wrote: > Am 04.06.2013 14:48, schrieb John Keeping: > > The problem is that sometimes you do want to adjust the path and > > sometimes you don't. Reading git-submodule(1), it says: > > > > This may be either an absolute URL, or (if it be

Re: [PATCH 05/11] tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)

Johannes Sixt writes: > There are many instances where the treatment of symbolic links in the > object model and the algorithms are tested, but where it is not > necessary to actually have a symbolic link in the worktree. > diff --git a/t/t3000-ls-files-others.sh b/t/t3000-ls-files-others.sh > i

Re: [PATCH v3 0/6] git send-email suppress-cc=self fixes

On Tue, Jun 04, 2013 at 10:40:51AM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" writes: > > > This includes bugfixes related to handling of --suppress-cc=self > > flag. Tests are also included. > > Hmph, flipped the patches without test-applying first? No, I generated the patches with gi

Re: What's cooking in git.git (May 2013, #09; Wed, 29)

Am 04.06.2013 14:48, schrieb John Keeping: > On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote: >> On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote: >>> On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote: On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wro

Re: SNI (SSL virtual hosts)

valid point, but from what you can find on the web, the only solution provided everywhere was to disable certificate checking… so maybe that's not me, but this is first time someone spent some time to check whats going on :) at least there will be something, maybe this will help someone… thanks

Re: git-daemon: needs /root/.config/git/config?

Jeff King writes: > On Tue, Jun 04, 2013 at 12:10:25PM -0700, Jonathan Nieder wrote: > >> >> However, since changing user id and leaving $HOME is so common, there is >> >> a patch under consideration to loosen the check only for the case of >> >> EACCES on files in $HOME. That commit is 4698c8f (

Re: [PATCH/RFC] rev-list: add --authorship-order alternative ordering

On Tue, Jun 04, 2013 at 12:14:21PM -0700, Junio C Hamano wrote: > > diff --git a/commit.h b/commit.h > > index 67bd509..de07525 100644 > > --- a/commit.h > > +++ b/commit.h > > @@ -17,6 +17,7 @@ struct commit { > > void *util; > > unsigned int indegree; > > unsigned long date; > > +

Re: [PATCH/RFC] rev-list: add --authorship-order alternative ordering

Junio C Hamano writes: >> @@ -301,7 +328,8 @@ int parse_commit_buffer(struct commit *item, const void >> *buffer, unsigned long s >> pptr = &commit_list_insert(new_parent, pptr)->next; >> } >> } >> -item->date = parse_commit_date(bufptr, tail); >> +

Re: SNI (SSL virtual hosts)

On Tue, 4 Jun 2013, Janusz Harkot wrote: What makes you suggest that's what's happening? Sure, if it would've sent no or the wrong host name it would probably have that effect. line: [36] * Re-using existing connection! (#0) with host (nil) Ah that. Yes, that's a stupid line to show (that b

Re: [PATCH 15/15] for-each-ref: use get_pretty_userformat in --pretty

On Tue, Jun 4, 2013 at 8:35 AM, Ramkumar Ramachandra wrote: > Use get_pretty_userformat() to interpret the --pretty string. This > means that leading you can now reference a format specified in a pretty.* s/leading// perhaps? > configuration variable as an argument to 'git for-each-ref --pretty

Re: [PATCH 12/15] for-each-ref: introduce %(upstream:track[short])

On Tue, Jun 4, 2013 at 8:35 AM, Ramkumar Ramachandra wrote: > Introduce %(upstream:track) to display "[ahead M, behind N]" and > %(upstream:trackshort) to display "=", ">", "<", or "<>" > appropriately (inspired by the contrib/completion/git-prompt.sh). Bikeshedding: s/trackshort/trackbrief/ perh

Re: [PATCH 08/15] for-each-ref: get --pretty using format_commit_message

On Tue, Jun 4, 2013 at 8:35 AM, Ramkumar Ramachandra wrote: > From: Nguyễn Thái Ngọc Duy > > [rr: documentation] > > Signed-off-by: Ramkumar Ramachandra > --- > Documentation/git-for-each-ref.txt | 22 - > builtin/for-each-ref.c | 67 > ++

Re: [PATCH] t/README: test_must_fail is for testing Git

From: "Junio C Hamano" Sent: Tuesday, June 04, 2013 9:49 PM "Philip Oakley" writes: From: "Junio C Hamano" Sent: Tuesday, June 04, 2013 5:50 PM When a test wants to make sure there is no in an output file, we should just say "! grep string output"; Small nit: It took me two readings of t

Re: [PATCH 05/11] tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)

Johannes Sixt writes: > There are many instances where the treatment of symbolic links in the > object model and the algorithms are tested, but where it is not > necessary to actually have a symbolic link in the worktree. Make > adjustments to the tests and remove the SYMLINKS prerequisite when >

Re: git-daemon: needs /root/.config/git/config?

On Tue, Jun 04, 2013 at 12:10:25PM -0700, Jonathan Nieder wrote: > >> However, since changing user id and leaving $HOME is so common, there is > >> a patch under consideration to loosen the check only for the case of > >> EACCES on files in $HOME. That commit is 4698c8f (config: allow > >> inacces

Re: [PATCH] diff: add --ignore-blank-lines option

On Tue, Jun 4, 2013 at 10:46 PM, Junio C Hamano wrote: > OK. Thanks. > > I think the logic would be more like: > > 1. Start from xscr, find the first xchp that is !xchp->ignore; > if there is none, we are done. There is no more to show. > > 2. Remember the xchp as the beginning. > > 3. Tan

Re: [PATCH] t/README: test_must_fail is for testing Git

"Philip Oakley" writes: > From: "Junio C Hamano" > Sent: Tuesday, June 04, 2013 5:50 PM >> When a test wants to make sure there is no in an output >> file, we should just say "! grep string output"; > > Small nit: It took me two readings of the commit message to correctly > parse this break poi

Re: [PATCH] diff: add --ignore-blank-lines option

Antoine Pelisse writes: > On Tue, Jun 4, 2013 at 8:26 PM, Junio C Hamano wrote: >> Antoine Pelisse writes: >> >>> +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg) { >>> xdchange_t *xch, *xchp; >>> long max_common = 2 * xecfg->ctxlen + xecfg->interhunkctxlen; >

Re: [PATCH] t/README: test_must_fail is for testing Git

From: "Junio C Hamano" Sent: Tuesday, June 04, 2013 5:50 PM When a test wants to make sure there is no in an output file, we should just say "! grep string output"; Small nit: It took me two readings of the commit message to correctly parse this break point. The flowing together of the two p

Re: git-daemon: needs /root/.config/git/config?

Jonathan Nieder writes: > I could be remembering wrong, but I thought it was not so much "under > consideration" as "accepted for 1.8.4". I haven't heard any > compelling reasons not to apply it. > > Would it would make sense against earlier releases as well? True; the patch is queued on a topi

Re: [PATCH/RFC] rev-list: add --authorship-order alternative ordering

elliottcable writes: > --date-order is an excellent alternative to --topo-order if you want a feel > for > the *actual history*, chronologically, of your project. I use it often, with > --graph as well; it's a great way to get an overview of a project's recent > development history. > > However,

Re: git-daemon: needs /root/.config/git/config?

Johannes Sixt wrote: > Am 04.06.2013 18:08, schrieb Jeff King: >> However, since changing user id and leaving $HOME is so common, there is >> a patch under consideration to loosen the check only for the case of >> EACCES on files in $HOME. That commit is 4698c8f (config: allow >> inaccessible conf

Re: [PATCH] diff: add --ignore-blank-lines option

On Tue, Jun 4, 2013 at 8:26 PM, Junio C Hamano wrote: > Antoine Pelisse writes: > >> +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg) { >> xdchange_t *xch, *xchp; >> long max_common = 2 * xecfg->ctxlen + xecfg->interhunkctxlen; >> + long ignorable_context =

Re: git-daemon: needs /root/.config/git/config?

Am 04.06.2013 18:08, schrieb Jeff King: > Older versions of git silently ignored errors reading config files, but > it was tightened in v1.8.1.1, as there can be quite serious implications > to failing to read expected config (e.g., imagine transfer.fsckobjects, > or receive.deny* is ignored). > >

Re: [PATCH/RFC] add --authorship-order flag to git log / rev-list

elliottcable writes: > This is my first time submitting a patch to this list, so please, let me know > if > I'm doing any of this the wrong way! I've striven to follow > `Documentation/SubmittingPatches`. I hope I've succeeded. For that matter, > it's > my first time diving into git's sources,

Re: [PATCH] git-remote-mediawiki: use git.pm functions for credentials

benoit.per...@gmail.com writes: > From: Benoit Person > > In 52dce6d, a new credential function was added to git.pm, based on > git-remote-mediawiki's functions. The logical follow-up is to use > those functions in git-remote-mediawiki. > > Signed-off-by: Benoit Person > Signed-off-by: Matthieu

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Felipe Contreras writes: > You didn't answer, what happens when you run --skip-empty and --allow-empty? I'll answer to a slightly different question: What should happen? I think it should error out, because --allow-empty is about "allowing empty commits to be preserved", and --skip-empty is abo

Re: [PATCH] diff: add --ignore-blank-lines option

Antoine Pelisse writes: > +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg) { > xdchange_t *xch, *xchp; > long max_common = 2 * xecfg->ctxlen + xecfg->interhunkctxlen; > + long ignorable_context = max_common / 2 - 1; Could you explain how this math works? A

[PATCH/RFC] rev-list: add --authorship-order alternative ordering

--date-order is an excellent alternative to --topo-order if you want a feel for the *actual history*, chronologically, of your project. I use it often, with --graph as well; it's a great way to get an overview of a project's recent development history. However, in a project that rebases various in

[PATCH/RFC] add --authorship-order flag to git log / rev-list

This is my first time submitting a patch to this list, so please, let me know if I'm doing any of this the wrong way! I've striven to follow `Documentation/SubmittingPatches`. I hope I've succeeded. For that matter, it's my first time diving into git's sources, so I obviously would love some commen

Re: Can `git blame` show the date that each line was merged?

On Tue, Jun 04, 2013 at 10:28:06AM -0700, Junio C Hamano wrote: > > (though I suspect it would interact oddly with the "--reverse" option, > > and we would want to either declare them mutually exclusive or figure > > out some sane semantics). > > It is entirely unclear who the first child is, so

Re: [PATCH v3 0/6] git send-email suppress-cc=self fixes

"Michael S. Tsirkin" writes: > This includes bugfixes related to handling of --suppress-cc=self > flag. Tests are also included. Hmph, flipped the patches without test-applying first? 2/6 adds two lines to test_suppress_self_quoted helper function, but that is introduced only at 4/6. > > Chang

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Tue, Jun 4, 2013 at 12:35 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >>> I think just "Skip commits that are or become empty" without saying >>> "Instead of failing," is fine, too. >> >> I think "Instead of failing" makes perfect sense, because it's not our >> job to describe what

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

Felipe Contreras writes: >> I think just "Skip commits that are or become empty" without saying >> "Instead of failing," is fine, too. > > I think "Instead of failing" makes perfect sense, because it's not our > job to describe what other options do,... > ... > simply explain what this option > d

Re: Can `git blame` show the date that each line was merged?

Jeff King writes: > diff --git a/builtin/blame.c b/builtin/blame.c > index 57a487e..0fb67af 100644 > --- a/builtin/blame.c > +++ b/builtin/blame.c > @@ -1199,6 +1199,8 @@ static int num_scapegoats(struct rev_info *revs, struct > commit *commit) > { > int cnt; > struct commit_list *l

Re: Can `git blame` show the date that each line was merged?

On Tue, Jun 4, 2013 at 11:56 AM, Jeff King wrote: >> Aside: in some trial and error I notice this oddity: >> >> $ git blame --merges >> usage: git blame [options] [rev-opts] [rev] [--] file >> >> [rev-opts] are documented in git-rev-list(1) >> ... > > Your problem is not the pr

Re: [PATCH v5 5/7] add tests for rebasing merged history

Martin von Zweigbergk writes: > --- > +#TODO: make all flavors of rebase use --topo-order > +test_run_rebase success 'e n o' '' > +test_run_rebase success 'e n o' -m > +test_run_rebase success 'n o e' -i I do not quite follow this TODO. While I think it would be nice to update "rebase" so that

Re: SNI (SSL virtual hosts)

> What makes you suggest that's what's happening? Sure, if it would've sent no > or the wrong host name it would probably have that effect. line: [36] * Re-using existing connection! (#0) with host (nil) > Any chance you can snoop on the network and the SSL handshake to see who's to > > bl

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

On Mon, Jun 3, 2013 at 4:45 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >>> Pretty much what it says on the tin. Signed-off-by: Felipe Contreras --- Documentation/git-cher

[PATCH] t/README: test_must_fail is for testing Git

When a test wants to make sure there is no in an output file, we should just say "! grep string output"; "test_must_fail" is there only to test Git command and catch unusual deaths we know about (e.g. segv) as an error, not as an expected failure. Signed-off-by: Junio C Hamano --- t/README | 3

Re: Git status reports untracked on tracked files

Am 04.06.2013 11:05, schrieb Andrey Kiyanovsky: > I have tried Git 1.8.3 for Windows. Case is fixed. Thank you very much! > > 2013/6/4 Jeff King : >> On Wed, May 29, 2013 at 11:40:56AM +0300, Andrey Kiyanovsky wrote: >> >>> Git version 1.8.1.2. for Windows >>> >>> Git config: >>> >>> [core] >>>

Re: *** glibc detected *** git: double free or corruption (fasttop): 0x0000000001fab820 ***

On 06/04/2013 05:46 PM, Jason Gross wrote: > I get "*** glibc detected *** git: double free or corruption > (fasttop): 0x01fab820 ***" reliably on the following set of > commands. I'm working on a remote machine where I don't have > administrative privileges, so I can't update from git 1.7

Re: *** glibc detected *** git: double free or corruption (fasttop): 0x0000000001fab820 ***

On Tue, Jun 04, 2013 at 11:46:55AM -0400, Jason Gross wrote: > I get "*** glibc detected *** git: double free or corruption > (fasttop): 0x01fab820 ***" reliably on the following set of > commands. I'm working on a remote machine where I don't have > administrative privileges, so I can't

:6/4/2013 5:25:42 PM:

http://thielois.free.fr/kk/miwrmacrfkhwwidtajnzttpnim.bnopj -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dir.c: fix ignore processing within not-ignored directories

Am 02.06.2013 21:25, schrieb Junio C Hamano: > Duy Nguyen writes: > >>> + then >>> + false >>> + fi >>> +' >> >> Nit pick, maybe this instead? >> >> test_must_fail grep "^one/a.1" output > > Neither. > > ! grep "^one/a.1" output > Nice. I actually tried "!" but

Re: git-daemon: needs /root/.config/git/config?

On Tue, Jun 04, 2013 at 04:13:14PM +0200, Ian Kumlien wrote: > Due to the earlier problem I upgraded git on all machines > and eneded up with a ubunut machine running in to problems. > > I started getting errors like: > "fatal: protocol error: bad line length character: fata" > > Which after so

Re: Can `git blame` show the date that each line was merged?

On Tue, Jun 04, 2013 at 09:39:45AM -0400, Matt McClure wrote: > Can `git blame` show the date that each line was merged to the current > branch rather than the date it was committed? Not exactly. Git does not record when a commit entered a particular branch (or what the "ours" branch was called d

*** glibc detected *** git: double free or corruption (fasttop): 0x0000000001fab820 ***

I get "*** glibc detected *** git: double free or corruption (fasttop): 0x01fab820 ***" reliably on the following set of commands. I'm working on a remote machine where I don't have administrative privileges, so I can't update from git 1.7.2.5 to a newer version. I figured I'd report it,

Re: [PATCH 3/7] unpack-trees: factor out dup_entry

René Scharfe: While we're add it, "add" → "at" -- \\// Peter - http://www.softwolves.pp.se/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

git-daemon: needs /root/.config/git/config?

Hi again, Due to the earlier problem I upgraded git on all machines and eneded up with a ubunut machine running in to problems. I started getting errors like: "fatal: protocol error: bad line length character: fata" Which after some head scratching caused me to tell xinetd to directly launch g

Can `git blame` show the date that each line was merged?

Can `git blame` show the date that each line was merged to the current branch rather than the date it was committed? Aside: in some trial and error I notice this oddity: $ git blame --merges usage: git blame [options] [rev-opts] [rev] [--] file [rev-opts] are documented in git-re

Re: [PATCH v2 0/3] Towards a useable git-branch

On Tue, Jun 4, 2013 at 7:52 PM, Ramkumar Ramachandra wrote: > Duy Nguyen wrote: >> Nobody should ever parse these output >> with scripts. The color can be generated from color.branch.*. > > How do we implement color.branch.(current|local|remote|plain)? In the > current code, we take a crude appro

Re: [PATCH 15/15] for-each-ref: use get_pretty_userformat in --pretty

On Tue, Jun 4, 2013 at 7:35 PM, Ramkumar Ramachandra wrote: > Use get_pretty_userformat() to interpret the --pretty string. This > means that leading you can now reference a format specified in a pretty.* > configuration variable as an argument to 'git for-each-ref --pretty='. > There are two cav

Re: [PATCH 10/15] for-each-ref: introduce format specifier %>(*) and %<(*)

On Tue, Jun 4, 2013 at 7:35 PM, Ramkumar Ramachandra wrote: > +static unsigned int get_atom_width(struct format_one_atom_context *ctx, > + const char *start, const char *end) > +{ > + struct strbuf sb = STRBUF_INIT; > + int i, atom = parse_atom(start, e

[no subject]

Отправлено с iPhone

Re: [PATCH v2 0/3] Towards a useable git-branch

Duy Nguyen wrote: > Nobody should ever parse these output > with scripts. The color can be generated from color.branch.*. How do we implement color.branch.(current|local|remote|plain)? In the current code, we take a crude approach by hand-constructing argc, argv strings and passing it to cmd_for_

Re: [PATCH 00/15] Towards a more awesome git-branch

On Tue, Jun 4, 2013 at 7:35 PM, Ramkumar Ramachandra wrote: > Hi, > > Duy and I have been working on this topic for some time now. Here's a > review candidate. I'm still hung up one the detached HEAD thing. It's a bit quirky to put in for-each-ref, but for-each-ref can't truly replace branch --l

Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)

On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote: > On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote: > > On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote: > > > On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote: > > > > > Sorry, I should have been more

[PATCH 05/15] pretty: extend pretty_print_context with callback

From: Nguyễn Thái Ngọc Duy The struct pretty_print_context contains the context in which the placeholders in format_commit_one() should be parsed. Although format_commit_one() primarily acts as a parser, there is no way for a caller to plug in custom callbacks. Now, callers can: 1. Parse a cus

[PATCH 11/15] for-each-ref: introduce %(HEAD) marker

'git branch' shows which branch you are currently on with an '*', but 'git for-each-ref' misses this feature. So, extend the format with %(HEAD) to do exactly the same thing. Now you can use the following format in for-each-ref: %C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset) to di

[PATCH 10/15] for-each-ref: introduce format specifier %>(*) and %<(*)

From: Nguyễn Thái Ngọc Duy Pretty placeholders %>(N) and %<(N) require a user provided width N, which makes sense because the commit chain could be really long and the user only needs to look at a few at the top, going to the end just to calculate the best width wastes CPU cycles. for-each-ref i

[PATCH 02/15] for-each-ref: don't print out elements directly

From: Nguyễn Thái Ngọc Duy Currently, the entire callchain starting from show_ref() parses and prints immediately. This inflexibility limits our ability to extend the parser. So, convert the entire callchain to accept a strbuf argument to write to. Also introduce a show_refs() helper that call

[PATCH 04/15] quote: remove sq_quote_print()

Remove sq_quote_print() since it has no callers. A nicer alternative sq_quote_buf() exists: its callers aren't forced to print immediately. For historical context, sq_quote_print() was first introduced in 575ba9d6 (GIT_TRACE: show which built-in/external commands are executed, 2006-06-25) for the

[PATCH 12/15] for-each-ref: introduce %(upstream:track[short])

Introduce %(upstream:track) to display "[ahead M, behind N]" and %(upstream:trackshort) to display "=", ">", "<", or "<>" appropriately (inspired by the contrib/completion/git-prompt.sh). Now you can use the following format in for-each-ref: %C(green)%(refname:short)%C(reset)%(upstream:tracksho

[PATCH 08/15] for-each-ref: get --pretty using format_commit_message

From: Nguyễn Thái Ngọc Duy --format is very limited in its capabilities. Introduce --pretty, which extends the existing --format with pretty-formats. In --pretty: - Existing --format %(atom) is available. They also accept some pretty magic. For example, you can use "% (atom)" to only disp

[PATCH 14/15] pretty: introduce get_pretty_userformat

This helper function is intended to be used by callers implementing --pretty themselves; it parses pretty.* configuration variables recursively and hands the user-defined format back to the caller. No builtins are supported, as CMT_FMT_* are really only useful when displaying commits. Callers mig

[PATCH 06/15] pretty: limit recursion in format_commit_one()

To make sure that a pretty_ctx->format substitution doesn't result in an infinite recursion, change the prototype of format_commit_one() to accept one last argument: no_recurse. So, a single substitution by format() must yield a result that can be parsed by format_commit_one() without the help of

[PATCH 07/15] pretty: allow passing NULL commit to format_commit_message()

From: Nguyễn Thái Ngọc Duy The new formatter, for-each-ref, may use non-commit placeholders only. While it could audit the format line and warn/exclude commit placeholders, that's a lot more work than simply ignore them. Unrecognized placeholders are displayed as-is, pretty obvious that they are

[PATCH 15/15] for-each-ref: use get_pretty_userformat in --pretty

Use get_pretty_userformat() to interpret the --pretty string. This means that leading you can now reference a format specified in a pretty.* configuration variable as an argument to 'git for-each-ref --pretty='. There are two caveats: 1. A leading "format:" or "tformat:" is automatically stripped

[PATCH 03/15] tar-tree: remove dependency on sq_quote_print()

Currently, there is exactly one caller of sq_quote_print(), namely cmd_tar_tree(). In the interest of removing sq_quote_print() and simplification, replace it with an equivalent call to sq_quote_argv(). No functional changes intended. Signed-off-by: Ramkumar Ramachandra --- builtin/tar-tree.c |

[PATCH 13/15] for-each-ref: improve responsiveness of %(upstream:track)

From: Nguyễn Thái Ngọc Duy Before anything is printed, for-each-ref sorts all refs first. As part of the sorting, populate_value() is called to fill the values in for all atoms/placeholders per entry. By the time sort_refs() is done, pretty much all data is already retrieved. This works fine wh

[PATCH 09/15] for-each-ref: teach verify_format() about pretty's syntax

From: Nguyễn Thái Ngọc Duy Pretty format accepts either ' ', '+' or '-' after '%' and before the placeholder name to modify certain behaviors. Teach verify_format() about this so that it finds atom "upstream" in, for example, '% (upstream)'. This is important because verify_format populates used_

[PATCH 00/15] Towards a more awesome git-branch

Hi, Duy and I have been working on this topic for some time now. Here's a review candidate. Duy did most of the chunky work, and I mostly did review/documentation. The key patches are: [5/15] is a brilliant patch that made this entire thing possible. [10/15] is another brilliant patch to auto

[PATCH 01/15] for-each-ref, quote: convert *_quote_print -> *_quote_buf

From: Nguyễn Thái Ngọc Duy for-each-ref.c:print_value() currently prints values to stdout immediately using {sq|perl|python|tcl}_quote_print, giving us no opportunity to do any further processing. In preparation for getting print_value() to accept an additional strbuf argument to write to, conve

Re: SNI (SSL virtual hosts)

On Tue, 4 Jun 2013, Janusz Harkot wrote: Which libcurl version and SSL backend is this? (curl -V usually tells) $ curl -V curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 From what I can tell, that OpenSSL version supports SNI fine and libcurl has supported it

Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)

On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote: > On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote: > > On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote: > > > > Sorry, I should have been more specific here. I saw that you did some > > > > changes to make "submo

[PATCH] git-remote-mediawiki: use git.pm functions for credentials

From: Benoit Person In 52dce6d, a new credential function was added to git.pm, based on git-remote-mediawiki's functions. The logical follow-up is to use those functions in git-remote-mediawiki. Signed-off-by: Benoit Person Signed-off-by: Matthieu Moy --- contrib/mw-to-git/git-remote-mediawik

Re: SNI (SSL virtual hosts)

> It does. git uses libcurl for the HTTPS parts and it has support SNI for a > long time, assuming you built libcurl with a TLS library that handles it. > > Which libcurl version and SSL backend is this? (curl -V usually tells) $ curl -V curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSS

fetch delta resolution vs. checkout (was: java zlib woes)

On Mon, 27 May 2013 06:11:46 +, Andreas Krey wrote: ... > > I now have a full test case (involving a generated repo just shy of 1GB) > that will reproduce that hang. Will look up the existing jgit bug to > report there. On https://bugs.eclipse.org/bugs/show_bug.cgi?id=394078 A question: The

Re: SNI (SSL virtual hosts)

On Tue, 4 Jun 2013, Janusz Harkot wrote: Strange was, that initial communication was OK (http GET), but when there was http POST - git reported error (incorrect certificate). The only workaround was to disable certificate verification. My question is: does git support SNI on the https? If so

Nike - die Eleganz von innen heraus

Eine größere nike blazer low Anzahl von Personen in der Erde nutzen irgendeine Art von Turnschuhen täglich. Es gibt eine große Auswahl mit Bezug zur Auswahl. Die historische Vergangenheit von Turnschuhen hat eine große Vielzahl von Ände

Verbessern Sie den persönlichen Geschmack an lebensnotwendigen Gütern

Leichtathletik Nike Air Jordan begann, weil Leinwand besten und Gummisohlen Schuhe oder Stiefel mit zu gesehen worden, weil Turnschuhe. US Rubber die Firma Keds verwendet, um die primären sehr Turnschuhe im Jahr 1917 zu vermarkten. Generell Tu

  1   2   >