Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

Junio C Hamano writes: > Johannes Schindelin writes: > >> Subject: Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally >> remote ref name > > No verb? s/optionally/report/ perhaps? I just noticed that I didn't tweak the copy I have in

Re: [PATCH] checkout doc: clarify command line args for "checkout paths" mode

Junio C Hamano wrote: > here is another attempt, this time to avoid "Restore" and ... > > Documentation/git-checkout.txt | 30 -- > 1 file changed, 16 insertions(+), 14 deletions(-) Thanks. I find this one easier to read indeed. [...] > ---

Darlehensangebot

Guten Tag Sir / ma, Wir. ICBC Finance Company hier in der Türkei gewährt Darlehen an Kunden mit 3% Zinssatz. und auch Geld für Investitionen und andere finanzielle Zwecke unabhängig von ihrem Standort, Geschlecht, Familienstand, Bildung, Jobstatus, aber müssen eine gesetzliche

Re: [PATCH] checkout doc: clarify command line args for "checkout paths" mode

Jonathan Nieder writes: >> +'git checkout' [] [--] ... >> -'git checkout' [-p|--patch] [] [--] [...] >> +'git checkout' (-p|--patch) [] [--] [...] > ... > Even for this particular form, the current file is inconsistent about > whether to call the arguments '...' or '...'. >

Re: [RFC] column: show auto columns when pager is active

On Tue, Oct 10, 2017 at 07:02:00PM +0200, Martin Ågren wrote: > On 10 October 2017 at 16:01, Jeff King wrote: > > On Tue, Oct 10, 2017 at 12:30:49PM +0200, Martin Ågren wrote: > >> On 9 October 2017 at 23:45, Kevin Daudt wrote: > >> > Since ff1e72483 (tag: change

Re: [PATCH] checkout doc: clarify command line args for "checkout paths" mode

Hi, Junio C Hamano wrote: [...] > The source of the confusion is that -p(atch) is described as if it > is just another "optional" part and its description is lumped > together with the non patch mode, even though the actual end user > experience is vastly different. Makes sense. This should

[PATCH] checkout doc: clarify command line args for "checkout paths" mode

There are "git checkout [-p][][--][...]" in the SYNOPSIS section, and "git checkout [-p][][--]..." as the header for the section that explains the "check out paths from index/tree-ish" mode. It is unclear if we require at least one path, or it is entirely optional. Actually, both are wrong.

Re: [PATCH v2 1/3] for-each-ref: let upstream/push optionally report the remote name

Johannes Schindelin writes: > The implementation chooses *not* to DWIM the push remote if no explicit > push remote was configured; The reason is that it is possible to DWIM this > by using > > %(if)%(push:remotename)%(then) > %(push:remotename) >

Re: What happened to "git status --color=(always|auto|never)"?

Jeff King writes: > On Tue, Oct 10, 2017 at 12:03:14PM -0700, Jonathan Nieder wrote: > >> Where I worry is about commands where the line between porcelain and >> plumbing blur, like "git log --format=raw". I actually still prefer >> the approach where "color.ui=always" becomes

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

Jonathan Nieder writes: > If we want to make the advertised protocol versions on the server side > configurable, I think it should be independent from the configuration > for protocol versions to use on the client side. Rationale: > > - As a client-side user, I may want to

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

Junio C Hamano writes: > A few questions that come to mind are: > > - Does "git add sub/" have enough information to populate >.gitmodules? If we have reasonable "default" values for >.gitmodules entries (e.g. missing URL means we won't fetch when >asked to go

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

On Tue, Oct 10, 2017 at 4:31 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> So you propose to make git-add behave like "git submodule add" >> (i.e. also add the .gitmodules entry for name/path/URL), which I >> like from a submodule perspective. >>

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

Stefan Beller writes: > So you propose to make git-add behave like "git submodule add" > (i.e. also add the .gitmodules entry for name/path/URL), which I > like from a submodule perspective. > > However other users of gitlinks might be confused[1], which is why > I refrained

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

On Tue, Oct 10, 2017 at 2:17 PM, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > >> Given some of this discussion though, maybe we want to change the >> semantics of 'protocol.version' so that both servers and clients respect >> it. I have no preference for this,

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

On Tue, 3 Oct 2017 13:15:00 -0700 Brandon Williams wrote: > +enum protocol_version determine_protocol_version_server(void) > +{ > + const char *git_protocol = getenv(GIT_PROTOCOL_ENVIRONMENT); > + enum protocol_version version = protocol_v0; > + > + /* > + *

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

Hi, Brandon Williams wrote: > Given some of this discussion though, maybe we want to change the > semantics of 'protocol.version' so that both servers and clients respect > it. As of right now, these patches have the server always allow > protocol v0 and v1? Though that doesn't do much right

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

On 10/06, Martin Ågren wrote: > On 6 October 2017 at 11:40, Junio C Hamano wrote: > > Simon Ruderich writes: > > > >> Did you consider Stefan Beller's suggestion regarding a > >> (white)list of allowed versions? > >> > >> On Mon, Sep 18, 2017 at 01:06:59PM

Re: "git rm" seems to do recursive removal even without "-r"

On Tue, 10 Oct 2017, Paul Smith wrote: > On Tue, 2017-10-10 at 04:36 -0400, Robert P. J. Day wrote: > >   ah, now *that* is a compelling rationale that justifies the > > underlying weirdness. but it still doesn't explain the different > > behaviour between: > > > >   $ git rm -n 'Makefile*' > >  

[PATCH] Documentation: document Extra Parameters

Document the server support for Extra Parameters, additional information that the client can send in its first message to the server during a Git client-server interaction. Signed-off-by: Jonathan Tan --- I noticed that Documentation/technical was not updated in this

Re: What happened to "git status --color=(always|auto|never)"?

On Tue, Oct 10, 2017 at 12:03:14PM -0700, Jonathan Nieder wrote: > > I do wonder if people would end up seeing some corner cases as > > regressions, though. Right now "diff-tree" _does_ color the output by > > default, and it would stop doing so under your scheme. That's the right > > thing to do

Re: What happened to "git status --color=(always|auto|never)"?

Hi, Jeff King wrote: > On Tue, Oct 10, 2017 at 09:51:38PM +0900, Junio C Hamano wrote: >> I think the right fix to the original problem (you cannot remove >> auto-color from the plumbing) is to stop paying attention to color >> configuration from the default config. I wonder if something like

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

On Tue, Oct 10, 2017 at 6:03 AM, Heiko Voigt wrote: >> > As mentioned in the cover letter. This seems to be the only test that >> > ensures that we stay compatible with setups without .gitmodules. Maybe >> > we should add/revive some? >> >> An interesting discussion covering

Re: [RFC] column: show auto columns when pager is active

On Tue, Oct 10, 2017 at 07:04:42PM +0200, Martin Ågren wrote: > On 10 October 2017 at 16:29, Jeff King wrote: > > On Tue, Oct 10, 2017 at 10:10:19AM -0400, Jeff King wrote: > > > > it will randomly succeed or fail, depending on whether sed manages to > > read the input before the

Re: [PATCH v3 07/10] connect: tell server that the client understands v1

On Tue, 3 Oct 2017 13:15:04 -0700 Brandon Williams wrote: > 2. ssh://, file:// >Set 'GIT_PROTOCOL' environment variable with the desired protocol >version. With the file:// transport, 'GIT_PROTOCOL' can be set >explicitly in the locally running git-upload-pack or

Re: [PATCH v3 05/10] upload-pack, receive-pack: introduce protocol version 1

On Tue, 3 Oct 2017 13:15:02 -0700 Brandon Williams wrote: > + switch (determine_protocol_version_server()) { > + case protocol_v1: > + if (advertise_refs || !stateless_rpc) > + packet_write_fmt(1, "version 1\n"); > + /* > +

Re: [PATCH v3 04/10] daemon: recognize hidden request arguments

On Tue, 3 Oct 2017 13:15:01 -0700 Brandon Williams wrote: > /* > * Read the host as supplied by the client connection. The return value is probably worth documenting. Something like "Returns a pointer to the character *after* the NUL byte terminating the host argument, or

Re: [PATCH v3 02/10] pkt-line: add packet_write function

On Tue, 3 Oct 2017 13:14:59 -0700 Brandon Williams wrote: > +void packet_write(const int fd_out, const char *buf, size_t size) No need for "const" in "const int fd_out", I think. Same comment for the header file. > +{ > + if (packet_write_gently(fd_out, buf, size)) > +

Re: [PATCH v3 01/10] connect: in ref advertisement, shallows are last

On Tue, 3 Oct 2017 13:14:58 -0700 Brandon Williams wrote: > +static int process_dummy_ref(void) > +{ > + struct object_id oid; > + const char *name; > + > + if (parse_oid_hex(packet_buffer, , )) > + return 0; > + if (*name != ' ') > +

Re: [PATCH] submodule: avoid sentence-lego in translated string

On 10 October 2017 at 04:35, Changwoo Ryu wrote: > 2017-10-10 10:26 GMT+09:00 Junio C Hamano : >> Jean-Noël AVILA writes: >> >>> On Monday, 9 October 2017, 09:47:26 CEST Stefan Beller wrote: >>> I always assumed that translators are

Re: [RFC] column: show auto columns when pager is active

On 10 October 2017 at 16:29, Jeff King wrote: > On Tue, Oct 10, 2017 at 10:10:19AM -0400, Jeff King wrote: > > it will randomly succeed or fail, depending on whether sed manages to > read the input before the stdin terminal is closed. > > I'm not sure of an easy way to fix

Re: [RFC] column: show auto columns when pager is active

On 10 October 2017 at 16:01, Jeff King wrote: > On Tue, Oct 10, 2017 at 12:30:49PM +0200, Martin Ågren wrote: >> On 9 October 2017 at 23:45, Kevin Daudt wrote: >> > Since ff1e72483 (tag: change default of `pager.tag` to "on", >> > 2017-08-02), the pager has been

Re: git download issue

On Tue, Oct 10, 2017 at 03:45:38PM +0200, Anthony Chevalet wrote: > I can't download git for windows from https://git-scm.com/downloads > > https://git-scm.com/download/win redirects to https://git-scm.com/downloads > > Any hint? Thanks for reporting. This should be fixed now, and is related

Re: [RFC] column: show auto columns when pager is active

On Tue, Oct 10, 2017 at 10:10:19AM -0400, Jeff King wrote: > That said, I'm still puzzled why it would return zero output. Strace > shows that the read from stdin is getting no input. I suspect this may > have to do with how we redirect stdin in test-terminal.perl. > > See 18d8c26930

Re: [RFC] column: show auto columns when pager is active

On Mon, Oct 09, 2017 at 11:45:43PM +0200, Kevin Daudt wrote: > +test_expect_success TTY '20 columns, mode auto, pager' ' > + cat >expected <<\EOF && > +oneseven > +twoeight > +three nine > +four ten > +five eleven > +six > +EOF > + test_terminal env PAGER="cat|cat" git column

Re: [RFC] column: show auto columns when pager is active

On Tue, Oct 10, 2017 at 12:30:49PM +0200, Martin Ågren wrote: > On 9 October 2017 at 23:45, Kevin Daudt wrote: > > When columns are set to automatic for git tag and the output is > > paginated by git, the output is a single column instead of multiple > > columns. > > > > Standard

git download issue

Hello, I can't download git for windows from https://git-scm.com/downloads https://git-scm.com/download/win redirects to https://git-scm.com/downloads Any hint? Thanks, Anthony

Re: [PATCH 1/2] describe: do not use cmd_*() as a subroutine

> The cmd_foo() function is a moral equivalent of 'main' for a Git > subcommand 'git foo', and as such, it is allowed to do many things > that make it unsuitable to be called as a subroutine, including > > - call exit(3) to terminate the process; > > - allocate resource held and used

Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

On Tue, Oct 10, 2017 at 09:11:15AM -0400, Derrick Stolee wrote: > On 10/10/2017 8:56 AM, Junio C Hamano wrote: > > Jeff King writes: > > > > > OK, I think that makes more sense. But note the p->num_objects thing I > > > mentioned. If I do: > > > > > >git pack-objects

Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

On 10/10/2017 8:56 AM, Junio C Hamano wrote: Jeff King writes: OK, I think that makes more sense. But note the p->num_objects thing I mentioned. If I do: git pack-objects .git/objects/pack/pack num_objects) return; Technically that also covers open_pack_index()

Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

On Tue, Oct 10, 2017 at 09:56:38PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > OK, I think that makes more sense. But note the p->num_objects thing I > > mentioned. If I do: > > > > git pack-objects .git/objects/pack/pack > > > then I have a pack with zero objects,

Re: What happened to "git status --color=(always|auto|never)"?

On Tue, Oct 10, 2017 at 09:51:38PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > :( I was worried that this might hit some third-party scripts. > > ... > > All that said, should we revisit the decision from 6be4595edb? The two > > code changes we could make are: > > > >

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

Hi, On Mon, Oct 09, 2017 at 11:20:51AM -0700, Stefan Beller wrote: > On Fri, Oct 6, 2017 at 3:32 PM, Heiko Voigt wrote: > > NOTE: The argument in this message is not correct, see description in > > cover letter. > > > > The setup of the repositories in this test is using

Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

Jeff King writes: > OK, I think that makes more sense. But note the p->num_objects thing I > mentioned. If I do: > > git pack-objects .git/objects/pack/pack > then I have a pack with zero objects, which I think we'd similarly want > to return early from. I.e., I think we need:

Re: What happened to "git status --color=(always|auto|never)"?

Jeff King writes: > :( I was worried that this might hit some third-party scripts. > ... > All that said, should we revisit the decision from 6be4595edb? The two > code changes we could make are: > > 1. Adding a "--color" option to "git status". Commit 0c88bf5050 > (provide

Re: "git rm" seems to do recursive removal even without "-r"

On Tue, 2017-10-10 at 04:36 -0400, Robert P. J. Day wrote: >   ah, now *that* is a compelling rationale that justifies the > underlying weirdness. but it still doesn't explain the different > behaviour between: > >   $ git rm -n 'Makefile*' >   $ git rm -n '*Makefile' I explained that behavior

Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

On Tue, Oct 10, 2017 at 08:16:27AM -0400, Derrick Stolee wrote: > > > + mad->init_len = 0; > > > + if (!match) { > > > + nth_packed_object_oid(, p, first); > > > + extend_abbrev_len(, mad); > > If we have zero objects in the pack, what would nth_packed_object_oid() > > be

Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

On 10/9/2017 9:49 AM, Jeff King wrote: On Sun, Oct 08, 2017 at 02:49:42PM -0400, Derrick Stolee wrote: @@ -505,6 +506,65 @@ static int extend_abbrev_len(const struct object_id *oid, void *cb_data) return 0; } +static void find_abbrev_len_for_pack(struct packed_git *p, +

Re: "git rm" seems to do recursive removal even without "-r"

On Sun, Oct 08, 2017 at 07:56:20AM -0400, Robert P. J. Day wrote: > but as i asked in my earlier post, if i wanted to remove *all* files > with names of "Makefile*", why can't i use: > > $ git rm 'Makefile*' > > just as i used: > > $ git rm '*.c' > > are those not both acceptable

My name is Sylvanus Eyadema , i have written you the letter about one a month ago and i don't hear from you therefore i repeated this letter once again to you, i in possession of the leading documents

Wir haben ein $ 6,480,000.00 Paket, um Ihnen zu liefern!

Wir haben ein Paket für Sie mit einem gewinnenden Scheck lohnt sich die Summe von sechs Millionen vierhundert und achtzehn tausend United States Dollars ($ 6.480.000,00USD) und auch ein Apple MacBook Pro und das neue Apple iPhone (7) 256GB Handy hinzugefügt zu Ihrem Paket, das Ihnen geliefert

Re: [RFC] column: show auto columns when pager is active

On 9 October 2017 at 23:45, Kevin Daudt wrote: > When columns are set to automatic for git tag and the output is > paginated by git, the output is a single column instead of multiple > columns. > > Standard behaviour in git is to honor auto values when the pager is > active, which

Re: What happened to "git status --color=(always|auto|never)"?

On Tue, Oct 10, 2017 at 12:42:43PM +0800, Nazri Ramliy wrote: > > commit 6be4595edb8e5b616c6e8b9fbc78b0f831fa2a87 > > Author: Jeff King > > Date: Tue Oct 3 09:46:06 2017 -0400 > > > > color: make "always" the same as "auto" in config > > > >

Re: [PATCH 1/3] write_entry: fix leak when retrying delayed filter

On Tue, Oct 10, 2017 at 05:25:43AM -0400, Jeff King wrote: > On Tue, Oct 10, 2017 at 11:23:19AM +0200, Simon Ruderich wrote: >> On Tue, Oct 10, 2017 at 09:00:09AM +0900, Junio C Hamano wrote: --- a/entry.c +++ b/entry.c @@ -283,6 +283,7 @@ static int write_entry(struct cache_entry

Re: [PATCH v2 1/3] for-each-ref: let upstream/push optionally report the remote name

Johannes Schindelin writes: > There are times when e.g. scripts want to know not only the name of the > upstream branch on the remote repository, but also the name of the > remote. > > This patch offers the new suffix :remotename for the upstream and for > the push

Re: [PATCH 1/3] write_entry: fix leak when retrying delayed filter

On Tue, Oct 10, 2017 at 11:23:19AM +0200, Simon Ruderich wrote: > On Tue, Oct 10, 2017 at 09:00:09AM +0900, Junio C Hamano wrote: > >> --- a/entry.c > >> +++ b/entry.c > >> @@ -283,6 +283,7 @@ static int write_entry(struct cache_entry *ce, > >>if (dco && dco->state !=

Re: [PATCH 1/3] write_entry: fix leak when retrying delayed filter

On Tue, Oct 10, 2017 at 09:00:09AM +0900, Junio C Hamano wrote: >> --- a/entry.c >> +++ b/entry.c >> @@ -283,6 +283,7 @@ static int write_entry(struct cache_entry *ce, >> if (dco && dco->state != CE_NO_DELAY) { >> /* Do not send the blob in case of

Re: "git rm" seems to do recursive removal even without "-r"

"Robert P. J. Day" writes: > underlying weirdness. but it still doesn't explain the different > behaviour between: > > $ git rm -n 'Makefile*' > $ git rm -n '*Makefile' > > in the linux kernel source tree, the first form matches only the > single, top-level Makefile,

Re: [PATCH] Documentation/git-config.txt: reword missleading sentence

Nathan PAYRE writes: > Thanks you for the this complete answer, > we take note of your comments. > > We would like to reword something else in the same line > and we don't know what is the best way to do that properly. > Should we do a [PATCH v2] or revert the last commit

Re: "git rm" seems to do recursive removal even without "-r"

On Mon, 9 Oct 2017, Jeff King wrote: > On Sun, Oct 08, 2017 at 04:42:27PM -0400, Theodore Ts'o wrote: > > > On Sun, Oct 08, 2017 at 03:44:14PM -0400, Robert P. J. Day wrote: > > > > > > > > find | xargs git rm > > > > > > > > myself. > > > > > > that's what i would have normally used until

Re: [PATCH] Documentation/git-config.txt: reword missleading sentence

Hi, Thanks you for the this complete answer, we take note of your comments. We would like to reword something else in the same line and we don't know what is the best way to do that properly. Should we do a [PATCH v2] or revert the last commit and commit a new one? 2017-10-05 12:13 GMT+02:00

Re: new contributors presentation

Hi, >First things first. I suspect that you are trying to contribute to >the Git project (GitHub is totally a different animal, even though >they benefit greatly from our presence, and we theirs). You are right excuse us for this. >And if you are dipping your toes to the Git project's