On 5/18/2019 12:17 AM, Mike Hommey wrote:
> On Sat, May 18, 2019 at 12:58:28PM +0900, Mike Hommey wrote:
>> On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
>>>
>>> All the above is without commit-graph, I presume? If so, then you
>>> should give it a try, as it might bring immediate
Jakub Narebski :
> As far as I understand it this would slow down receiving new commits
> tremendously. Currently great care is taken to not have to parse the
> commit object during fetch or push if it is not necessary (thanks to
> things such as reachability bitmaps, see e.g. [1]).
>
> With this
On Sun, May 19, 2019 at 2:37 PM Jeff King wrote:
> [...]
> - credential_form_url() parses a URL and decodes the specific
s/form/from/
> elements, but it's hard to convert it back into a regular URL. It
> treats "host:port" as a single unit, meaning it needs to be
> re-encoded speci
Ævar Arnfjörð Bjarmason writes:
> On Thu, May 16 2019, Eric S. Raymond wrote:
>> Derrick Stolee :
>>> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
The deeper problem is that I want something from Git that I cannot
have with 1-second granularity. That is: a unique timestamp on each
c
SZEDER Gábor writes:
> On Sat, May 18, 2019 at 01:17:06PM +0900, Mike Hommey wrote:
>> On Sat, May 18, 2019 at 12:58:28PM +0900, Mike Hommey wrote:
>>> On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
On Sat, May 18, 2019 at 09:54:12AM +0900, Mike Hommey wrote:
[...]
> There
Team,
Git for Windows v2.22.0-rc1 is available here:
https://github.com/git-for-windows/git/releases/tag/v2.22.0-rc1.windows.1
Thanks,
Johannes
On Sun, 19 May 2019, Junio C Hamano wrote:
> A release candidate Git v2.22.0-rc1 is now available for testing
> at the usual places. It is c
On Sun, May 19, 2019 at 2:55 AM Philip Oakley wrote:
> I'll add the answer to one on the stackoverflow Q&A's I'd looked at. I
> hadn't put the branch -a and -l options together.
Maybe update/add some examples in our man pages too.
--
Duy
On Sun, May 19, 2019 at 1:41 AM Ævar Arnfjörð Bjarmason
wrote:
> That's:
>
> git for-each-ref 'refs/remotes//'
> git branch -a -l '/'
>
> The latter will conflate with any local branches you happen to
> have prefixed with .
That problem should be gone if you use -r instead of -a.
--
Duy
If the user clones with a URL containing a password and has no
credential helper configured, we're stuck. We don't want to write the
password into .git/config because that risks accidentally disclosing it.
But if we don't record it somewhere, subsequent fetches will fail unless
the user is there to
If you clone a URL with a password, like:
git clone https://user:p...@example.com/repo.git
we'll write that literal URL, including the password into .git/config.
This can lead to accidentally disclosing it, since .git/config isn't
generally assumed to be a secret. In particular, it's very prone
When we anonymize URLs to show in messages, we strip out both the
username and password (if any). But there are also contexts where we
should strip out the password (to avoid leaking it) but retain the
username.
Let's generalize transport_anonymize_url() to support both cases. We'll
give it a new
On Fri, May 17, 2019 at 06:20:31PM -0400, Jeff King wrote:
> What if we did this:
>
> 1. Do not ever write the password part of a URL into config.
>
> 2. When we extract the user/pass out of a URL, put them into the
> credential struct, so that when we successfully authenticate, we
>
On Fri, May 17, 2019 at 11:58:47PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, May 17 2019, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> >> Far be it from me to care about AIX, but it seems like this is ripe for
> >> regressions, because we don't know which platforms were relying on "
There are two ways a 'struct repository' could be initialized before
using: via initialize_the_repository() and repo_init().
The first way always initializes 'index' field because that's how it is
before the introduction of 'struct repository'. Back then 'the_index' is
always available (even if no
Since commit 545dc345eb (progress: break too long progress bar lines,
2019-04-12) when splitting a too long progress line, sometimes it
looks as if a superfluous empty line were added between the title
line and the counters.
To make sure that the previously displayed progress line is completely
co
For an environment variable that is supposed to be set by users, the
GIT_TR2* env vars are just too unclear, inconsistent, and ugly.
Most of the established GIT_* environment variables don't use
abbreviations, and in case of the few that do (GIT_DIR,
GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvio
On 19/05/2019 04:07, Duy Nguyen wrote:
On Sun, May 19, 2019 at 2:55 AM Philip Oakley wrote:
I'll add the answer to one on the stackoverflow Q&A's I'd looked at. I
hadn't put the branch -a and -l options together.
Maybe update/add some examples in our man pages too.
deffo on an update! For th
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The first release candidate Git 2.
The descriptions of the GIT_TRACE2* environment variables link to the
technical docs for further details on the supported values. However,
a link like this only really works if the docs are viewed in a browser
and the full documentation is available. OTOH, in 'man git' there are
no links to conve
When using `git clone --recurse-submodules` there was previously no way to
pass a `--remote` switch to the implicit `git submodule update` command for
any use case where you want the submodules to be checked out on their
remote-tracking branch rather than with the SHA-1 recorded in the superproject
I was expected an env var like:
GIT_DESIRED_COMMIT_MESSAGE
to show up when .git/hooks/pre-commit is run
but as described here, there doesn't appear to be any args to the
script and the environment variable isn't there?
https://stackoverflow.com/questions/56205170/retrieving-desired-git-commit-m
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The first release candidate Git 2.
On 18.05.19 21:34, Philip Oakley wrote:
Hi Adam
Hi Philip
On 18/05/2019 15:07, Dr. Adam Nielsen wrote:
This "Otherwise" below could be the complement to the initial "If", or
could be part of a "matches" pair of example sentences. At least on my
initial reading I paired it via the 'matches'
Philip Oakley :
> > But I don't quite understand your claim that there's no format
> > breakage here, unless you're implying to me that timestamps are already
> > stored in the git file system as variable-length strings. Do they
> > really never get translated into time_t? Good news if so.
> Mayb
A release candidate Git v2.22.0-rc1 is now available for testing
at the usual places. It is comprised of 699 non-merge commits
since v2.21.0, contributed by 66 people, 16 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
Hi Eric,
On 19/05/2019 05:09, Eric S. Raymond wrote:
Philip Oakley :
But I don't quite understand your claim that there's no format
breakage here, unless you're implying to me that timestamps are already
stored in the git file system as variable-length strings. Do they
really never get transla
Am 18.05.19 um 16:13 schrieb Dr. Adam Nielsen:
> - - If the pattern ends with a slash, it is removed for the
> - purpose of the following description, but it would only find
> + - A slash `/` is used as a directory separator. A leading and trailing
> + slash have special meaning and are explain
27 matches
Mail list logo
