On Tue, Dec 18, 2018 at 9:22 AM Jeff King wrote:
>
> On Sun, Dec 16, 2018 at 01:57:57PM -0800, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > Add an atom proving the path of the linked worktree where this ref is
> > checked out, if it is checked out in any linked worktrees,
On Wed, Dec 19, 2018 at 09:52:12PM -0500, Jeff King wrote:
> On Thu, Dec 20, 2018 at 12:17:53AM +, brian m. carlson wrote:
>
> > On Wed, Dec 19, 2018 at 10:27:35AM -0500, Jeff King wrote:
> > > I dunno. This is one of those dark corners of the code where we appear
> > > to do the wrong thing,
On Thu, Dec 20, 2018 at 12:17:53AM +, brian m. carlson wrote:
> On Wed, Dec 19, 2018 at 10:27:35AM -0500, Jeff King wrote:
> > I dunno. This is one of those dark corners of the code where we appear
> > to do the wrong thing, but nobody seems to have noticed or cared much,
> > and changing it r
On Wed, Dec 19, 2018 at 03:29:48PM -0800, Jonathan Nieder wrote:
> > I'm also not sure it really matters all that much either way. If you buy
> > my argument that this is just about placing the general era of the
> > commit in the mind of the reader, then "just before v2.11" or "just
> > after v2.
In some shells, such as bash and zsh, it's possible to use a command
substitution to provide the output of a command as a file argument to
another process, like so:
diff -u <(printf "a\nb\n") <(printf "a\nc\n")
However, this syntax does not produce useful results with git diff
--no-index.
On m
On Wed, Dec 19, 2018 at 10:38:41AM -0500, Jeff King wrote:
> Hmm. It looks like we never set repo_fmt.hash_algo to anything besides
> GIT_HASH_SHA1 anyway. I guess the existing field is really just there in
> preparation for us eventually respecting extensions.hashAlgorithm (or
> whatever it's call
On Wed, Dec 19, 2018 at 10:27:35AM -0500, Jeff King wrote:
> I dunno. This is one of those dark corners of the code where we appear
> to do the wrong thing, but nobody seems to have noticed or cared much,
> and changing it runs the risk of breaking some obscure cases. I'm not
> sure if we should bi
On Wed, Dec 19 2018, Jonathan Nieder wrote:
> Hi,
>
> Duy Nguyen wrote:
>> On Wed, Dec 19, 2018 at 6:04 PM Ævar Arnfjörð Bjarmason
>
>>> E.g. when composing
>>> https://public-inbox.org/git/878t0lfwrj@evledraar.gmail.com/ I
>>> remembered PERLLIB_EXTRA went back & forth between
>>> working/b
On 2018.12.17 16:33, Jeff King wrote:
> On Thu, Dec 13, 2018 at 02:18:26PM -0800, Josh Steadmon wrote:
>
> > On 2018.12.12 17:17, Masaya Suzuki wrote:
> > > On Wed, Dec 12, 2018 at 3:02 AM Jeff King wrote:
> > > > This ERR handling has been moved to a very low level. What happens if
> > > > we're
Jeff King wrote:
> On Wed, Dec 19, 2018 at 10:39:27AM -0800, Jonathan Nieder wrote:
>> Is there some rule about how long the hex string has to be for this to
>> work?
>
> In both cases, it has to be 7 characters.
Thanks.
[...]
>> The issue with this is that it is ambiguous about what the tag nam
On Wed, Dec 19, 2018 at 10:59:30PM +, Sitsofe Wheeler wrote:
> While using trying to use git to clone a remote repository git
> index-pack occasionally goes on to hang:
> [...]
> Looking at where it is stuck, git is doing read of a pipe:
>
> #0 0x7fd1b845034e in __libc_read (fd=fd@entry=
When communicating with a remote server or a subprocess, use expanded
numbers rather than abbreviated numbers in the object filter spec (e.g.
"limit:blob=1k" becomes "limit:blob=1024").
Update the protocol docs to note that clients should always perform this
expansion, to allow for more compatibil
NOTE: this patch is based on top of md/list-objects-filter-by-depth
Currently, git clients pass filter specs verbatim over the network and
to subprocesses. We support various numeric abbreviations for parameters
on these limits (via git_parse_ulong()), but other implementations may
not support the
On Wed, Dec 19, 2018 at 10:46:52PM +0100, Martin Ågren wrote:
> > 2. Arguably we should not even look at extensions.* unless we see a
> > version >= 1. But we do process them as we parse the config file.
> > This is mostly an oversight, I think. We have to handle them as we
> > se
Hi,
While using trying to use git to clone a remote repository git
index-pack occasionally goes on to hang:
export GIT_TRACE=1
git clone -n remotehost:diffusion/LIBEDIT/libedit
22:43:48.948378 git.c:418 trace: built-in: git clone -n
remotehost:diffusion/LIBEDIT/libedit
Cloning into
On Wed, Dec 19, 2018 at 10:39:27AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > - web interfaces like GitHub won't linkify this type of reference
> > (whereas they will for something that looks like a hex object id)
> >
> > - my terminal makes it easy to select hex strings, but
Hi,
Duy Nguyen wrote:
> On Wed, Dec 19, 2018 at 6:04 PM Ævar Arnfjörð Bjarmason
>> E.g. when composing
>> https://public-inbox.org/git/878t0lfwrj@evledraar.gmail.com/ I
>> remembered PERLLIB_EXTRA went back & forth between
>> working/breaking/working with your/my/your patch, so:
>>
>> git
On Tue, 18 Dec 2018 at 13:00, Johannes Schindelin
wrote:
> > Makes me wonder if `setup_git_directory_gently()` should BUG if it
> > receives NULL. That would require some reshuffling in setup.c, since
> > `setup_git_directory()` calls out to it with NULL... Just thinking out
> > loud. In any case,
On Wed, 19 Dec 2018 at 16:48, Jeff King wrote:
>
> On Tue, Dec 18, 2018 at 08:25:28AM +0100, Martin Ågren wrote:
>
> > +void clear_repository_format(struct repository_format *format)
> > +{
> > + string_list_clear(&format->unknown_extensions, 0);
> > + free(format->work_tree);
> > + fr
On Wed, 19 Dec 2018 at 16:38, Jeff King wrote:
>
> On Tue, Dec 18, 2018 at 08:25:27AM +0100, Martin Ågren wrote:
>
> > Check that `version` is non-negative before using `hash_algo`.
> Hmm. It looks like we never set repo_fmt.hash_algo to anything besides
> GIT_HASH_SHA1 anyway. I guess the existi
Hi,
William Hubbs wrote:
> this is my first patch for git, so please be gentle. ;-)
Thanks for contributing!
> I am in a situation where I need to use different authorship information
> for some repositories I commit to.
>
> Git already supports setting different authorship and committer
> info
On Wed, 19 Dec 2018 at 01:18, brian m. carlson
wrote:
> I think this change is fine, because we initialize the value in
> the_repository elsewhere, and if there's no repository, this should
> never have a value other than the default anyway.
Thanks, it feels good that this patch matches how you t
On Wed, 19 Dec 2018 at 16:27, Jeff King wrote:
>
> On Tue, Dec 18, 2018 at 08:25:26AM +0100, Martin Ågren wrote:
>
> > No-one looks at the return value, so we might as well drop it. It's
> > still available as `format->version`.
>
> Hmm. If we have to pick one, I'd say that just returning a sane e
A user complained that they had the following message in a git command:
fatal: invalid parent position 2147483647
In hex, this value is 0x7fff, corresponding to the GRAPH_MISSING_PARENT
constant. This constant was intended as a way to have the commit-graph store
commits with parents that are
From: Derrick Stolee
When writing a commit-graph, we write GRAPH_MISSING_PARENT if the
parent's object id does not appear in the list of commits to be
written into the commit-graph. This was done as the initial design
allowed commits to have missing parents, but the final version
requires the com
On Wed, Dec 19, 2018 at 2:19 PM William Hubbs wrote:
>
> The author.email, author.name, committer.email and committer.name
> settings are analogous to the GIT_AUTHOR_* and GIT_COMMITTER_*
> environment variables, but for the git config system. This allows them
> to be set separatel
On Wed, Dec 19 2018, Andrew Shearer wrote:
> Hello
>
> I am using a "git svn clone" command to extract our project history from svn
> into git.
> About 30m into the process it fails with:
>
> r50739 = 2a1491de1353b1e3cce50d8f9d383407218a44f1 (refs/remotes/git-svn)
> fatal: Cannot open '.git/Git
On Wed, Dec 19 2018, Jeff King wrote:
> On Wed, Dec 19, 2018 at 03:02:14PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> On Mon, Dec 17 2018, Jonathan Nieder wrote:
>>
>> > v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
>>
>> Minor nit not just on this patch, but your patches
The author.email, author.name, committer.email and committer.name
settings are analogous to the GIT_AUTHOR_* and GIT_COMMITTER_*
environment variables, but for the git config system. This allows them
to be set separately for each repository.
Signed-off-by: William Hubbs
---
Docum
Hi all,
this is my first patch for git, so please be gentle. ;-)
I am in a situation where I need to use different authorship information
for some repositories I commit to.
Git already supports setting different authorship and committer
information with environment variables, but this setting is
Hi,
Jeff King wrote:
> - web interfaces like GitHub won't linkify this type of reference
> (whereas they will for something that looks like a hex object id)
>
> - my terminal makes it easy to select hex strings, but doesn't
> understand this git-describe output :)
>
> These tools _cou
On Wed, Dec 19, 2018 at 03:02:14PM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Dec 17 2018, Jonathan Nieder wrote:
>
> > v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
>
> Minor nit not just on this patch, but your patches in general: I think
> you're the only one usin
On Tuesday, December 18, 2018 2:56:43 PM MST Johannes Schindelin wrote:
> Sounds like you need https://github.com/git-for-windows/git/pull/1757
> (we do not currently have a responsive maintainer for Git GUI,
> unfortunately, otherwise this patch would have made it into an official
> Git version al
On Wed, Dec 19, 2018 at 03:02:14PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Dec 17 2018, Jonathan Nieder wrote:
>
> > v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
>
> Minor nit not just on this patch, but your patches in general: I think
> you're the only one us
On Wed, Dec 19, 2018 at 6:04 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Dec 17 2018, Jonathan Nieder wrote:
>
> > v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
>
> Minor nit not just on this patch, but your patches in general: I think
> you're the only one using this t
Looks like that was a flake. Everything passes now.
https://travis-ci.org/ijt/git/builds/469843833
On Wed, Dec 19, 2018 at 12:07 AM Issac Trotts wrote:
>
> Travis showed one failure. I'm not sure if it's a flake.
> https://travis-ci.org/ijt/git/builds/469843833. Rerunning it.
>
> On Tue, Dec 18,
Hi everyone,
The 46th edition of Git Rev News is now published:
https://git.github.io/rev_news/2018/12/19/edition-46/
Thanks a lot to the contributors: Johannes Schindelin, Kaartic
Sivaraam and Matt Singletary!
Enjoy,
Christian, Jakub, Markus and Gabriel.
On Tue, Dec 18, 2018 at 12:54:02PM -0800, Erin Dahlgren wrote:
> > Might it make sense to make GIT_DIR_HIT_MOUNT_POINT more like
> > GIT_DIR_HIT_CEILING currently is, rather than the other way around?
> > I.e., something like:
> >
> > case GIT_DIR_HIT_CEILING:
> > if (!nongit_ok)
> >
On Tue, Dec 18, 2018 at 01:05:51PM -0800, Josh Steadmon wrote:
> On 2018.12.18 12:35, Jeff King wrote:
> > On Thu, Dec 13, 2018 at 11:43:55AM -0800, Josh Steadmon wrote:
> >
> > > Add a new fuzz test for the commit graph and fix a buffer read-overflow
> > > that it discovered. Additionally, fix t
On Tue, Dec 18, 2018 at 08:25:28AM +0100, Martin Ågren wrote:
> After we set up a `struct repository_format`, it owns various pieces of
> allocated memory. We then either use those members, because we decide we
> want to use the "candidate" repository format, or we discard the
> candidate / scratc
On Tue, Dec 18, 2018 at 08:25:27AM +0100, Martin Ågren wrote:
> If `read_repository_format()` encounters an error, `format->version`
> will be -1 and all other fields of `format` will be undefined. However,
> in `setup_git_directory_gently()`, we use `repo_fmt.hash_algo`
> regardless of the value
On Tue, Dec 18, 2018 at 08:25:26AM +0100, Martin Ågren wrote:
> No-one looks at the return value, so we might as well drop it. It's
> still available as `format->version`.
>
> In v1 of what became commit 2cc7c2c737 ("setup: refactor repo format
> reading and verification", 2016-03-11), this funct
Hi,
The new built-in rebase feature is much faster than before. Thanks for that :)
One problem we found in it is that doesn't seem to execute post-checkout hook.
Please fix it.
Thanks,
- Orgad
On Mon, Dec 17 2018, Jonathan Nieder wrote:
> v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
Minor nit not just on this patch, but your patches in general: I think
you're the only one using this type of template instead of the `%h
("%s", %ad)` format documented in Submitt
On Wed, Dec 19 2018, Carlo Arenas wrote:
> On Tue, Dec 18, 2018 at 7:29 PM John Passaro wrote:
>>
>> I recently submitted my first patch using OSX and found the experience
>> frustrating, for reasons that have come up on the list before,
>> concerning git-send-email and perl dependencies that y
On Wed, Dec 19 2018, John Passaro wrote:
> I recently submitted my first patch using OSX and found the experience
> frustrating, for reasons that have come up on the list before,
> concerning git-send-email and perl dependencies that you need to be
> root to update.
>
> Last seen here:
> https:/
From: Sun Chao
When calling `git pack-redundant --all`, if there are too many local
packs and too many redundant objects within them, the too deep iteration
of `get_permutations` will exhaust all the resources, and the process of
`git pack-redundant` will be killed.
The following script could cr
From: Sun Chao
Remove unused functions to find `min` packs, such as `get_permutations`,
`pll_free`, etc.
Signed-off-by: Sun Chao
Signed-off-by: Jiang Xin
---
builtin/pack-redundant.c | 72
1 file changed, 72 deletions(-)
diff --git a/builtin/pack-redu
From: Jiang Xin
Add test cases for git pack-redundant to validate new algorithm for git
pack-redundant.
Signed-off-by: Jiang Xin
---
t/t5322-pack-redundant.sh | 69 +++
1 file changed, 69 insertions(+)
create mode 100755 t/t5322-pack-redundant.sh
diff --gi
Sun Chao is my former colleague at Huawei. He finds a bug of git-pack-redundant.
When I was in Huawei, I develop a program to manage fork tree of repositories,
using alternate repo for forks to save disk spaces.
Sun Chao finds if there are too many packs and many of them overlap each
other, runn
On Wed, Dec 19, 2018 at 12:15 AM Robin H. Johnson wrote:
>
> I think this is encapsulated in the v2/promisor work, but wanted to
> check how close that was to fruition, and that it would indeed be
> possible.
>
> This would enable replacement of any workflow that presently uses rsync
> to update.
From: Issac Trotts
Make it possible to write for example
git log --format="%H,%S"
where the %S at the end is a new placeholder that prints out the ref
(tag/branch) for each commit.
Using %d might seem like an alternative but it only shows the ref for the last
commit in the branch.
Sig
Travis showed one failure. I'm not sure if it's a flake.
https://travis-ci.org/ijt/git/builds/469843833. Rerunning it.
On Tue, Dec 18, 2018 at 7:47 PM Issac Trotts wrote:
>
> On Tue, Dec 18, 2018 at 9:14 AM Issac Trotts wrote:
> >
> > Hi Peff, thanks for the feedback. I tried a variant of the co
53 matches
Mail list logo
