On Mon, Jun 25, 2018 at 04:26:00PM -0500, Taylor Blau wrote:
> For instance, a line containing the following (taken from README.md:27):
>
> (`man gitcvs-migration` or `git help cvs-migration` if git is
>
> Is printed as follows:
>
> $ git grep -no -e git -- README.md | grep ":27"
>
On Tue, Jun 26, 2018 at 12:51:45PM -0400, Robert P. J. Day wrote:
> > I agree it's weird. I think it's trying to mean "behaves as if it
> > was set to", but with the additional notion that the command-line
> > argument would take precedence over the environment (which is our
> > usual rule). But
On Thu, Jun 28, 2018 at 12:36:06PM -0400, Todd Zullinger wrote:
> >> It might be enough if the default values are relatively sane
> >> and consistent. That would be a slight improvement over the
> >> current situation still.
> >
> > Yeah. Taking a step back from the implementation questions, I
On Thu, Jun 28, 2018 at 06:23:56PM +0200, Johannes Schindelin wrote:
> On Thu, 28 Jun 2018, Jeff King wrote:
>
> > On Wed, Jun 27, 2018 at 09:35:23PM +0200, Johannes Schindelin via
> > GitGitGadget wrote:
> >
> > > To prevent erroneous commits from be
On Thu, Jun 28, 2018 at 10:27:32AM -0700, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I.e.:
> >>
> >> FOO='with spaces'
> >> BAR=$FOO sh -c 'echo $BAR'
> >>
> >> works just fine.
> >
> > $ x="two spaces"
> >
> > $ echo $x
> > two spaces
> >
> > Maybe we should
On Thu, Jun 28, 2018 at 05:56:18PM +0100, Ramsay Jones wrote:
> > Yeah, this solution seems sensible. Given that we would never report any
> > error for that blob, there is no point in even looking at it. I wonder
> > if we ought to do the same for other types, too. Is there any point in
> >
On Thu, Jun 28, 2018 at 09:39:39AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, this solution seems sensible. Given that we would never report any
> > error for that blob, there is no point in even looking at it. I wonder
> > if we ought to do the s
On Thu, Jun 28, 2018 at 07:21:18PM +0200, Lars Schneider wrote:
> How about this:
>
> 1) We allow users to set the encoding "auto". Example:
>
> *.txt working-tree-encoding=auto
>
> 2) We define a new variable `core.autoencoding`. By default the value is
> UTF-8 (== no re-encoding) but
On Tue, Jun 26, 2018 at 07:15:45PM -0700, Elijah Newren wrote:
> Crazy idea: maybe we could defang it a little more thoroughly with
> something like the following (apologies in advance if gmail whitespace
> damages this):
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index
On Tue, Jun 26, 2018 at 05:13:05PM -0400, Eric Sunshine wrote:
> On Tue, Jun 26, 2018 at 5:01 PM Jeff King wrote:
> > On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> > > Some of these dangers can be de-thoothed during the linting phase by
> > >
On Thu, Jun 28, 2018 at 02:44:47AM +, brian m. carlson wrote:
> On Wed, Jun 27, 2018 at 07:54:52AM +, Steve Groeger wrote:
> > We have common code that is supposed to be usable across different
> > platforms and hence different file encodings. With the full support of the
> >
On Wed, Jun 27, 2018 at 04:58:43PM -0400, Todd Zullinger wrote:
> I tend to think that the default should be to build
> documentation that is accurate for that build, but since
> it's something I'll set once for my package builds it's not
> a big deal either way to me.
To be clear, I think so,
On Wed, Jun 27, 2018 at 12:44:43PM -0400, Todd Zullinger wrote:
> I wrote:
> > Jeff King wrote:
> >> (Related, there's a build target in the local Makefile for using
> >> asciidoctor; does it need updated, too?)
> >
> > I didn't test asciido
On Wed, Jun 27, 2018 at 11:03:52AM -0400, Todd Zullinger wrote:
> So what you're saying is that if I had procrastinated a
> little, you may have written such a patch for me? :)
Yes, but that's a dangerous game of chicken. :)
> > 1. The pre-built documentation that Junio builds for
> >
On Wed, Jun 27, 2018 at 09:35:23PM +0200, Johannes Schindelin via GitGitGadget
wrote:
> To prevent erroneous commits from being reported (e.g. when unpacking
> Git's source code from a .tar.gz file into a subdirectory of a different
> Git project, as e.g. git_osx_installer does), we
On Wed, Jun 27, 2018 at 07:39:53PM +0100, Ramsay Jones wrote:
> Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02),
> fsck will issue an error message for '.gitmodules' content that cannot
> be parsed correctly. This is the case, even when the corresponding blob
> object has
On Wed, Jun 27, 2018 at 12:56:37AM -0400, Todd Zullinger wrote:
> Replace `$(prefix)/etc/gitconfig` and `$(prefix)/etc/gitattributes` in
> generated documentation with the paths chosen when building. Readers of
> the documentation should not need to know how `$(prefix)` was defined.
Yes, I was
On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> > I'm not sure if there's a good solution, though. Even if you retained
> > the subshells and instead did a chain-lint inside each subshell, like
> > this:
> >
> > (exit 117) &&
> > one &&
> > (
> > (exit 117) &&
> >
On Tue, Jun 26, 2018 at 04:17:08PM -0400, Jeff King wrote:
> I'm not sure if there's a good solution, though. Even if you retained
> the subshells and instead did a chain-lint inside each subshell, like
> this:
So obviously that means "I don't think there's a good solution with
On Tue, Jun 26, 2018 at 03:52:54PM -0400, Eric Sunshine wrote:
> The existing --chain-lint already suffers the same shortcoming. Older
> (or even new poorly-written) tests, even without subshells, can fall
> victim already:
>
> (exit $sentinel) &&
> mkdir -p a/b/c &&
> cd a/b/c
>
On Tue, Jun 26, 2018 at 02:27:39PM -0400, Jeff King wrote:
> So yeah, we would not want to allow EXT::"rm -rf /" to slip past the
> known-unsafe match. Any normalization should happen before then
> (probably right in transport_helper_init).
>
> Come to think o
On Tue, Jun 26, 2018 at 10:09:58AM -0700, Junio C Hamano wrote:
> > It may also interact in a funny way with our allowed-protocol code, if
> > "SSH" gets a pass as "ssh" under the default config, but actually runs
> > the otherwise-disallowed git-remote-SSH (though one would _hope_ if you
> >
On Tue, Jun 26, 2018 at 06:18:26AM -0400, Robert P. J. Day wrote:
>
> ENVIRONMENT
> GIT_CONFIG
> Take the configuration from the given file instead of
> .git/config. Using the "--global" option forces this to
> ~/.gitconfig. Using the "--system" option forces this to
>
On Mon, Jun 25, 2018 at 11:19:51AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > We seem to match url schemes case-sensitively:
> >
> > $ git clone SSH://example.com/repo.git
> > Cloning into 'repo'...
> > fatal: Unable to find remote help
On Fri, Jun 22, 2018 at 10:49:26AM -0500, Taylor Blau wrote:
> Attached is my third--anticipate the final--re-roll of my series to
> teach 'git grep --column'.
You know when you say that it jinxes it, right? :)
> Since the last time, only a couple of things have changed at Peff's
> suggestions
On Sat, Jun 23, 2018 at 05:45:19PM -0400, Noam Postavsky wrote:
> On 20 May 2016 at 18:12, Noam Postavsky
> wrote:
My, this is a blast from the past. :)
> Subject: [PATCH v1] log: Fix coloring of certain octupus merge shapes
>
> For octopus merges where the first parent edge immediately
On Fri, Jun 22, 2018 at 07:42:38PM -0700, Anthony Sottile wrote:
> A bit of an amusing edge case.
>
> I'm not exactly sure the correct approach to fix this but here's my
> reproduction, triage, and a few potential options I see.
>
> Note that after the username prompt, I pressed ^D
>
>
We seem to match url schemes case-sensitively:
$ git clone SSH://example.com/repo.git
Cloning into 'repo'...
fatal: Unable to find remote helper for 'SSH'
whereas rfc3986 is clear that the scheme portion is case-insensitive.
We probably ought to match at least our internal ones with
On Fri, Jun 22, 2018 at 06:34:28PM -0400, Eric Sunshine wrote:
> I wonder if it would be better and cleaner to limit the visibility of
> this change to cmd_branch(), rather than spreading it across a global
> variable, a callback function, and cmd_branch(). Perhaps, like this:
I'd prefer that,
On Fri, Jun 22, 2018 at 11:45:09PM +0200, Johannes Schindelin wrote:
> > This might be a candidate for another "weather balloon" patch to see if
> > anybody complains, though. The last time time we dealt with this in a
> > major way was over 7 years ago in 28bd70d811 (unbreak and eliminate
> >
originally because "--create-reflog" was
squatting on the "-l" option. Now that we've deprecated that
use for long enough, we can make the switch.
Signed-off-by: Jeff King
---
This one is mostly a squash of the remove/reincarnate steps from the
previous iteration. I also noticed that
te-reflog"
- when we are in some _other_ mode, like deletion. There
the "-l" is a noop for now, but it will eventually
conflict with any other mode request, and the user
should be told that this is changing.
Signed-off-by: Jeff King
---
This one has the interesting cha
nce that
would leave the variable unset after our test finishes,
confusing downstream tests (the helper is not not smart
enough to restore the previous value, and just always runs
test_unconfig).
Signed-off-by: Jeff King
---
Same as before.
t/t3200-branch.sh | 2 +-
1 file changed, 1 inse
actually remove "-l"
entirely from most of these callers. That's because these
days core.logallrefupdates defaults to true in a non-bare
repository.
I've left them in place, though, since they serve to
document the expectation of the test, even if they are
technically noops.
Signe
This series replaces the contents of jk/branch-l-0-deprecation,
jk/branch-l-1-removal, and jk/branch-l-2-reincarnation.
It implements the idea discussed in the subthread in:
https://public-inbox.org/git/xmqqzi0hety4@gitster-ct.c.googlers.com/
Namely that "branch -l" would warn about
On Thu, Jun 21, 2018 at 04:45:49PM -0500, Taylor Blau wrote:
> > but not this:
> >
> > $ ./git grep --column -v --not -e scalable --and --not -e fast --
> > README.md
> > README.md:13:Git - fast, scalable, distributed revision control system
> > README.md:16:Git is a fast, scalable,
On Thu, Jun 21, 2018 at 08:09:43PM +0200, Pavel Cahyna wrote:
> > > + int len = mbstowcs(wcstring, outbuf->buf, outbuf->len);
> >
> > I don't think mbstowcs() is always going to do the right thing there.
> > We're looking at a string that was sent from the remote server. What
> > encoding is it
On Thu, Jun 21, 2018 at 12:04:11PM -0400, Jack Adrian Zappa wrote:
> Hi, I was trying to clone a repo into a non-existent directory. but it
> gave me a failure:
>
> $ git clone https://github.com/jelera/vim-javascript-syntax.git
> ~/.vim/bundle/vim-javascript-syntax
> fatal: destination path
>
On Thu, Jun 21, 2018 at 02:10:30PM +0200, Sebastian Kisela wrote:
> From: Sebastian Kisela
>
> Fix volnurability against MITM attacks on client side
> by replacing non printable and non white space characters
> by "?".
>
> Fixes: CVE-2018-121
I'm not sure if this is a productive direction
On Thu, Jun 21, 2018 at 07:53:02AM -0400, Jeff King wrote:
> > @@ -1429,7 +1447,7 @@ static void show_line(struct grep_opt *opt, char
> > *bol, char *eol,
> > */
> > if (opt->columnnum && cno) {
> > char buf[32];
> > -
On Wed, Jun 20, 2018 at 03:05:30PM -0500, Taylor Blau wrote:
> Hi,
>
> Here is a re-roll of my series to add --column to 'git-grep(1)'. Since
> last time, not much has changed other than the following:
>
> - Fix a typo where 'col', 'icol' were spelled as 'match', 'imatch'
> [1].
>
> -
On Thu, Jun 21, 2018 at 09:03:05AM +0200, Johannes Schindelin wrote:
> > > And at that point, maybe
> > >
> > > char *some_var = xstrdup("default");
> > > git_config_string(_var, ...);
> > >
> > > that takes "char **" and frees the current storage before assigning to
> > > it may be simpler
On Tue, Jun 19, 2018 at 10:40:16PM +0200, Torsten Bögershausen wrote:
>
>
> On 06/19/2018 08:22 PM, Eric Sunshine wrote:
> > On Tue, Jun 19, 2018 at 2:06 PM Junio C Hamano wrote:
> > > Torsten Bögershausen writes:
> > > > t5562 fails here under MacOS:
> > > > "gzip -k" is not portable.
> >
On Tue, Jun 19, 2018 at 07:00:48PM +, Dyer, Edwin wrote:
> Just curious if there was any additional comment on this potential
> OOB? I may have missed it and if so, apologies for the ask.
The fix is in master, and should be part of the upcoming v2.18. See
commit 9d2e330b17 (ewah_read_mmap:
On Tue, Jun 19, 2018 at 08:50:16PM +0200, René Scharfe wrote:
> Negation causes the whole non-matching line to match, with --column
> reporting 1 or nothing in such a case, right? Or I think doing the
> same when the operator is applied a second time is explainable.
Yes to your first question.
On Tue, Jun 19, 2018 at 10:58:30AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Although there are interesting cases around inversion. For example:
> >
> > git grep --not \( --not -e a --and --not -e b \)
> >
> > is equivalent to:
> >
>
On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
> > The key thing about this iteration is that it doesn't regress
> > performance, because we always short-circuit where we used to. The other
> > obvious route is to stop short-circuiting only when "--column" is in
> > effect, which
On Tue, Jun 19, 2018 at 02:36:50PM +0200, Christian Halstrick wrote:
> What is not clear to me is how we can make use of the servers initial
> response in order control which credential helper to call and how to
> transport the credentials.
I don't think we'd ever decide _which_ credential
On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
> Attached is a ``fresh start'' of my series to teach 'git grep --column'.
> Since the last time I sent this, much has changed, notably the semantics
> for deciding which column is the first when given (1) extended
> expressions and (2)
On Mon, Jun 18, 2018 at 06:43:14PM -0500, Taylor Blau wrote:
> static void show_line(struct grep_opt *opt, char *bol, char *eol,
> - const char *name, unsigned lno, char sign)
> + const char *name, unsigned lno, unsigned cno, char sign)
Here "cno" is
On Mon, Jun 18, 2018 at 08:53:27AM -0700, Junio C Hamano wrote:
> > Yeah, that will work for some cases. A few places it might not:
> >
> > - some people may want to provide this only in response to a 401
> >
> > - some tokens may need to be refreshed, which would require interacting
> >
On Sun, Jun 17, 2018 at 11:55:33PM +0530, Kaartic Sivaraam wrote:
> On Sun, 2018-06-17 at 14:00 -0400, Eric Sunshine wrote:
> > Whether or not to talk about alternate solutions in the commit message
> > is a judgment call. Same for deciding what belongs in the commit
> > message proper and what
On Sun, Jun 17, 2018 at 01:37:24PM +0200, Johannes Schindelin wrote:
> > If it's just a custom Authorization header, we should be able to support
> > it with existing curl versions without _too_ much effort.
>
> Indeed. Because it is already implemented:
>
> git -c
On Sat, Jun 16, 2018 at 04:35:13PM +0200, SZEDER Gábor wrote:
> > + head -c 512 <$bitmap >$bitmap.tmp &&
> > + mv $bitmap.tmp $bitmap &&
>
> This line turns out to be problematic on OSX and ultimately causes the
> test to fail.
>
> When OSX's 'mv's destination is read-only, it asks whether
On Fri, Jun 15, 2018 at 02:23:44PM -0400, Derrick Stolee wrote:
> If we are considering changing the reachability bitmap, then I'm very
> intrigued. I think the number one thing to consider is to use the
> multi-pack-index as a reference point (with a stable object order) so the
> objects can be
On Fri, Jun 15, 2018 at 12:48:52PM -0700, Junio C Hamano wrote:
> Derrick Stolee writes:
>
> >> ewah_clear() can become file-scope static, and
> >> rlwit_discharge_empty() can be eliminated. I do not know if either
> >> is worth doing, though.
> >
> > With Peff's patches, this is true. When I
On Fri, Jun 15, 2018 at 11:33:14AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > One thing that gave me pause on ripping out more code is that I have
> > some bitmap-related patches on my send-to-upstream list, and I wasn't
> > sure if they used any of this cod
On Fri, Jun 15, 2018 at 10:15:50AM -0400, Derrick Stolee wrote:
> > Hmm, if you are in the mood to drop ewah dead code, how about:
> >
> >ewah/bitmap.o - bitmap_clear
> >ewah/bitmap.o - bitmap_each_bit
> >ewah/ewah_bitmap.o - ewah_and
> >ewah/ewah_bitmap.o -
On Fri, Jun 15, 2018 at 09:41:46AM -0700, Junio C Hamano wrote:
> Derrick Stolee writes:
>
> > On 6/14/2018 11:44 PM, Jeff King wrote:
> >> The return value of ewah_read_mmap() is now an ssize_t,
> >> since we could (in theory) process up to 32GB of data
On Fri, Jun 15, 2018 at 10:05:42AM -0700, Junio C Hamano wrote:
> > - memcpy(self->buffer, ptr, self->buffer_size * sizeof(eword_t));
> > - ptr += self->buffer_size * sizeof(eword_t);
>
>
> > + data_len = st_mult(self->buffer_size, sizeof(eword_t));
>
> This is a faithful conversion from
On Fri, Jun 15, 2018 at 07:10:28PM +0200, SZEDER Gábor wrote:
> > I said "yuck" because the original does not work if there happen to
> > be more than (or for that matter, less than) one '.bitmap' file
> > there. But at least as long as there is one, it should work ;-)
>
> Well, the test starts
On Fri, Jun 15, 2018 at 01:13:21AM -0400, Jeff King wrote:
> > The trouble is that GIT_SSH_VARIANT=simple is too... simple. You
> > would like a variant that passes in [-p port] [-4] [-6] as well. We
> > didn't implement that because we didn't have the attention of any
>
On Fri, Jun 15, 2018 at 02:30:43AM -0400, Eric Sunshine wrote:
> On Fri, Jun 15, 2018 at 12:20 AM Jeff King wrote:
> > We have OLD_ICONV, too, which should probably do nothing if NO_ICONV is
> > set. I think that works OK. We end up setting -DOLD_ICONV on the command
> >
On Thu, Jun 14, 2018 at 11:27:03AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Another alternative is to simply accept that these tests are racy, and
> >> that the resulting test failures are rare enough that it isn't worth
> >>
On Thu, Jun 14, 2018 at 09:20:33PM -0700, Jonathan Nieder wrote:
> What we've switched to is a versioned interface. By setting
> GIT_SSH_VARIANT=simple, you are asking Git to promise to pass exactly
> options. If Git has a new option it wants to pass (like the "-o
> SendEnv" thing) but can
On Thu, Jun 14, 2018 at 10:25:03PM -0400, Eric Sunshine wrote:
> The Makefile tweak NO_ICONV is meant to allow Git to be built without
> iconv in case iconv is not installed or is otherwise dysfunctional.
> However, NO_ICONV's disabling of iconv is incomplete and can incorrectly
> allow "-liconv"
On Thu, Jun 14, 2018 at 11:28:50PM -0400, Jeff King wrote:
> Yep. We also fail to check if we even have enough bytes to read the
> buffer_size in the first place.
>
> Here are some patches. The first one fixes the problem you found. The
> second one drops some dead code tha
We don't call this function, and never have. The on-disk
bitmap format uses network-byte-order integers, meaning that
we cannot use the native-byte-order format written here.
Let's drop it in the name of simplicity.
Signed-off-by: Jeff King
---
ewah/ewah_io.c | 26
in the ewah data size,
meaning it may be possible to convince the code to allocate
a too-small buffer and read() into it.
Signed-off-by: Jeff King
---
ewah/ewah_io.c | 55 --
ewah/ewok.h| 1 -
2 files changed, 56 deletions(-)
diff --git a/ewah
our computations
right
The included test is far from comprehensive, as it just
picks a static point at which to truncate the generated
bitmap. But in practice this will hit in the middle of an
ewah and make sure we're at least exercising this code.
Reported-by: Luat Nguyen
Signed-off-by: Jeff
On Fri, Jun 15, 2018 at 06:59:43AM +0800, Luat Nguyen wrote:
> Recently, I’ve found a security issue related to out-of-bound read at
> function named `ewah_read_mmap`
Thanks, this is definitely a bug worth addressing. But note...
> Assume that, an attacker can put malicious `./git/index` into
On Thu, Jun 14, 2018 at 04:46:10PM -0400, Randall S. Becker wrote:
> > I suspect (2) would fit in with the existing code better, as the special
> > case
> > would mostly be limited to the manner in which we feed the credential to
> > curl. And you could probably just set a config option for
On Thu, Jun 14, 2018 at 11:55:22AM -0700, Jonathan Nieder wrote:
> > No, my wrapper _isn't_ simple. It passes most options to openssh, but
> > just doesn't understand the "-G" probing. So if the default was
> > openssh-like instead of "simple", then that would work fine without me
> > setting
On Tue, Jun 12, 2018 at 09:29:13AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > To be honest, I could easily see an argument that I _should_ be setting
> > GIT_SSH_VARIANT to explain what my wrapper is expecting, even though it
> > happened to work bef
On Thu, Jun 14, 2018 at 02:31:03PM +0200, SZEDER Gábor wrote:
> 't5561-http-backend.sh' is prone to occasional failures; luckily it's
> not 'git-http-backend's fault, but the test script is a bit racy. I
> won't go into the details here, patch 4/4's commit message discusses
> it at length. 4/4
On Thu, Jun 14, 2018 at 02:31:07PM +0200, SZEDER Gábor wrote:
> The last test of 't5561-http-backend.sh', 'server request log matches
> test results' may fail occasionally, because the order of entries in
> Apache's access log doesn't match the order of requests sent in the
> previous tests,
On Thu, Jun 14, 2018 at 10:13:42AM +, brian m. carlson wrote:
> > I know that other git server environments like github support that on
> > client side by allowing tokens to be used as usernames in a BASIC
> > authentication flow. We could do the same but I am asking whether
> > there is also
On Wed, Jun 13, 2018 at 05:05:09PM -0400, Jeff King wrote:
> > In order to be sure fetching funky tags will never break, let's
> > explicitly test all relevant cases with 4 tag objects pointing to 1) a
> > blob, 2) a tree, 3) a commit, and 4) another tag objects. The referenc
On Tue, Jun 12, 2018 at 06:54:17PM +, Kirill Smelkov wrote:
> > If an extra connection isn't a problem, you might be better off with
> > "git ls-remote", and then picking through the results for refs of
> > interest, and then "git fetch-pack" to actually get the pack. That's how
> > git-fetch
On Wed, Jun 13, 2018 at 06:43:04PM +, Kirill Smelkov wrote:
> From: Kirill Smelkov
> Date: Wed, 13 Jun 2018 12:28:21 +0300
> Subject: [PATCH v2] fetch-pack: test explicitly that --all can fetch tag
> references pointing to non-commits
>
> Fetch-pack --all became broken with respect to
On Mon, Jun 11, 2018 at 06:06:11PM +0200, ch wrote:
> After the rebase the 'stuff' branch only has a single commit even though I'd
> expect there to be two according to the instructions that were passed to
> git-rebase. It works as expected if there's either no merge-conflict at the
> reword or
On Sat, Jun 09, 2018 at 03:44:30PM +0200, Martin Ågren wrote:
> On 9 June 2018 at 11:21, Jeff King wrote:
> > On Sat, Jun 09, 2018 at 10:50:36AM +0200, Martin Ågren wrote:
> >
> >> On 9 June 2018 at 10:32, Jeff King wrote:
> >> > Except it _does_ do
On Mon, Jun 11, 2018 at 09:43:02AM +, Kirill Smelkov wrote:
> > Looking deeper, we do not need these trees and blobs at all. The problem
> > is really just a tag that peels to an object that is not otherwise a ref
> > tip, regardless of its type.
>
> Thanks for feedback and for coming up
On Tue, Jun 12, 2018 at 10:18:31AM +0200, Crni Gorac wrote:
> I'm working on a large closed-source project. For one of clients, I
> had to create a library that consists of some directories from
> original project, and even within these directories, not all files are
> used for the library. On
On Mon, Jun 11, 2018 at 03:08:42PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Mon, Jun 04, 2018 at 10:57:30PM +0900, Junio C Hamano wrote:
> >
> >> * jk/index-pack-maint (2018-06-01) 2 commits
> >> (merged to 'next' on 2018-06-04 at c5
On Mon, Jun 11, 2018 at 11:50:46AM -0700, Jonathan Tan wrote:
> Here's an paragraph to be added to the end of the commit message. I can
> send a reroll with the exact same code but with the updated commit
> message if Junio requests it.
>
> [additional paragraph begin]
>
> This patch raises two
On Mon, Jun 11, 2018 at 10:35:40AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If you don't even have symbolic-ref handy, you can do:
> >
> > echo "ref: refs/heads/new-branch" >.git/HEAD
> >
> > That's not generally recommended, si
On Mon, Jun 11, 2018 at 05:18:13AM -0400, Jeff King wrote:
> > >> +sleep 1; # is interrupted by SIGCHLD
> > >> +if (!$exited) {
> > >> +close($out);
> > >> +die "Command did not exit after reading whole body";
> >
On Tue, Jun 05, 2018 at 01:18:08AM +0300, Max Kirillov wrote:
> > On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote:
> > Since this is slightly less efficient, and because it only matters if
> > the web server does not already close the pipe, should this have a
> > run-time
On Sun, Jun 10, 2018 at 06:07:27PM +0300, Max Kirillov wrote:
> On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote:
> > On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote:
> >> + env \
> >> + CONTENT_TYPE=applicatio
for more discussion).
As a result, there's no need to create a commit in our
tests. Let's drop it in the name of simplicity. And since
that was the only thing referencing $tree, we can pull our
tree creation out of a command substitution.
Signed-off-by: Jeff King
---
t/t7415-submodule-names.sh | 11
tead, let's just use lookup_unknown_object() to get
the real "struct object", and pass that.
Signed-off-by: Jeff King
---
fsck.c | 3 ++-
t/t7415-submodule-names.sh | 18 ++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/fsck.c b/fsck.
On Sat, Jun 09, 2018 at 11:46:13AM +0200, SZEDER Gábor wrote:
> I add few more lines of context here:
>
> tree=$(
> {
> printf "100644 blob $content\t$tricky\n" &&
>
> > printf "12 blob
On Mon, Jun 11, 2018 at 02:14:41AM -0400, Jeff King wrote:
> On Sun, Jun 10, 2018 at 12:00:57AM +, brian m. carlson wrote:
>
> > I also have to look at this issue from the interests of what is best for
> > the FLOSS community and for users as a whole. Adding in functional
On Sun, Jun 10, 2018 at 12:00:57AM +, brian m. carlson wrote:
> I also have to look at this issue from the interests of what is best for
> the FLOSS community and for users as a whole. Adding in functionality
> that sends off usage data from a command-line tool, especially one that
> is as
On Sun, Jun 10, 2018 at 12:44:25AM +0200, Johannes Sixt wrote:
> > I agree with Peff: this is something you as a user need to be aware of,
> > and need to make sure you configure your Git just like you want. As long
> > as this is a purely opt-in feature, it is useful and helpful.
>
> The
On Sat, Jun 09, 2018 at 10:05:49PM +0200, Johannes Schindelin wrote:
> > E.g., could we have a flag or environment variable to have the existing
> > traces output JSON? I guess right now they're inherently free-form via
> > trace_printf, so it would involve adding some structured interface
> >
On Mon, Jun 11, 2018 at 01:28:23AM -0400, Eric Sunshine wrote:
> On Mon, Jun 11, 2018 at 12:47 AM, Jeff King wrote:
> > Subject: fetch-pack: don't try to fetch peeled values with --all
> > [...]
> > Original report and test from Kirill Smelkov.
> >
> > Signed-o
On Mon, Jun 11, 2018 at 12:20:16AM -0400, Jeff King wrote:
> Doubly interesting, it looks like this case _used_ to work, but was
> broken by 5f0fc64513 (fetch-pack: eliminate spurious error messages,
> 2012-09-09). Which only changed the fetch-pack side. It moved the
> handling
On Sun, Jun 10, 2018 at 02:32:57PM +, Kirill Smelkov wrote:
> Added test shows remote with two tag objects pointing to a blob and a
> tree. The tag objects themselves are referenced from under regular
> refs/tags/* namespace. If test_expect_failure is changed to
> test_expect_success the test
1201 - 1300 of 13736 matches
Mail list logo
