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
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.
[...]
> ---
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
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 '...'.
>
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
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
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.
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)
>
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
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
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
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.
>>
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
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,
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;
> +
> + /*
> + *
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
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
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*'
> >
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
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
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
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
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
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
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");
> + /*
> +
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
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))
> +
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 != ' ')
> +
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
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
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
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
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
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
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
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
> 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
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
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()
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,
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:
> >
> >
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
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:
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
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
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
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,
+
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
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
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
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
> >
> >
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
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
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 !=
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
"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,
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
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
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
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
61 matches
Mail list logo